6 ms·

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

by 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?
    - Klathmon 10y ago
      Because that's what leads to monumentally difficult to use tools. Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break... Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.
      - wheelerwj 10y ago
        "rather than bloating the current tools, you.." just bloat the whole stack.
        Klathmon 10y ago
        How so? I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts. If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all. Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.
      - neandrake 10y ago
        Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come. It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?
  - rsj_hn 10y ago
    The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability. In other words, this is the consequence of optimizing for new entrants and writability versus readability and maintainability. It also becomes much harder to funnel talented people into being contributors to existing projects rather than starting their own. In other languages there are very large projects that are heavily refactored and improved to support new patterns and use cases with regularity. Just yesterday I was using Antlr 4, which has been around for 25 years. But it's been updated many times. Maven was started in 2002, and maven 3 in 2008. It's stable and production quality. The openssl library goes back to 1998. Vim goes back to 1988 -- also rock solid and reliable. We're using a networking stack that is pretty damn old. But in the JS world, I can't help but think they would never be able produce anything that reliable because 6 years later they would be on their 6th re-write of Vim. And no, it's not (IMO) because other languages have corporate sponsors. Javascript came out of the webspace which (was) primarily throwaway code. It was a bad thing to have an old website. They prioritized rapid prototyping, which was appropriate for that business case. However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years. You need tools that last decades, even as they are incrementally improved. If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff. It's no different than the developer that builds non-sustainable housing that has to be torn down every 10 years but is really cheap to build. Long term, a city built that way will necessarily be smaller in size and more expensive to maintain than a city built with housing that is more expensive to build up front but lasts a lot longer. Exponential decay is going to catch up to languages that like to keep re-writing all their libraries. More importantly, I don't see an awareness on the part of the JS community that this is a serious problem that they need to tackle. They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff. So when there is announcement -- here is your standard webstack and it contains a tool less than a year old, a lot of people are gonna say "WTF", and explaining to them that Yarn has some new feature that NPM doesn't kinda misses the point. Of course it has some new features -- but still -- "WTF"?
gotofritz 10y ago
Just google "yarn vs npm" and you'll know the answer... the tools change because the technology is evolving, despite node the front end is still the driver, and mobile phones / browsers / etc are constantly being improved and evolved, and the ecosystem keeps up with it. Would you rather it all stayed static like in the C world and then you program a 2016 smartphone with a 2006 stack?
- 1_player 10y ago
  No, the problem is never improving the existing software but rewriting a new solution from scratch every 3 months [1][2], that, while it solves the shortcomings of the previous tool, now introduces a complete set of new problems. And people that actually have stuff to deliver are always playing catch up and fighting the bugs of alpha quality software. I feel strongly about this, especially when reading a step-by-step tutorial, that's most probably intended at frontend "newbies", that for example is pushing Yarn: I played with it the other day on a working VueJS application, and got hit by a bug, causing yarn to delete important files in node_modules. My code wouldn't work anymore. Really sorry that I can't find the bug report anymore to prove my point. The workaround was going back to npm. Teaching people alpha quality software is irresponsible. If you want to teach, or have stuff to deliver, use the battle tested tech. Experiment when you know how the pieces work together and have lots of free time. 1: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html 2: EDIT: this is a big problem of our industry, it happens in all environments, but the JS community is the worst IMO. Desktop Linux is the second worst offender.
- wheelerwj 10y ago
  The problem with continuously changing technologies is that it doesn't allow you to become a master of that stack, so your constantly relearning how to accomplish the same thing. It's inefficient. If I build my applications with well established technologies, then I can do it quickly and accurately. Sure, I might miss out on some cutting edge benefits, but my shit works, always. However, if i switch to JS, I feel like I will have to not only relearn how to do things I already know how to do, but I will be stuck in a cycle of continuing education and won't ever be able to expand my skillset beyond those things.
elcct 10y ago
I'd say tools change every couple of days and often introduce breaking changes.

by khc 10y ago

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?
  - Klathmon 10y ago
    Because that's what leads to monumentally difficult to use tools. Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break... Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.
    - wheelerwj 10y ago
      "rather than bloating the current tools, you.." just bloat the whole stack.
      - Klathmon 10y ago
        How so? I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts. If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all. Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.
    - neandrake 10y ago
      Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come. It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?
- rsj_hn 10y ago
  The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability. In other words, this is the consequence of optimizing for new entrants and writability versus readability and maintainability. It also becomes much harder to funnel talented people into being contributors to existing projects rather than starting their own. In other languages there are very large projects that are heavily refactored and improved to support new patterns and use cases with regularity. Just yesterday I was using Antlr 4, which has been around for 25 years. But it's been updated many times. Maven was started in 2002, and maven 3 in 2008. It's stable and production quality. The openssl library goes back to 1998. Vim goes back to 1988 -- also rock solid and reliable. We're using a networking stack that is pretty damn old. But in the JS world, I can't help but think they would never be able produce anything that reliable because 6 years later they would be on their 6th re-write of Vim. And no, it's not (IMO) because other languages have corporate sponsors. Javascript came out of the webspace which (was) primarily throwaway code. It was a bad thing to have an old website. They prioritized rapid prototyping, which was appropriate for that business case. However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years. You need tools that last decades, even as they are incrementally improved. If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff. It's no different than the developer that builds non-sustainable housing that has to be torn down every 10 years but is really cheap to build. Long term, a city built that way will necessarily be smaller in size and more expensive to maintain than a city built with housing that is more expensive to build up front but lasts a lot longer. Exponential decay is going to catch up to languages that like to keep re-writing all their libraries. More importantly, I don't see an awareness on the part of the JS community that this is a serious problem that they need to tackle. They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff. So when there is announcement -- here is your standard webstack and it contains a tool less than a year old, a lot of people are gonna say "WTF", and explaining to them that Yarn has some new feature that NPM doesn't kinda misses the point. Of course it has some new features -- but still -- "WTF"?

gotofritz 10y ago

Just google "yarn vs npm" and you'll know the answer... the tools change because the technology is evolving, despite node the front end is still the driver, and mobile phones / browsers / etc are constantly being improved and evolved, and the ecosystem keeps up with it. Would you rather it all stayed static like in the C world and then you program a 2016 smartphone with a 2006 stack?

1_player 10y ago
No, the problem is never improving the existing software but rewriting a new solution from scratch every 3 months [1][2], that, while it solves the shortcomings of the previous tool, now introduces a complete set of new problems. And people that actually have stuff to deliver are always playing catch up and fighting the bugs of alpha quality software. I feel strongly about this, especially when reading a step-by-step tutorial, that's most probably intended at frontend "newbies", that for example is pushing Yarn: I played with it the other day on a working VueJS application, and got hit by a bug, causing yarn to delete important files in node_modules. My code wouldn't work anymore. Really sorry that I can't find the bug report anymore to prove my point. The workaround was going back to npm. Teaching people alpha quality software is irresponsible. If you want to teach, or have stuff to deliver, use the battle tested tech. Experiment when you know how the pieces work together and have lots of free time. 1: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html 2: EDIT: this is a big problem of our industry, it happens in all environments, but the JS community is the worst IMO. Desktop Linux is the second worst offender.
wheelerwj 10y ago
The problem with continuously changing technologies is that it doesn't allow you to become a master of that stack, so your constantly relearning how to accomplish the same thing. It's inefficient. If I build my applications with well established technologies, then I can do it quickly and accurately. Sure, I might miss out on some cutting edge benefits, but my shit works, always. However, if i switch to JS, I feel like I will have to not only relearn how to do things I already know how to do, but I will be stuck in a cycle of continuing education and won't ever be able to expand my skillset beyond those things.

elcct 10y ago

I'd say tools change every couple of days and often introduce breaking changes.