10 ms·

I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very

I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very well. Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard. React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit for a simple webpage, which would be silly. We're building a web app, right?) I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a little lost at why we're using both Webpack and Gulp though. Babel is a necessary evil to ensure we're "cross-platform" in a manner of speaking. These are probably your most "unnecessarily complicated" tools. ESLint and Flow check your code for obvious mistakes. Reminds me of IntelliSense and compiler warnings. Again, pretty standard stuff. Mocha is a test runner and Chai is an "assertion library". Chai isn't a big deal: expect(foo).to.equal('bar'); Simple stuff. Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary. Am I the only one that likes this ecosystem? I feel like it follows the Unix philosophy of "Make each program do one thing well". You need almost all these tools in other environments -- they're just typically chosen for you in advanced.

morgante 10y ago
I like it too. People vastly over-estimate the complexity of these tools. As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched to Webpack).
- threeseed 10y ago
  The complexity of the tools isn't the problem. It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last. So for those us who don't do front end development we come back and suddenly have to learn 20 new tools.
  - deleted 10y ago
    [deleted]
  - Can_Not 10y ago
    > It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last. If you assume that the entire Javascript community was one person or one coherent group, then yes. But it is not like that at all. You state this as if a single organization made grunt, then made gulp, then made webpack. This is nearly as absurd as saying "The entire programming community seems to suffer from ADHD and is constantly inventing new languages". People who are using grunt didn't pack-up their bags and move to gulp, then pack up their bags and move to webpack. Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens. That's as absurd as suggesting that after leaving ruby for node, your team left node for golang, then left golang for rust, then finally rewrote their application in elixir. All these different tools solve different problems, or solve them under different constraints, or solve them in ways that better match their backend languages. There isn't some magical tool that everyone needs to jump to.
    - setr 10y ago
      Probably a better term than inventing is "standardizing". The community as a single general entity, is constantly changing what they accept is the "standard stack". I don't get to have my safe goto stack of LAMP for twenty years, and then swap out alternatives after research and my needs; the goto stack is radically different every year. And ofc there's a big push for frameworks and languages over libraries, and libraries get coupled to frameworks, so anytime you do want to "upgrade" to the new thing, _everything_ goes with it.
      - Can_Not 10y ago
        > The community as a single general entity, is constantly changing what they accept is the "standard stack". You're operating on a false premise, the community is not a single entity. You don't oversimplify Javascript and pick the "standard stack", you have to do some basic research first. Maybe you need jQuery, maybe you need React. It would be pretty stupid to assume that all web development problems are nails then also assume the latest popular bleeding edge tool is a hammer.
- wheelerwj 10y ago
  Maybe that's part of the problem. Most people don't start a new project every week, so we get to know the same tools pretty well for a year or two or longer.
- jomamaxx 10y ago
  "As a freelancer, I start a new project every other week or so." Yeah - I'm not sure if this is representative. Moroever, if you're staring a project every other week, you may not be working at the scale/resiliency that most entities need, not even considering legacy etc.. The toolchain churn in JS is too much, especially relative to other platforms.
- cgag 10y ago
  Coming back to my project from 6 months ago and upgrading dependencies and finding out nothing my tooling is obsolete os awful.
Retozi 10y ago
I like it as well. I have yet to see tech stack that has comparable potential but is less complicated and can be stripped down as low as the web stack if your requirements permit it. I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of. However, I would like to see the tech stack that allows you to do the same with less complexity. It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.
deleted 10y ago
[deleted]
Cyph0n 10y ago
I'm usually one of those "JS frontend ecosystem is too complex" guys, but I found this tutorial to be quite approachable. Maybe the format of introducing one thing in each section helps? There was a similar but much more complicated tutorial on HN a while back that I didn't get at all. Most of the explanation was handwavy - "just do this, trust me" - and the entire tutorial was dumped on a single page. Just looking at the scrollbar discouraged me! I'm kind of surprised to see Yarn in a tutorial already. Welcome to the fast-moving world of JS, I guess?
- ateevchopra 10y ago
  Many people feel "JS frontend ecosystem is too complex". All of this is usually because of the horizontal complexity than the vertical horizontal complexity. There are just so many tools one should know. As nulagrithom said, all these do their job best ! And if you want to have a good project, you will be better with these tools :) And once you know what they do, they are pretty easy to work with.
ateevchopra 10y ago
If you have worked in JS for some time, and have an idea what all these tools do, This comment is probably the best tl;dr of what you are going to learn ! Pretty balanced, Just to the point. I havn't read the tutorial, but looks promising !. Will sure checkout this weekend :)
khc 10y ago
I think the reason most of us dislike the ecosystem isn't because therre are many libraries and tools in the stack. In the C-world, every time you type 'make' I am probably executing two dozen different programs, so we are very comfortable with "Make each program do one thing well". The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple years. As someone who doesn't do this as a full time job but once in a while has to poke his head out to the other side, it's really hard to keep up with even the acronyms. For example, I know that we are using npm, but now you say we should use yarn?!
- deleted 10y ago
  [deleted]
- Klathmon 10y ago
  I don't buy that either. The youngest thing on that list is yarn, but aside from that everything is a few years old at least. And nobody is saying you need to use anything. Npm works fine, bower still works fine, hell pulling down tarballs still works fine. You don't need to use the newest thing if you don't have the problems it's trying to solve.
  - vcarl 10y ago
    Yeah, from the outside I can understand the "everything keeps changing!!" complaint, but having been involved in JS for a few years, every single tool that got replaced was replaced for completely valid reasons, that couldn't have been solved incrementally by improving what was already there. Grunt > Gulp > Webpack manual polyfills > 6to5 > Babel script tags > bower > NPM > Yarn nothing > Flow/Typescript All of these were significant improvements upon the status quo. If you don't understand why, that's fine! Keep using what you know.
    - neandrake 10y ago
      As an outsider my question would be why can't the existing tools update and adopt instead of being replaced?
djfm 10y ago
I love this ecosystem. It's living, it's thriving. I love the fact that tons of great engineers are coming up with new ideas everyday to make my life as a developer easier. I love hearing a developer at a daily stand-up meeting saying he's been up all night trying out a new shiny thing and concluding by saying it also solves a big issue we had in our product and here's the pull request (timestamp 4am). The hype is here for a reason. Hype is nothing bad, being excited about your tools makes your days happier. I love the fact that JS people are never going to take "No" for an answer, constantly pushing the boundaries of what's possible, and making the web standards improve. I love the rise of functional programming. JS is a playground where mathematical theory and all of its beauty meets practice and the real world. It attracts talented people who bring a new perspective to our field. I love the fact that now I have theorems that ensure my login button will work. > I'm a little lost at why we're using both Webpack and Gulp though. Same here. I think one of the huge benefits of webpack is that it actually kills a lot of complexity by allowing you to skip gulp/grunt in most cases. I think most people do not realize that the JS ecosystem is actually removing complexity. Most people think the JS ecosystem is overly complicated, when in fact, it's just that in JS the complexity is exposed. This allows us to focus on reducing it. In order to address an issue, you must first make it visible. Nowadays the trend in JS is to use multiple small tools that solve specific issues very well. We have a complexity in setup in exchange for less complexity in development. I argue this is a good thing, because setup is easy to document and only happens once in a project. Whereas you face development complexity every day. This part from the tutorial is very significant to me: > I recommend writing everything from scratch yourself Yes! Yes! Yes! That's the heart of the JS philosophy: the ecosystem is trying very hard to make you understand what you are doing and why. It's giving you the keys to question what you're told and improve it. It's also why there's so much trolling. It's a good thing, question what seems too complex so that people can tackle the issue. Please, do keep saying JS sucks, it's exactly what makes it so strong. Do not use a framework, wire-up things yourself so that tomorrow you can repair it or upgrade it easily. Do not write your router from scratch. But do connect the standard-issue router to your business logic yourself. Don't let someone else plug it in for you. It'll fit, but it won't look as good as if it were custom-made by a great tailor. Finally, I love the config files. I hear a lot of trolling about all the config files, but I love the fact that I don't need to tell both webpack and mocha how to transpile JS and can just let the .babelrc tell them and everyone else. It's amazing that you can just git clone something and have all your environment setup as the author intended: language variant, linting... with .eslintrc developers using IntelliJ and atom both see the same messages. Long live JS, or whatever comes next as we improve it!
gotofritz 10y ago
Did you not read the memo? "the javascript ecosystem is a mess!!111" etc
novaleaf 10y ago
Webpack + Typescript works as a replacement (without Gulp, Babel, eslint, or flow) if you are interested in giving typescript a go.
jomamaxx 10y ago
"You need almost all these tools in other environments -- they're just typically chosen for you in advanced." + I don't think anyone is complaining about what the tools do, or necessarily their quality. The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc.. Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place. Again - great stack. But it won't last long, and it's very expensive to churn. Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now". Reasonable assertion. Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach. Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn. Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.
snorrah 10y ago
How big is the nodemodules dir after installing these 12 "small tools" ?
- lloyd-christmas 10y ago
  Who cares? This is 2016, memory footprint hasn't been relevant in years.
  - yellowapple 10y ago
    This attitude is precisely why so many software projects nowadays are memory hogs. Not everyone has an i7-powered Macbook with 8+ GB of RAM.
    - lloyd-christmas 10y ago
      It took my 2 minutes to find a laptop under $500 with 8GB of RAM. My 2011 asus laptop has 8GB RAM. I'm not going to build software with my 2005 Inspiron in mind. Don't expect people to cater to 10 year old machines.
      - yellowapple 10y ago
        Not everyone has $500 of disposable income, either. Not to mention that very few phones and netbooks (like Chromebooks) have more than 4GB of RAM (in fact, I'm not aware of any in either category except for the Chromebook Pixel line). Lots of people in the real world are stuck with hardware with 2GB of RAM (or less!). I develop with those users in mind. I don't expect the average HN-reading programmer to do the same (I've long given up on that), but that doesn't mean it ain't a problem.
        lloyd-christmas 10y ago
        > I develop with those users in mind I also develop with users in mind, which is why I don't care how large my development environment is as long as it brings benefit to them. My original comment was a response to a person who rhetorically asked how big the node_modules folder was after installing a list of dev tools. I don't install my IDE on your phone/netbook, nor do I install my JS dev tools. Who cares how much disk space it eats up on my developer computer? I couldn't fill my disk space unless I spent a week downloading porn. My laptop cost comment was one about developer contributions, based on the belief that we were still talking about dev tools. I won't design my dev environment so that a developer with a 10 year old computer can work with me. Everything in here has been about developer workflow. The user isn't impacted by any of it. In fact, all it does is improve their experience. For an example, I have a hobby app I'm working on in node/angular2, which is an image editing platform. $ du -sh my_app/ 483MB my_app/ $ cd my_app && npm run build $ du -sh my_app.tar.gz 3.7MB my_app.tar.gz It unzips to 24MB, 20MB of which are the few node modules that don't play nice with my build system. Spinning it up, it takes ups 62 MB of RAM. I'd hardly consider that earth shattering to a user (the user doesn't download it anyway, it's an api deployed on a server). When I run it in dev mode, it takes up 400MB of RAM. I don't care, because that's what this computer exists for.
ivanhoe 10y ago
Unix philosophy is "Make each program do one thing well", but they've made them once, many decades ago and haven't change them much since. The problem here IMHO is the speed at which it all evolves, and even more the speed at which the old tools become obsolete. You start a new project with the current 'cutting-edge' stack, and within the 6 months everyone switched to something else. It's become a full-time job just to stay up to date with everything that's going on, and that means making architecture decisions is a lot harder. Also, I personally dislike the fact that it forces one to pick a niche. For decades you could say "I'm good in front-end dev" and really mean it, and now it's not possible anymore to be truly proficient in all that's going on, you just have to specialize.
facorreia 10y ago
I think what sets many people off -- including myself -- is that the "recommended" libraries change so often. It's like a joke: "You're still using npm for installing packages? That's SO 2015! Of course you should be using Yarn." After 21 years of JavaScript, one would expect a little more stability, so that the web app you build in 2016 with cutting-edge technology wouldn't be scoffed at in 2017 and obsolete by 2018.

morgante 10y ago

I like it too. People vastly over-estimate the complexity of these tools. As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched to Webpack).

threeseed 10y ago
The complexity of the tools isn't the problem. It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last. So for those us who don't do front end development we come back and suddenly have to learn 20 new tools.
- deleted 10y ago
  [deleted]
- Can_Not 10y ago
  > It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last. If you assume that the entire Javascript community was one person or one coherent group, then yes. But it is not like that at all. You state this as if a single organization made grunt, then made gulp, then made webpack. This is nearly as absurd as saying "The entire programming community seems to suffer from ADHD and is constantly inventing new languages". People who are using grunt didn't pack-up their bags and move to gulp, then pack up their bags and move to webpack. Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens. That's as absurd as suggesting that after leaving ruby for node, your team left node for golang, then left golang for rust, then finally rewrote their application in elixir. All these different tools solve different problems, or solve them under different constraints, or solve them in ways that better match their backend languages. There isn't some magical tool that everyone needs to jump to.
  - setr 10y ago
    Probably a better term than inventing is "standardizing". The community as a single general entity, is constantly changing what they accept is the "standard stack". I don't get to have my safe goto stack of LAMP for twenty years, and then swap out alternatives after research and my needs; the goto stack is radically different every year. And ofc there's a big push for frameworks and languages over libraries, and libraries get coupled to frameworks, so anytime you do want to "upgrade" to the new thing, _everything_ goes with it.
    - Can_Not 10y ago
      > The community as a single general entity, is constantly changing what they accept is the "standard stack". You're operating on a false premise, the community is not a single entity. You don't oversimplify Javascript and pick the "standard stack", you have to do some basic research first. Maybe you need jQuery, maybe you need React. It would be pretty stupid to assume that all web development problems are nails then also assume the latest popular bleeding edge tool is a hammer.
wheelerwj 10y ago
Maybe that's part of the problem. Most people don't start a new project every week, so we get to know the same tools pretty well for a year or two or longer.
jomamaxx 10y ago
"As a freelancer, I start a new project every other week or so." Yeah - I'm not sure if this is representative. Moroever, if you're staring a project every other week, you may not be working at the scale/resiliency that most entities need, not even considering legacy etc.. The toolchain churn in JS is too much, especially relative to other platforms.
cgag 10y ago
Coming back to my project from 6 months ago and upgrading dependencies and finding out nothing my tooling is obsolete os awful.

Retozi 10y ago

I like it as well. I have yet to see tech stack that has comparable potential but is less complicated and can be stripped down as low as the web stack if your requirements permit it. I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of. However, I would like to see the tech stack that allows you to do the same with less complexity. It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.

deleted 10y ago

[deleted]

Cyph0n 10y ago

I'm usually one of those "JS frontend ecosystem is too complex" guys, but I found this tutorial to be quite approachable. Maybe the format of introducing one thing in each section helps? There was a similar but much more complicated tutorial on HN a while back that I didn't get at all. Most of the explanation was handwavy - "just do this, trust me" - and the entire tutorial was dumped on a single page. Just looking at the scrollbar discouraged me! I'm kind of surprised to see Yarn in a tutorial already. Welcome to the fast-moving world of JS, I guess?

ateevchopra 10y ago
Many people feel "JS frontend ecosystem is too complex". All of this is usually because of the horizontal complexity than the vertical horizontal complexity. There are just so many tools one should know. As nulagrithom said, all these do their job best ! And if you want to have a good project, you will be better with these tools :) And once you know what they do, they are pretty easy to work with.

ateevchopra 10y ago

If you have worked in JS for some time, and have an idea what all these tools do, This comment is probably the best tl;dr of what you are going to learn ! Pretty balanced, Just to the point. I havn't read the tutorial, but looks promising !. Will sure checkout this weekend :)

khc 10y ago

I think the reason most of us dislike the ecosystem isn't because therre are many libraries and tools in the stack. In the C-world, every time you type 'make' I am probably executing two dozen different programs, so we are very comfortable with "Make each program do one thing well". The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple years. As someone who doesn't do this as a full time job but once in a while has to poke his head out to the other side, it's really hard to keep up with even the acronyms. For example, I know that we are using npm, but now you say we should use yarn?!

deleted 10y ago
[deleted]
Klathmon 10y ago
I don't buy that either. The youngest thing on that list is yarn, but aside from that everything is a few years old at least. And nobody is saying you need to use anything. Npm works fine, bower still works fine, hell pulling down tarballs still works fine. You don't need to use the newest thing if you don't have the problems it's trying to solve.
- vcarl 10y ago
  Yeah, from the outside I can understand the "everything keeps changing!!" complaint, but having been involved in JS for a few years, every single tool that got replaced was replaced for completely valid reasons, that couldn't have been solved incrementally by improving what was already there. Grunt > Gulp > Webpack manual polyfills > 6to5 > Babel script tags > bower > NPM > Yarn nothing > Flow/Typescript All of these were significant improvements upon the status quo. If you don't understand why, that's fine! Keep using what you know.
  - neandrake 10y ago
    As an outsider my question would be why can't the existing tools update and adopt instead of being replaced?

djfm 10y ago

I love this ecosystem. It's living, it's thriving. I love the fact that tons of great engineers are coming up with new ideas everyday to make my life as a developer easier. I love hearing a developer at a daily stand-up meeting saying he's been up all night trying out a new shiny thing and concluding by saying it also solves a big issue we had in our product and here's the pull request (timestamp 4am). The hype is here for a reason. Hype is nothing bad, being excited about your tools makes your days happier. I love the fact that JS people are never going to take "No" for an answer, constantly pushing the boundaries of what's possible, and making the web standards improve. I love the rise of functional programming. JS is a playground where mathematical theory and all of its beauty meets practice and the real world. It attracts talented people who bring a new perspective to our field. I love the fact that now I have theorems that ensure my login button will work. > I'm a little lost at why we're using both Webpack and Gulp though. Same here. I think one of the huge benefits of webpack is that it actually kills a lot of complexity by allowing you to skip gulp/grunt in most cases. I think most people do not realize that the JS ecosystem is actually removing complexity. Most people think the JS ecosystem is overly complicated, when in fact, it's just that in JS the complexity is exposed. This allows us to focus on reducing it. In order to address an issue, you must first make it visible. Nowadays the trend in JS is to use multiple small tools that solve specific issues very well. We have a complexity in setup in exchange for less complexity in development. I argue this is a good thing, because setup is easy to document and only happens once in a project. Whereas you face development complexity every day. This part from the tutorial is very significant to me: > I recommend writing everything from scratch yourself Yes! Yes! Yes! That's the heart of the JS philosophy: the ecosystem is trying very hard to make you understand what you are doing and why. It's giving you the keys to question what you're told and improve it. It's also why there's so much trolling. It's a good thing, question what seems too complex so that people can tackle the issue. Please, do keep saying JS sucks, it's exactly what makes it so strong. Do not use a framework, wire-up things yourself so that tomorrow you can repair it or upgrade it easily. Do not write your router from scratch. But do connect the standard-issue router to your business logic yourself. Don't let someone else plug it in for you. It'll fit, but it won't look as good as if it were custom-made by a great tailor. Finally, I love the config files. I hear a lot of trolling about all the config files, but I love the fact that I don't need to tell both webpack and mocha how to transpile JS and can just let the .babelrc tell them and everyone else. It's amazing that you can just git clone something and have all your environment setup as the author intended: language variant, linting... with .eslintrc developers using IntelliJ and atom both see the same messages. Long live JS, or whatever comes next as we improve it!

gotofritz 10y ago

Did you not read the memo? "the javascript ecosystem is a mess!!111" etc

novaleaf 10y ago

Webpack + Typescript works as a replacement (without Gulp, Babel, eslint, or flow) if you are interested in giving typescript a go.

jomamaxx 10y ago

"You need almost all these tools in other environments -- they're just typically chosen for you in advanced." + I don't think anyone is complaining about what the tools do, or necessarily their quality. The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc.. Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place. Again - great stack. But it won't last long, and it's very expensive to churn. Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now". Reasonable assertion. Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach. Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn. Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.

snorrah 10y ago

How big is the nodemodules dir after installing these 12 "small tools" ?

lloyd-christmas 10y ago
Who cares? This is 2016, memory footprint hasn't been relevant in years.
- yellowapple 10y ago
  This attitude is precisely why so many software projects nowadays are memory hogs. Not everyone has an i7-powered Macbook with 8+ GB of RAM.
  - lloyd-christmas 10y ago
    It took my 2 minutes to find a laptop under $500 with 8GB of RAM. My 2011 asus laptop has 8GB RAM. I'm not going to build software with my 2005 Inspiron in mind. Don't expect people to cater to 10 year old machines.
    - yellowapple 10y ago
      Not everyone has $500 of disposable income, either. Not to mention that very few phones and netbooks (like Chromebooks) have more than 4GB of RAM (in fact, I'm not aware of any in either category except for the Chromebook Pixel line). Lots of people in the real world are stuck with hardware with 2GB of RAM (or less!). I develop with those users in mind. I don't expect the average HN-reading programmer to do the same (I've long given up on that), but that doesn't mean it ain't a problem.
      - lloyd-christmas 10y ago
        > I develop with those users in mind I also develop with users in mind, which is why I don't care how large my development environment is as long as it brings benefit to them. My original comment was a response to a person who rhetorically asked how big the node_modules folder was after installing a list of dev tools. I don't install my IDE on your phone/netbook, nor do I install my JS dev tools. Who cares how much disk space it eats up on my developer computer? I couldn't fill my disk space unless I spent a week downloading porn. My laptop cost comment was one about developer contributions, based on the belief that we were still talking about dev tools. I won't design my dev environment so that a developer with a 10 year old computer can work with me. Everything in here has been about developer workflow. The user isn't impacted by any of it. In fact, all it does is improve their experience. For an example, I have a hobby app I'm working on in node/angular2, which is an image editing platform. $ du -sh my_app/ 483MB my_app/ $ cd my_app && npm run build $ du -sh my_app.tar.gz 3.7MB my_app.tar.gz It unzips to 24MB, 20MB of which are the few node modules that don't play nice with my build system. Spinning it up, it takes ups 62 MB of RAM. I'd hardly consider that earth shattering to a user (the user doesn't download it anyway, it's an api deployed on a server). When I run it in dev mode, it takes up 400MB of RAM. I don't care, because that's what this computer exists for.

ivanhoe 10y ago

Unix philosophy is "Make each program do one thing well", but they've made them once, many decades ago and haven't change them much since. The problem here IMHO is the speed at which it all evolves, and even more the speed at which the old tools become obsolete. You start a new project with the current 'cutting-edge' stack, and within the 6 months everyone switched to something else. It's become a full-time job just to stay up to date with everything that's going on, and that means making architecture decisions is a lot harder. Also, I personally dislike the fact that it forces one to pick a niche. For decades you could say "I'm good in front-end dev" and really mean it, and now it's not possible anymore to be truly proficient in all that's going on, you just have to specialize.

facorreia 10y ago

I think what sets many people off -- including myself -- is that the "recommended" libraries change so often. It's like a joke: "You're still using npm for installing packages? That's SO 2015! Of course you should be using Yarn." After 21 years of JavaScript, one would expect a little more stability, so that the web app you build in 2016 with cutting-edge technology wouldn't be scoffed at in 2017 and obsolete by 2018.