4 ms·

So the argument is essentially "there's a lot of stuff I don't really understand, a lot of it must be redundant"? React isn't just Angular with a different nam

by ng12 10y ago

So the argument is essentially "there's a lot of stuff I don't really understand, a lot of it must be redundant"? React isn't just Angular with a different name -- they have fundamentally different views on how web development should be done. They also fit different use cases (Angular is a one-stop-shop, React is minimalist by design). Same thing with the build systems. Add in the fact that a lot of this wasn't possible until recently (i.e. Webpack is fundamentally enabled by ES6-style imports) and of course things are going to change rapidly. > Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript. I'm not sure what you mean by this. Elm-html is the only example I can think of that is non-Javascript. If you're referring to Angular2 being Typescript you can still use it just fine with regular JS.

flukus 10y ago
Sure react and angular are different, what about the dozens of others? I posted elsewhere the number of crappy make clones alone: https://www.npmjs.com/search?q=make+build https://www.npmjs.com/search?q=make+build
- BigJono 10y ago
  What about them? As a front-end develop I don't know or care about them until they solve a problem I have with the existing toolset. I couldn't care less whether there's one alternative to React/Angular or a thousand.
- Klathmon 10y ago
  For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. But secondly, what makes them crappy? I've used make, and IMO it's pretty crappy itself. Have you had to maintain a recursive makefile? It's a complete nightmare to say the least. And i'm far from the only one to think make is worthy of a "remake". In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc... If you run your same search in pip, or ruby gems, or composer, or cargo, or cpan, or any other package manager for any other language and i'm sure you'll see it's fair share of build tools, frameworks, libraries, and unmaintained stuff. It's not a problem, and it never will be.
  - flukus 10y ago
    > For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. It's a problem because every time I need $tool I might have to evaluate dozens of choices, check for compatibility, investigate the ones that suit, hope to god the rest of the community is familiar with it, hope it is supported in future, etc. And then with the rate of churn you might have to do the same in a year. Make has been supported for 30 years, I know it's not going anywhere. > In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc... So there's already dozens of tools, why reinvent them in javascript? Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.
    - Klathmon 10y ago
      Well you don't need to evaluate dozens of choices, a few at most. Hell if you just wanted to go by your search above 2 of the top 3 are the 2 biggest build systems in JavaScript (grunt and gulp), and the other isn't a build system. Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". The more the merrier IMO, and if they are good then they will rise to the top over time. If you don't want to choose, just pick the most popular and deal with it, it'll feel the same as another platform where there's only one to choose from. But you could also just use make, it's all about your needs. Do you want your project to still build in a few decades with very little change? Then choose the tools for that. You just making a pet project that just needs to live until the domain expires? Try out something new! Afraid of change? Stick with make! >Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world. For the most part JS has settled. When it comes to "stuff like make" it's basically gulp or grunt (or make and friends). Yeah there are other smaller players, but there's also a few dozen Java build tools that you've probably never heard of.
      - flukus 10y ago
        See I looked at grunt and gulp and they both seemed lacking. Grunt doesn't seem to be a make clone at all, the getting started page only pays lip service to custom tasks. They both seem to require the tools you want to use to have plugins specifically for them. Neither seems to allow for variables from the command line. When I last looked into it I gave jake a go, but then you run into problems where other random tools only have grunt/gulp plugins. The core tools of the ecosystem just seem to be picking all the wrong abstraction points.

by ng12 10y ago

flukus 10y ago

Sure react and angular are different, what about the dozens of others? I posted elsewhere the number of crappy make clones alone: https://www.npmjs.com/search?q=make+build https://www.npmjs.com/search?q=make+build

BigJono 10y ago
What about them? As a front-end develop I don't know or care about them until they solve a problem I have with the existing toolset. I couldn't care less whether there's one alternative to React/Angular or a thousand.
Klathmon 10y ago
For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. But secondly, what makes them crappy? I've used make, and IMO it's pretty crappy itself. Have you had to maintain a recursive makefile? It's a complete nightmare to say the least. And i'm far from the only one to think make is worthy of a "remake". In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc... If you run your same search in pip, or ruby gems, or composer, or cargo, or cpan, or any other package manager for any other language and i'm sure you'll see it's fair share of build tools, frameworks, libraries, and unmaintained stuff. It's not a problem, and it never will be.
- flukus 10y ago
  > For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. It's a problem because every time I need $tool I might have to evaluate dozens of choices, check for compatibility, investigate the ones that suit, hope to god the rest of the community is familiar with it, hope it is supported in future, etc. And then with the rate of churn you might have to do the same in a year. Make has been supported for 30 years, I know it's not going anywhere. > In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc... So there's already dozens of tools, why reinvent them in javascript? Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.
  - Klathmon 10y ago
    Well you don't need to evaluate dozens of choices, a few at most. Hell if you just wanted to go by your search above 2 of the top 3 are the 2 biggest build systems in JavaScript (grunt and gulp), and the other isn't a build system. Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". The more the merrier IMO, and if they are good then they will rise to the top over time. If you don't want to choose, just pick the most popular and deal with it, it'll feel the same as another platform where there's only one to choose from. But you could also just use make, it's all about your needs. Do you want your project to still build in a few decades with very little change? Then choose the tools for that. You just making a pet project that just needs to live until the domain expires? Try out something new! Afraid of change? Stick with make! >Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world. For the most part JS has settled. When it comes to "stuff like make" it's basically gulp or grunt (or make and friends). Yeah there are other smaller players, but there's also a few dozen Java build tools that you've probably never heard of.
    - flukus 10y ago
      See I looked at grunt and gulp and they both seemed lacking. Grunt doesn't seem to be a make clone at all, the getting started page only pays lip service to custom tasks. They both seem to require the tools you want to use to have plugins specifically for them. Neither seems to allow for variables from the command line. When I last looked into it I gave jake a go, but then you run into problems where other random tools only have grunt/gulp plugins. The core tools of the ecosystem just seem to be picking all the wrong abstraction points.