5 ms·

Awesome job. This is not a knock on JavaScript in particular, but the amount of brain bandwidth and dependencies to launch a modern web app is getting a bit abs

Awesome job. This is not a knock on JavaScript in particular, but the amount of brain bandwidth and dependencies to launch a modern web app is getting a bit absurd. I'm turning into that old grumpy hacker who prefers the simple good ole' days of LAMP. :-) React - (UI Framework) GraphQL - (Web Data API) Apollo - (GraphQL Client) Next - (Routing, SSR, Hot Module Reloading, Code Splitting, Build tool uses Webpack) Redux - (State Management) Node.js - (Web Server) Express - (Web App Server) Passport - (Authentication) Babel - (JS Transpiling) Flow - (Static Types) ESLint - (JS Best Practices/Code Highlighting) Jest - (Tests) Yarn Package Manager - (Better Dependencies) Docker - (Container Deployment)

wishinghand 9y ago
The length of that is the same as doing it in any other language, it's just that the ways to do it aren't built into the language. You could eschew a lot of these things, but you'd just end up building them yourself. Flow? Unfortunate that it's a separate thing but it gets types which will relieve most programmers. Yarn? .NET has Nuget, Ruby has Gem, Go has dep, etc. Passport? I sure as hell don't want to do authentication all on my own. Jest? I mean, you don't have to test but everyone should.
colordrops 9y ago
Definitely a lot of stuff going on. I take that as a sign of maturity rather than a problem. It's not really any different from C++ or Java or Python. You've got to learn all the frameworks and tooling as well. There's an equivalent for many of those packages in other languages.
ng12 9y ago
I see these kind of posts often. What's a reasonable benchmark? What useful projects have only a handful of dependencies? You could say the same about a project in any language -- it's just more noticeable in the JavaScript ecosystem because best practices are still developing.
- Touche 9y ago
  news.ycombinator.com which is faster and has 0 js deps.
  - ng12 9y ago
    HN contains 2kb worth of JavaScript, it's almost all HTML.
deleted 9y ago
[deleted]
oddlyaromatic 9y ago
>launch a modern web app It took me a long time to realize that "launching the app" is not really what these tools are for. You can create perfectly fine awesome web apps with just HTML/CSS/ES5. But as it gets more complex, or you add collaborators, or you feel how much easier/faster certain things would be if you could operate at a different level of abstraction... the world does tend to pull you towards these tools. None of them are necessary though, they just trade a little ramp at the beginning for a lot of saved headaches later on. I still don't use have of this stuff, but I recall recently debugging an issue that was a couple of clicks into an SPA (in an interview no less) and I sure wished I had jumped through the hoops to get hot module reloading on that one! Likewise, I'm kind of ready for tests now, to make sure the rendered HTML is what I expect in various scenarios, rather than walk through the app like a paranoid moron after every change. I think the way to stay sane in modern front-end development is to not overthink the tools - if your project is already using them, great, use them the right amount for your team. If you don't use, say, Redux, but your state management is causing lots of pain, hey, maybe it's time for Redux now. If you already write only beautiful ES5 that runs correctly an is easy to reason about, who needs Babel. My favorite situation is when somebody else picked the tools and the build process and I don't have to give a crap about evaluating all the options. Knowing and caring about all of the pros and cons IS a lot of bandwidth!
adamnemecek 9y ago
You are partially right but you have to remember that each of these is addressing a generally large pain point. So by embracing a standard solution, you can abstract that point away to some degree. This tradeoff is called progress.
renlo 9y ago
Just from looking at the list of libraries/frameworks/tech used, it seems like it was over-engineered. It was probably a fun project to work on, or maybe it was a good learning experience for the developer, but it seems like it's a wee bit too over-complicated. If someone wanted to release something like this to actual customers then I don't think you'd want to make it like that. This is coming from someone who started out in the front-end with JS and SPAs. Why add in the responsiveness (and overhead) of a SPA when your users won't really notice the difference?
- computerex 9y ago
  I am sorry, but your gut feeling of why you think this is over engineered is not an argument.
  - nightski 9y ago
    Is it really a gut feeling when Hacker News itself does not use hardly any of those technologies?
    - deleted 9y ago
      [deleted]
  - noitsnot 9y ago
    The list of 14 'Features' should be all you need as an argument.
- cnp 9y ago
  It's just one way to do things, used to demonstrate interesting new tech. It's meant as a helpful pointer similar to TodoMVC and not as a demonstration on how to build Hacker News "better".
leeoniya 9y ago
without commenting on the dependencies specifically, and simply evaluating the result sent to the client: - 1.1 MB of assets (pretty much all of it scripts). - 300ms of JS execution (on fast desktop in Chrome 63) - document.querySelectorAll("*").length = 742 in terms of perf, i'm sorry, but this is nothing to be proud of. even a fast vdom lib without SSR can do this in 10% the payload (or less) and 20% the scripting time (or less). why people are amazed at the speed of this impl is rather odd to me. i suppose it works well to demonstrate a large stack, but what you end up paying for that stack is plainly evident here.
lettergram 9y ago
I find you need different tools for different jobs. I personally build 80% of my apps using Rails or Django, with vanilla coffeescript or javascript + a few libraries for graphs. That works for most business applications, and pretty much any information app (which IMO are usually the most valuable by dollars) Rails is easier for most people to develop in (even if they are framiliar with JS or Django) within a week of starting. Usually after a 5 minute discussion I can show them why it's amazing and everyone switches over. However, at a point, react and the like becomes easier when you want a prettier customer facing application, or when you want only part of the web page to update in real time (Personally, I can do this in Rails, but many find react easier). Point being, in those cases a framework that's literally built for that might be easier, and that's when it should be used. Honestly, I think this whole JS craze is annoying, and I try to run no javascript. Because of that, I might be more sensitive than most and I design websites accordingly (only using JS as necessary)

wishinghand 9y ago

The length of that is the same as doing it in any other language, it's just that the ways to do it aren't built into the language. You could eschew a lot of these things, but you'd just end up building them yourself. Flow? Unfortunate that it's a separate thing but it gets types which will relieve most programmers. Yarn? .NET has Nuget, Ruby has Gem, Go has dep, etc. Passport? I sure as hell don't want to do authentication all on my own. Jest? I mean, you don't have to test but everyone should.

colordrops 9y ago

Definitely a lot of stuff going on. I take that as a sign of maturity rather than a problem. It's not really any different from C++ or Java or Python. You've got to learn all the frameworks and tooling as well. There's an equivalent for many of those packages in other languages.

ng12 9y ago

I see these kind of posts often. What's a reasonable benchmark? What useful projects have only a handful of dependencies? You could say the same about a project in any language -- it's just more noticeable in the JavaScript ecosystem because best practices are still developing.

Touche 9y ago
news.ycombinator.com which is faster and has 0 js deps.
- ng12 9y ago
  HN contains 2kb worth of JavaScript, it's almost all HTML.

deleted 9y ago

[deleted]

oddlyaromatic 9y ago

>launch a modern web app It took me a long time to realize that "launching the app" is not really what these tools are for. You can create perfectly fine awesome web apps with just HTML/CSS/ES5. But as it gets more complex, or you add collaborators, or you feel how much easier/faster certain things would be if you could operate at a different level of abstraction... the world does tend to pull you towards these tools. None of them are necessary though, they just trade a little ramp at the beginning for a lot of saved headaches later on. I still don't use have of this stuff, but I recall recently debugging an issue that was a couple of clicks into an SPA (in an interview no less) and I sure wished I had jumped through the hoops to get hot module reloading on that one! Likewise, I'm kind of ready for tests now, to make sure the rendered HTML is what I expect in various scenarios, rather than walk through the app like a paranoid moron after every change. I think the way to stay sane in modern front-end development is to not overthink the tools - if your project is already using them, great, use them the right amount for your team. If you don't use, say, Redux, but your state management is causing lots of pain, hey, maybe it's time for Redux now. If you already write only beautiful ES5 that runs correctly an is easy to reason about, who needs Babel. My favorite situation is when somebody else picked the tools and the build process and I don't have to give a crap about evaluating all the options. Knowing and caring about all of the pros and cons IS a lot of bandwidth!

adamnemecek 9y ago

You are partially right but you have to remember that each of these is addressing a generally large pain point. So by embracing a standard solution, you can abstract that point away to some degree. This tradeoff is called progress.

renlo 9y ago

Just from looking at the list of libraries/frameworks/tech used, it seems like it was over-engineered. It was probably a fun project to work on, or maybe it was a good learning experience for the developer, but it seems like it's a wee bit too over-complicated. If someone wanted to release something like this to actual customers then I don't think you'd want to make it like that. This is coming from someone who started out in the front-end with JS and SPAs. Why add in the responsiveness (and overhead) of a SPA when your users won't really notice the difference?

computerex 9y ago
I am sorry, but your gut feeling of why you think this is over engineered is not an argument.
- nightski 9y ago
  Is it really a gut feeling when Hacker News itself does not use hardly any of those technologies?
  - deleted 9y ago
    [deleted]
- noitsnot 9y ago
  The list of 14 'Features' should be all you need as an argument.
cnp 9y ago
It's just one way to do things, used to demonstrate interesting new tech. It's meant as a helpful pointer similar to TodoMVC and not as a demonstration on how to build Hacker News "better".

leeoniya 9y ago

without commenting on the dependencies specifically, and simply evaluating the result sent to the client: - 1.1 MB of assets (pretty much all of it scripts). - 300ms of JS execution (on fast desktop in Chrome 63) - document.querySelectorAll("*").length = 742 in terms of perf, i'm sorry, but this is nothing to be proud of. even a fast vdom lib without SSR can do this in 10% the payload (or less) and 20% the scripting time (or less). why people are amazed at the speed of this impl is rather odd to me. i suppose it works well to demonstrate a large stack, but what you end up paying for that stack is plainly evident here.

lettergram 9y ago

I find you need different tools for different jobs. I personally build 80% of my apps using Rails or Django, with vanilla coffeescript or javascript + a few libraries for graphs. That works for most business applications, and pretty much any information app (which IMO are usually the most valuable by dollars) Rails is easier for most people to develop in (even if they are framiliar with JS or Django) within a week of starting. Usually after a 5 minute discussion I can show them why it's amazing and everyone switches over. However, at a point, react and the like becomes easier when you want a prettier customer facing application, or when you want only part of the web page to update in real time (Personally, I can do this in Rails, but many find react easier). Point being, in those cases a framework that's literally built for that might be easier, and that's when it should be used. Honestly, I think this whole JS craze is annoying, and I try to run no javascript. Because of that, I might be more sensitive than most and I design websites accordingly (only using JS as necessary)