7 ms·

How can you find the js fragmentation a feature and not a stinking pile of shit? Seriously.

by omegote 10y ago

qaq 10y ago
It creates jobs :)
finchisko 10y ago
What exactly do you mean by js fragmentation? If that, you have power to pick from hundreds of lib/fw and combine them together, then what you call fragmentation is actual real benefit for me. I like to make decisions myself, but if you like the others to take decisions for you, js is probably not for you. The very good example is redux. Redux was once simple state management lib. Take a look at it now https://github.com/xgrommx/awesome-redux https://github.com/xgrommx/awesome-redux. That is real power of js ecosystem.
- acemarke 10y ago
  Obligatory self-plug: the "awesome-redux" list is cluttered and not well organized, and was actually rejected from inclusion in Sindre Sorhus's "awesome-awesome" list because of that ( https://github.com/sindresorhus/awesome/issues/714#issuecomment-235304428 https://github.com/sindresorhus/awesome/issues/714#issuecomm... ). On the flip side, I keep a list of Redux-related addons and utilities at https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links that is actively maintained and has (hopefully) much better categorization, as well as being a much more comprehensive list of all the useful pieces out there in the Redux ecosystem. But yes, as I've said in some recent comments: Dan and Andrew found a sweet spot with Redux's design in terms of approach, concepts, and providing building blocks for others, and that's led to an explosion of useful stuff that people have built for their own use cases.
onion2k 10y ago
There are two schools of thought. The first is that you should optimise for the platform you're targeting, so a fragmented JS world is a good thing because you optimise for different things depending on where your code is going to run. The second school of thought is that you should optimise for development, and you should have the same language everywhere even if that means slightly less efficient code. For example, if you write long running services in node then optimising for memory allocation in order to avoid leaks is a good idea. It's less useful for clientside things that generally don't run for nearly as long. Conversely, if you write isomorphic JS that can run in the browser but also needs to run on the server for that first-load advantage, then you'd prefer if things work the same everywhere. Neither school is 'right' per se. How a language ought to evolve is incredibly subjective.
- flueedo 10y ago
  Yep, and, not that having to learn and become acquainted with shortcomings of new sets of languages/tools every other year isn't a fact of life for many devs that one ought to just accept. But having something run just (or as close as possible to) the same across many platforms make it more likely that that knowledge you acquired will remain among your best options when approaching a wide range of problems for a longer time.
  - tracker1 10y ago
    Java 4 FOREVER!!!! f*ck maven... we like complex Ant configs... Generics can go to hell. I mean this is a bit of hyperbole, but the point is that languages and platforms evolve, and given that JS has a bigger target surface than anything else in the history of computing, with more resources than anything else ever being poured into it, multiplied by approaches and opinions, how can it not be diverse. The world doesn't have the same houses everywhere either... Oh noes, they're building different styles of roofs over there.. the sky is falling.
kowdermeister 10y ago
First the term. By fragmentation I mean two things: 1) we have many libraries doing the same thing. 2) the implementation is JS is not the same in every environment. If you are spending most of your time writing other languages which have a standard library, I can understand your opinion. However, I see fragmentation as: 1) It introduces the opportunity everyone on the planet to give a shot at implementing something that may or may not be better than we consider today the best. For example I used a datepicker in my latest project but in the current it failed and I could replace it in 15 minutes rather than spending hours finding the issue with the "standard one". I'm not really experienced in the C++ world, but I guess people would call me crazy if I proposed a new stdio lib. Maybe there could be better libraries, who knows. It's a settled game there. See jQuery in JS land, it was for many years, "the golden tool". Now we have alternatives for more specialized workflows. Not everybody wears the same hat all the time. 2) EcmaScript is constantly evolving, that causes another fragmentation, but this also allows the dev community to propose changes, implement new features and create a really vibrant feedback loop. If you stick to the latest stable (currently ES5) you are safe to build whatever you like with great stability.
- inimino 10y ago
  The fact that people can contribute is great, the fact that it is impossible to get started in modern JS development without making dozens of seemingly inscrutable choices is not.
  - radioact1ve 10y ago
    Exactly this. All of the upfront choices, will I make the right choice? I've been meaning to jump in and learn. After years of backend development (C#, Python, and some Go), I want to give JS a shot and at least experiment. It's a daunting process that I keep pushing back as there is no immediate need.
    - inimino 10y ago
      The best thing to remember is that if you're doing it for fun and learning, you don't need anything but a plain old HTML5 and a plain old script tag. Once you feel you need something more than that for a particular project (or for work) you'll be better able to evaluate what's out there. <script> // get started! </script>
deleted 10y ago
[deleted]
wrecursion 10y ago
I see it both as one of JS's greatest strengths, and greatest weakness's. Certainly, at a prototyping/exploratory level, all of the freedom and choices are great! For me, however, when you just 'need to get sh*t done', all the choices and configuration required to setup a project becomes a nightmare, commonly referred to now days as js fatigue. I am looking forward to trying out http://www.electrode.io/ http://www.electrode.io/ on my next project. Other than that, I have been digging into elm as a way to reduce the choices required and the cognitive load involved in setting a project up. It's great to have 'one true way' of doing things.
fenomas 10y ago
I've never understood this complaint. JS is used everywhere from browsers to servers to native apps to IoT. Does there really need to be One True Framework/Linter/Build tool/etc?Is it really that big a problem that people have made a lot of different tools and libraries because they're solving a lot of different problems?
- randall 10y ago
  I think the problem is keeping up. It's simple if you can pay attention, but if you're still on angular 1.x because you have other things to worry about, the fragmentation and pace means you can get years behind if you're not careful. It's not like ruby has another package manager every 6 months. I agree the many implementations probably are a feature, not a bug, but still induce fatigue. It's too easy to get behind.
  - fenomas 10y ago
    Maybe I'm missing something really fundamental, but why try to keep up with everything? It's a huge ecosystem and any given dev/team can only use a tiny bit of it. If a library does everything you need it to, does it matter if you're years behind on it? (modulo e.g. security fixes) I mean, certainly I agree that trying to keep current on everything would be a nightmare. But surely that's just the result of lots of people sharing lots of libraries, right? If other languages don't have the same problem, isn't that just because people aren't sharing as much code?
    - deleted 10y ago
      [deleted]
    - randall 10y ago
      I think this is true, but JS also "sucks" in different ways, so not keeping up means expending seemingly unnecessary effort in maintainability, reliability, etc. Angular 1 is impossible to maintain compared to Angular 2, for instance. Angular 1 fixed a lot of problems vanilla js faced. It's all improvements.
  - 10y ago
z3t4 10y ago
things evolve until they reach perfection. Then they die.

How can you find the js fragmentation a feature and not a stinking pile of shit? Seriously.

by omegote 10y ago

How can you find the js fragmentation a feature and not a stinking pile of shit? Seriously.

qaq 10y ago

It creates jobs :)

finchisko 10y ago

What exactly do you mean by js fragmentation? If that, you have power to pick from hundreds of lib/fw and combine them together, then what you call fragmentation is actual real benefit for me. I like to make decisions myself, but if you like the others to take decisions for you, js is probably not for you. The very good example is redux. Redux was once simple state management lib. Take a look at it now https://github.com/xgrommx/awesome-redux https://github.com/xgrommx/awesome-redux. That is real power of js ecosystem.

acemarke 10y ago
Obligatory self-plug: the "awesome-redux" list is cluttered and not well organized, and was actually rejected from inclusion in Sindre Sorhus's "awesome-awesome" list because of that ( https://github.com/sindresorhus/awesome/issues/714#issuecomment-235304428 https://github.com/sindresorhus/awesome/issues/714#issuecomm... ). On the flip side, I keep a list of Redux-related addons and utilities at https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links that is actively maintained and has (hopefully) much better categorization, as well as being a much more comprehensive list of all the useful pieces out there in the Redux ecosystem. But yes, as I've said in some recent comments: Dan and Andrew found a sweet spot with Redux's design in terms of approach, concepts, and providing building blocks for others, and that's led to an explosion of useful stuff that people have built for their own use cases.

onion2k 10y ago

There are two schools of thought. The first is that you should optimise for the platform you're targeting, so a fragmented JS world is a good thing because you optimise for different things depending on where your code is going to run. The second school of thought is that you should optimise for development, and you should have the same language everywhere even if that means slightly less efficient code. For example, if you write long running services in node then optimising for memory allocation in order to avoid leaks is a good idea. It's less useful for clientside things that generally don't run for nearly as long. Conversely, if you write isomorphic JS that can run in the browser but also needs to run on the server for that first-load advantage, then you'd prefer if things work the same everywhere. Neither school is 'right' per se. How a language ought to evolve is incredibly subjective.

flueedo 10y ago
Yep, and, not that having to learn and become acquainted with shortcomings of new sets of languages/tools every other year isn't a fact of life for many devs that one ought to just accept. But having something run just (or as close as possible to) the same across many platforms make it more likely that that knowledge you acquired will remain among your best options when approaching a wide range of problems for a longer time.
- tracker1 10y ago
  Java 4 FOREVER!!!! f*ck maven... we like complex Ant configs... Generics can go to hell. I mean this is a bit of hyperbole, but the point is that languages and platforms evolve, and given that JS has a bigger target surface than anything else in the history of computing, with more resources than anything else ever being poured into it, multiplied by approaches and opinions, how can it not be diverse. The world doesn't have the same houses everywhere either... Oh noes, they're building different styles of roofs over there.. the sky is falling.

kowdermeister 10y ago

First the term. By fragmentation I mean two things: 1) we have many libraries doing the same thing. 2) the implementation is JS is not the same in every environment. If you are spending most of your time writing other languages which have a standard library, I can understand your opinion. However, I see fragmentation as: 1) It introduces the opportunity everyone on the planet to give a shot at implementing something that may or may not be better than we consider today the best. For example I used a datepicker in my latest project but in the current it failed and I could replace it in 15 minutes rather than spending hours finding the issue with the "standard one". I'm not really experienced in the C++ world, but I guess people would call me crazy if I proposed a new stdio lib. Maybe there could be better libraries, who knows. It's a settled game there. See jQuery in JS land, it was for many years, "the golden tool". Now we have alternatives for more specialized workflows. Not everybody wears the same hat all the time. 2) EcmaScript is constantly evolving, that causes another fragmentation, but this also allows the dev community to propose changes, implement new features and create a really vibrant feedback loop. If you stick to the latest stable (currently ES5) you are safe to build whatever you like with great stability.

inimino 10y ago
The fact that people can contribute is great, the fact that it is impossible to get started in modern JS development without making dozens of seemingly inscrutable choices is not.
- radioact1ve 10y ago
  Exactly this. All of the upfront choices, will I make the right choice? I've been meaning to jump in and learn. After years of backend development (C#, Python, and some Go), I want to give JS a shot and at least experiment. It's a daunting process that I keep pushing back as there is no immediate need.
  - inimino 10y ago
    The best thing to remember is that if you're doing it for fun and learning, you don't need anything but a plain old HTML5 and a plain old script tag. Once you feel you need something more than that for a particular project (or for work) you'll be better able to evaluate what's out there. <script> // get started! </script>

deleted 10y ago

[deleted]

wrecursion 10y ago

I see it both as one of JS's greatest strengths, and greatest weakness's. Certainly, at a prototyping/exploratory level, all of the freedom and choices are great! For me, however, when you just 'need to get sh*t done', all the choices and configuration required to setup a project becomes a nightmare, commonly referred to now days as js fatigue. I am looking forward to trying out http://www.electrode.io/ http://www.electrode.io/ on my next project. Other than that, I have been digging into elm as a way to reduce the choices required and the cognitive load involved in setting a project up. It's great to have 'one true way' of doing things.

fenomas 10y ago

I've never understood this complaint. JS is used everywhere from browsers to servers to native apps to IoT. Does there really need to be One True Framework/Linter/Build tool/etc?Is it really that big a problem that people have made a lot of different tools and libraries because they're solving a lot of different problems?

randall 10y ago
I think the problem is keeping up. It's simple if you can pay attention, but if you're still on angular 1.x because you have other things to worry about, the fragmentation and pace means you can get years behind if you're not careful. It's not like ruby has another package manager every 6 months. I agree the many implementations probably are a feature, not a bug, but still induce fatigue. It's too easy to get behind.
- fenomas 10y ago
  Maybe I'm missing something really fundamental, but why try to keep up with everything? It's a huge ecosystem and any given dev/team can only use a tiny bit of it. If a library does everything you need it to, does it matter if you're years behind on it? (modulo e.g. security fixes) I mean, certainly I agree that trying to keep current on everything would be a nightmare. But surely that's just the result of lots of people sharing lots of libraries, right? If other languages don't have the same problem, isn't that just because people aren't sharing as much code?
  - deleted 10y ago
    [deleted]
  - randall 10y ago
    I think this is true, but JS also "sucks" in different ways, so not keeping up means expending seemingly unnecessary effort in maintainability, reliability, etc. Angular 1 is impossible to maintain compared to Angular 2, for instance. Angular 1 fixed a lot of problems vanilla js faced. It's all improvements.
- 10y ago

z3t4 10y ago

things evolve until they reach perfection. Then they die.