Interesting points. Good ideas for features I would like, and laid out in a way that makes me want to contribute.
Awesome! What's one of them? Hope to see you around then!
The State of Babel
81–90 of 109 posts
Re: The State of Babel
#82Earlier quoted context omitted.
> 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…
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…
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.
Re: The State of Babel
#83Earlier quoted context omitted.
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…
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 too…
Personally I ended up sticking with gulp, but writing a small helper that turns the tasks into command line commands (search up gulp-run-command and my username if you care to look, I really only published it for ease of use though so don't rely on it not changing), so it basically feels like an easier cross-platform make with a fancier dependency system.
99% of tools have a CLI and it's generally pretty damn good.
If you don't have many "tasks" or they are pretty simple, just use npm's built in "npm run scripts" which works fantastically for smaller projects IMO.
I agree though about the lack of ability to pass flags. I wanted something that lets me make command line commands as tasks, build a dependency tree ala gulp, and pass in optional flags to trip things like prod vs dev builds.
But at the end of the day getting make to cooperate on all platforms was a mess, and it sure as shit didn't scale well or do stuff in parallel at all. So a simple if somewhat inelegant gulp file seems the best bet for us.
(I imagine this is how new build systems are born!)
Re: The State of Babel
#84Earlier quoted context omitted.
It's no worse than any other ecosystem. Modern Java development is just as prickly -- the only difference is the complexity is more established. JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment.
> JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment. Most of the churn seems to come from people reinventing the wheel over and over again.
In this case, the wheel started off with an impractical oval shape and the reinventions are usually making it rounder.
If you'd stopped the churn two years ago, people would be using Bower for front-end package management in addition to NPM, and Gulp or Grunt for task automation. Now a few churns later, NPM is the only package manager you need since you can use Webpack to automatically cut out your duplicated front-end packages. And now NPM provides all the task scripting most devs would need, so no more Gulp or Grunt.
Things are getting simpler and easier, but if you're looking from the outside you'll just see a long list of names of tools.
Re: The State of Babel
#85Earlier quoted context omitted.
To be fair that assumes you have node and npm set up properly, including making them upgradable, making sure node_modules is in PATH, etc. I think it's easy to forget "obvious" knowledge like this that (for me at least) had to be figured out with some trial and error.
But npm comes with node, so it's just installing the language at that point. And you don't need `node_modules` in the PATH, npm-run scripts will search the local node_modules first before hitting the path. But I do agree with your point. The "bootstrapping" process of getting started in a new ecosystem is always extremely exhausting. When i was first learning python, it took me 2 solid weeks of an hour or so a night…
> getting told ... that I shouldn't try messing with packages at all as I don't need them and should just install from git
This is my pet hate, except when it's clearly a newbie question. It's usually something like: "Hi, how do I [do unusual thing]?" > "Oh, you shouldn't be doing that, ever." > "Well, this is why I'm trying to do it and the reasonable constraints involved" > "oh, didn't think of that, here's a way to do it". Irritating as hell.
Re: The State of Babel
#86Earlier quoted context omitted.
> 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…
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…
> Maybe it's me, but I've never looked at a list of tools and thought "this is too many!".
There is the problem of diffraction of efforts, and spreading knowledge too thin. You see some of the problems in the way linux distros do packaging - every major distro family has its own packaging system, born from NIH syndrome. The result is less portability of both packages and skills.
Some competition is good, but there is a point beyond which lots of choice becomes counter-productive. Troubleshooting also becomes harder when the various tool communities are smaller on average.
Re: The State of Babel
#87Not only is Babel great as a tool for transpiling JavaScript, I've found the plugin system to be splendid for building a compile-to-JS language as well. The tools are terrific to work with.
Re: The State of Babel
#88Earlier quoted context omitted.
What? That it has a huge focus on backwards compatibility because it can't just rely on having the correct language version installed?
You can rely on having the correct version installed. This is an unwillingness to accept that it's not the version you want. You work out the minimum requirements and write to that, you don't start out with the latest and greatest and work backwards.
this is what babel enables, though, but it prevents you from thinking about it in your day to day life. babel specifically is a platform for treating javascript as a syntax tree and providing plugins that transform your code to target the minimum requirements you care about now, or in a year.
the alternative you propose is that everyone writes code that only targets well-supported javascript, but does that exclude polyfills or convenience functions? Does that mean that using a polyfill for Array.prototype.map is worse than using an implementation like _.map or a hand-written map function? At best, this choice results in a complex maintenance burden that is borne by developers during future refactors (rather than an infra-focused developer upgrading the babel distribution and its presets/plugins)
the current reality is that the browser ecosystem remains heterogenous (which is why there is still a valid market for things like jquery). A plugin like babel-preset-env for instance allows you to dynamically adjust the "minimum requirements" without needing to write new polyfills and gives the benefit of improving the transformed code with little to developer intervention. It's computers doing what they're good at, i struggle to see the harm in that.
Re: The State of Babel
#89Earlier quoted context omitted.
To be fair that assumes you have node and npm set up properly, including making them upgradable, making sure node_modules is in PATH, etc. I think it's easy to forget "obvious" knowledge like this that (for me at least) had to be figured out with some trial and error.
But npm comes with node, so it's just installing the language at that point. And you don't need `node_modules` in the PATH, npm-run scripts will search the local node_modules first before hitting the path. But I do agree with your point. The "bootstrapping" process of getting started in a new ecosystem is always extremely exhausting. When i was first learning python, it took me 2 solid weeks of an hour or so a night…
Don't you have to have node_modules in PATH to be able to run `babel ...`?
Re: The State of Babel
#90As an outsider to FE development, when I see posts like this, I just shudder at the complexity of the ecosystem.
As a insider to FE development, I'm tired of hearing comments about JS fatigue and all the rest. FE development is made of many moving parts and standards managed by different players. JS, for example, has to work on a variety of browsers, from obsolete to bleeding edge, from desktop to game consoles to mobile phones. Imagine if you had to write SQL that needs to run on ALL versions of ALL major databases, paired wit…
>Imagine if you had to write SQL that needs to run on ALL versions of ALL major databases, paired with code that needs to run on every possible JVM.
Both things are entirely possible -- and much simpler than the current state of FE.