6 ms·

Reading through the comments here has been predictable. A lot of people complaining about the complexity of the front-end ecosystem. Too many tools, to much con

Reading through the comments here has been predictable. A lot of people complaining about the complexity of the front-end ecosystem. Too many tools, to much configuration, etc. I’d like to say that you don’t need that complexity. If you just want to write a dumb front-end you don’t need typescript, you don’t need babel, you don’t need pug, you don’t need webpack, etc. If these things bother you, just skip it. I always start my websites with a simple index.html file and run a `python -m http.server`. That is it. Modern JavaScript has a really good module system that works in all major browser (even Edge), and node. If you want to write type safe JavaScript you can write your types as doc comments and have typescript check it without bundling or compiling. You literally need only two tools to write a website: a browser and a text editor. I’m not here to tell you that people shouldn’t use these complex tools. Many people configure their front-end environment just fine with webpack, babel, typescript, etc. If they work better that way, that is fine. But if that bothers you, simply don’t do it. There is no reason for you to complain about it.

jonahx 6y ago
I like your advice, but I think there is a reason for the complaints. An indefensible complexity has become the new normal. And it's what many people are forced to suffer through at work. If having a chorus of complaining dissenters on HN threads sways even a small percentage of people to take simpler approaches, it has done some good.
- tkzed49 6y ago
  When people are complaining about this kind of stuff at work, it raises the question of what the alternative is. The person you're replying to describes a great methodology for smaller projects, but in many cases there are great reasons to take on dependencies. Not taking a dependency means you pay in person-hours to reinvent it, and sometimes that cost is much higher than a couple extra seconds of build time. And, once you have a lot of dependencies, ES modules won't save you. People expect web apps to load fast, and code is big. Things like Webpack help make it a lot smaller. My point isn't that this is good, it's that it's not "indefensible". There are very real practical reasons that big companies deal with the debt of dependencies and bundlers.
  - runarberg 6y ago
    Many people (including my self at work) handle webpack configs just fine. I started a vue project at work the other day and it was as simple as: npx @vue/cli@latest create my-project This scaffolded a fully configured project with webpack, babel, typescript, eslint, a custom dev server, etc. I think react developers have a similar tool called create-react-app. I personally (or professionally, since I only use this at work; personally I just have an `index.html` and a python server) just let vue-cli handle the webpack config and forget about it. I guess rust developers use cargo to the same manner. I suspect much of the complain about the complexity of the front-end ecosystem comes from people that either a) don’t do front-end regularly and are trying to build a website for them self but get bad advice for the tools needed, or b) are backend developers at work and think they know better about the front-end then their front-end counterparts. In the case of (a), they simply just need better advice on tooling (and which tools are an overkill), the tone of my original comment was more directed at the other group (b; although the advice I gave was for the former group—whoops).
    - dmitriid 6y ago
      > it was as simple as: This just hides all the complexity behind a yet another layer of abstractions. The moment something breaks due to a minor upgrade, you're screwed.
      - lights0123 6y ago
        Although, I do think that Vue handles the webpack config in a great way. I've been using vue-cli to manage my webpack config for years now, and never had a minor upgrade of any dependency break the build. It also provides a nice way to hook into the webpack config, so you can still add your own plugins and loaders without having to opt out of it managing it for you.
- onenite 6y ago
  If one is in the majority and is suffering, then there is an opportunity to examine what one is doing, not to mention the environment. After working at small shops managing frontends with 1-2 other people and then moving to frontends managed by larger numbers and divisions, especially in a culture of moving quickly, things can get hairy quite fast. Even so, it helps to make a habit of revisiting things from first principles and to also assume the beginner’s mind, collectively, to work towards more refined, elegant, simpler systems/modules based on lessons of the past. Speaking of “normals”... it used to be normal for most people to be undernourished. Now, the normal is that the majority of people in many developed countries are overfed. And overstimulated. Same with the code we write. Overfed. Overstimulated. The dangers of prosperity and excess! But at least we have the opportunity to focus and sharpen our realities. ... Anyway, back to Webpack. Webpack is great. It is one such system that went through a lot of growing pains and complexities to get used to, not to mentioned subpar documentation in the early days, but it has evolved gracefully and is quite elegant, and has been for a few years now! Read the docs, people! And modern refined tools like Vue CLI, create-react-app, Next.js, and now Vite can take care of most of the “boring” frontend configuration! No one really needs to struggle with Webpack anymore.
- qudat 6y ago
  Dissenters are almost always people who haven't spent enough time in the JS ecosystem to understand why we need the tools we need to be successful. If you want to build a web app, you must target javascript and the browser. There are so many backend programming languages that enables developers to figure out their preferences. I get it, if I didn't have a choice but to build every web API using rails I think I would stop doing web development as well. I learned to embrace the JS ecosystem and all of its quirks a long time ago. I think the ecosystem is first class and better than most other ecosystems I've part of. None of the dissenters ever have good enough arguments to sway me. To each their own, but JS is a fantastic, vibrant ecosystem with exceptional engineers solving problems that are wholly unique to the browser.
  - cxr 6y ago
    > I learned to embrace the JS ecosystem and all of its quirks a long time ago. Stop conflating the NPM ecosystem with JS.
  - dmitriid 6y ago
    > Dissenters are almost always people who haven't spent enough time in the JS ecosystem to understand why we need the tools No. Dissenters are almost always people who clearly understand how overly complex and at the same time extremely brittle frontend toolchains are. Understanding why you need these tools doesn't change the reality of what these tools are and how they work.
apeescape 6y ago
That is all fine for personal projects. However, professional web apps typically have more complex requirement than just supporting the latest versions of major browsers without any further optimizations, so the only viable way of filling them is to use the complex tooling.
- deleted 6y ago
  [deleted]
- runarberg 6y ago
  idk. I’ve worked with complex python codes and they also tend to have some complex setups like virtualenvs, django manage scripts, required system software, custom python version etc. Thankfully my workplace has this system set up by python experts who maintains all the complex config and documents how colleagues can get this thing running on their machine. At work I don’t need to understand the complex setup, and if I were to write a python project personally, I wouldn’t do it this complex. A complex front-end code in your workplace should be similar. Hopefully a seasoned front-end developer is maintaining this complexity and if a back-end developer needs to contribute a trivial change, they can just `npm start` (documented in the README.md) which sets in place a whole lot of complexity that the back-end developer doesn’t need to understand, but just works.
  - zamber 6y ago
    Yes, but... chances are your backend dev will have a system-provided or just plain outdated Node version so they'll get a cryptic exception and will have to reach for assistance. Ideally you would have a pipeline building the project on each branch commit so that the backend dev can push, wait 5 min, fetch the artifacts for that branch and run it locally to test it. Or even better - if there's a pipeline chances are there's a Dockerfile doing the build but it will not support live-reload. Either ways it gets complex as soon as you have to get out of your comfort zone. Especially if the docs are outdated/verbose/non-existent.
anuila 6y ago
Preach. One can complain that the tools could be better, but not that they exist. They exist because they solve a problem that other platforms don't have: real-time delivery over the web and compatibility with a variety of runtimes.
t0astbread 6y ago
My setup for simple to somewhat complex web apps is to download a minified version of Preact and htm and just import it as ES6 modules. The builds from unpkg work just fine although it seems you can't use the hooks extension since it has an unpkg URL hard-coded. I haven't looked into building Preact myself.
djaychela 6y ago
>I always start my websites with a simple index.html file and run a `python -m http.server`. That is it I didn't know that was a thing, so thanks for mentioning it - tips like these are one of the main reasons I read hn - and it'll save me hours of now needless file transfers.
- sixbrx 6y ago
  "npx serve" is another good way to serve static files quickly without needing python or any npm installs even. npx is packaged with npm for a while now.
fergie 6y ago
Amen.

jonahx 6y ago

I like your advice, but I think there is a reason for the complaints. An indefensible complexity has become the new normal. And it's what many people are forced to suffer through at work. If having a chorus of complaining dissenters on HN threads sways even a small percentage of people to take simpler approaches, it has done some good.

tkzed49 6y ago
When people are complaining about this kind of stuff at work, it raises the question of what the alternative is. The person you're replying to describes a great methodology for smaller projects, but in many cases there are great reasons to take on dependencies. Not taking a dependency means you pay in person-hours to reinvent it, and sometimes that cost is much higher than a couple extra seconds of build time. And, once you have a lot of dependencies, ES modules won't save you. People expect web apps to load fast, and code is big. Things like Webpack help make it a lot smaller. My point isn't that this is good, it's that it's not "indefensible". There are very real practical reasons that big companies deal with the debt of dependencies and bundlers.
- runarberg 6y ago
  Many people (including my self at work) handle webpack configs just fine. I started a vue project at work the other day and it was as simple as: npx @vue/cli@latest create my-project This scaffolded a fully configured project with webpack, babel, typescript, eslint, a custom dev server, etc. I think react developers have a similar tool called create-react-app. I personally (or professionally, since I only use this at work; personally I just have an `index.html` and a python server) just let vue-cli handle the webpack config and forget about it. I guess rust developers use cargo to the same manner. I suspect much of the complain about the complexity of the front-end ecosystem comes from people that either a) don’t do front-end regularly and are trying to build a website for them self but get bad advice for the tools needed, or b) are backend developers at work and think they know better about the front-end then their front-end counterparts. In the case of (a), they simply just need better advice on tooling (and which tools are an overkill), the tone of my original comment was more directed at the other group (b; although the advice I gave was for the former group—whoops).
  - dmitriid 6y ago
    > it was as simple as: This just hides all the complexity behind a yet another layer of abstractions. The moment something breaks due to a minor upgrade, you're screwed.
    - lights0123 6y ago
      Although, I do think that Vue handles the webpack config in a great way. I've been using vue-cli to manage my webpack config for years now, and never had a minor upgrade of any dependency break the build. It also provides a nice way to hook into the webpack config, so you can still add your own plugins and loaders without having to opt out of it managing it for you.
onenite 6y ago
If one is in the majority and is suffering, then there is an opportunity to examine what one is doing, not to mention the environment. After working at small shops managing frontends with 1-2 other people and then moving to frontends managed by larger numbers and divisions, especially in a culture of moving quickly, things can get hairy quite fast. Even so, it helps to make a habit of revisiting things from first principles and to also assume the beginner’s mind, collectively, to work towards more refined, elegant, simpler systems/modules based on lessons of the past. Speaking of “normals”... it used to be normal for most people to be undernourished. Now, the normal is that the majority of people in many developed countries are overfed. And overstimulated. Same with the code we write. Overfed. Overstimulated. The dangers of prosperity and excess! But at least we have the opportunity to focus and sharpen our realities. ... Anyway, back to Webpack. Webpack is great. It is one such system that went through a lot of growing pains and complexities to get used to, not to mentioned subpar documentation in the early days, but it has evolved gracefully and is quite elegant, and has been for a few years now! Read the docs, people! And modern refined tools like Vue CLI, create-react-app, Next.js, and now Vite can take care of most of the “boring” frontend configuration! No one really needs to struggle with Webpack anymore.
qudat 6y ago
Dissenters are almost always people who haven't spent enough time in the JS ecosystem to understand why we need the tools we need to be successful. If you want to build a web app, you must target javascript and the browser. There are so many backend programming languages that enables developers to figure out their preferences. I get it, if I didn't have a choice but to build every web API using rails I think I would stop doing web development as well. I learned to embrace the JS ecosystem and all of its quirks a long time ago. I think the ecosystem is first class and better than most other ecosystems I've part of. None of the dissenters ever have good enough arguments to sway me. To each their own, but JS is a fantastic, vibrant ecosystem with exceptional engineers solving problems that are wholly unique to the browser.
- cxr 6y ago
  > I learned to embrace the JS ecosystem and all of its quirks a long time ago. Stop conflating the NPM ecosystem with JS.
- dmitriid 6y ago
  > Dissenters are almost always people who haven't spent enough time in the JS ecosystem to understand why we need the tools No. Dissenters are almost always people who clearly understand how overly complex and at the same time extremely brittle frontend toolchains are. Understanding why you need these tools doesn't change the reality of what these tools are and how they work.

apeescape 6y ago

That is all fine for personal projects. However, professional web apps typically have more complex requirement than just supporting the latest versions of major browsers without any further optimizations, so the only viable way of filling them is to use the complex tooling.

deleted 6y ago
[deleted]
runarberg 6y ago
idk. I’ve worked with complex python codes and they also tend to have some complex setups like virtualenvs, django manage scripts, required system software, custom python version etc. Thankfully my workplace has this system set up by python experts who maintains all the complex config and documents how colleagues can get this thing running on their machine. At work I don’t need to understand the complex setup, and if I were to write a python project personally, I wouldn’t do it this complex. A complex front-end code in your workplace should be similar. Hopefully a seasoned front-end developer is maintaining this complexity and if a back-end developer needs to contribute a trivial change, they can just `npm start` (documented in the README.md) which sets in place a whole lot of complexity that the back-end developer doesn’t need to understand, but just works.
- zamber 6y ago
  Yes, but... chances are your backend dev will have a system-provided or just plain outdated Node version so they'll get a cryptic exception and will have to reach for assistance. Ideally you would have a pipeline building the project on each branch commit so that the backend dev can push, wait 5 min, fetch the artifacts for that branch and run it locally to test it. Or even better - if there's a pipeline chances are there's a Dockerfile doing the build but it will not support live-reload. Either ways it gets complex as soon as you have to get out of your comfort zone. Especially if the docs are outdated/verbose/non-existent.

anuila 6y ago

Preach. One can complain that the tools could be better, but not that they exist. They exist because they solve a problem that other platforms don't have: real-time delivery over the web and compatibility with a variety of runtimes.

t0astbread 6y ago

My setup for simple to somewhat complex web apps is to download a minified version of Preact and htm and just import it as ES6 modules. The builds from unpkg work just fine although it seems you can't use the hooks extension since it has an unpkg URL hard-coded. I haven't looked into building Preact myself.

djaychela 6y ago

>I always start my websites with a simple index.html file and run a `python -m http.server`. That is it I didn't know that was a thing, so thanks for mentioning it - tips like these are one of the main reasons I read hn - and it'll save me hours of now needless file transfers.

sixbrx 6y ago
"npx serve" is another good way to serve static files quickly without needing python or any npm installs even. npx is packaged with npm for a while now.

fergie 6y ago

Amen.