7 ms·

First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling severa

First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. Babel is a compiler, ESNext is a language specification (now ES6 since after being been finalized more than 2 years ago). amd, systemjs, requirejs, and browserify are all still supported and have not been "deprecated" as you say. However for the last 2 years Webpack has been the dominant module bundling system since it's incredibly powerful and extendable. The standard for about 2 years now has been to use Babel + ES6 imports with Webpack. Babel lets you write ES6 code that compiles back to ES5, which means older browsers can run it. This means you can write modern code with patterns that will never get deprecated that works in older browsers. Webpack takes some configuration to fine tune it for large apps but getting it set up for a small app is pretty painless these days, and it continues to improve. I'm honestly kind of sick of there being someone in every comment thread bursting through the door to tell everyone about all the bloat in the JS ecosystem. It's largely been solved and there's a lot of maturity in the libraries in use now. I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.

jsheard 9y ago
Furthermore, you usually don't need Babel if you're a Typescript user because the Typescript compiler covers more or less the same ground. Use Typescript+Webpack if you like types, or Javascript+Babel+Webpack if you like surprises, and in either case use ES6 module imports.
- ComputerGuru 9y ago
  However a lot of guides (even some officially sanctioned ones iirc) use Babel to transpile typescript in the browser, forgoing the precompilation to JavaScript entirely. I don’t know if that’s just an artifact of days gone by, an attempt to bypass tsc before it gained on-the-fly watch-and-compile support, or for another reason entirely.
  - spiralx 9y ago
    I think you're getting Babel and SystemJS confused - the latter allows you to use TypeScript files as the source attribute in script tags and have it transpiled within the browser, which is sometimes used in examples and tutorials because it avoids any need to use the command line or configure a new TS project.
Arnavion 9y ago
>This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. "amd vs esnext vs systemjs" is about module formats. "Babel vs browserify vs requireJS vs webpack" is about transpilers and loaders.
ComputerGuru 9y ago
Thanks for taking the time to write out this reply - my initial comment sort of took on a life of its own, it wasn't originally supposed to turn into a rant and was never intended to be taken literally or to imply that it had been precisely crafted. I appreciate your responding to it nevertheless. I am actually very aware of the differences between the various components, but I am appalled at just how many cogs it takes to get things working _with 3rd party libraries involved_. It seems as soon as you bring in a single dependency, Pandora's Box is opened and you suddenly have to bring in 12 different build systems along with it. > I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated. In my case, it's the other way around. I don't think you understand how much of a breath of fresh air being able to "just paste a script into your html" was for people that came from complicated build systems that required you to locally download, build, and install each dependency your code relied on because there was no module system and there were no URLs or CDNs or whatnot. What is sad is that JS, after seeing how horrible of a mess the C "module" system was, went down the same road when they could have embraced better alternatives and iterated html/browsers in-step with JavaScript to come up with something that wasn't such a mess. I confess to not being a JS history expert, but as I understand it, require came from node running locally before people tried taking that to the web, and thus requireJS was born. Only it needed a mess of other components to get it to work with existing libraries. And then those 3rd party components were deprecated or replaced by newer iterations, sometimes by the same developers or sometimes by newcomers to the scene. And no one bothered with compatibility with existing systems, except people that drew up a type of "super standard" that encompassed n other types by simply multiplying their complexity instead of reducing it. We went from being able to get a web app up and running with an HTML file and a single JS file, optionally combined into a single document, to requiring a dozen different build systems, separate compilers and transpilers, many layers of abstraction, required preprocessors and optional in-browser on-the-fly compilers, OS-specific tools, library-specific module systems, and a million different ways that a single statement ("export") could be translated into code, or the dozen different gotchas that you need to consider when you type in that one word ("import") because you'll have to dig up the documentation for the library you want to use to find out just how it exports its interface.. and then you need to make it play nice with the framework you already have in place. We went from writing every line that of code that appeared in the browser to writing a simple "hello world" that require an insane 10x or 100x payload to run it... and only after studying the various build systems and trying to figure out which was old enough to be supported but new enough to still be around for longer than it took to learn JS itself. With regards to deprecation, I personally (though not even a web developer by trade) ran into the official deprecation of both bower and typings; and while requireJS and co may not be deprecated per se, if they're not the "right" way of starting a new app today then they are deprecated because your time is better spent learning skills that will still matter tomorrow and sooner or later for a living app you will need to replace them with something else to be able to use the latest version of dependencies and libraries.

jsheard 9y ago

Furthermore, you usually don't need Babel if you're a Typescript user because the Typescript compiler covers more or less the same ground. Use Typescript+Webpack if you like types, or Javascript+Babel+Webpack if you like surprises, and in either case use ES6 module imports.

ComputerGuru 9y ago
However a lot of guides (even some officially sanctioned ones iirc) use Babel to transpile typescript in the browser, forgoing the precompilation to JavaScript entirely. I don’t know if that’s just an artifact of days gone by, an attempt to bypass tsc before it gained on-the-fly watch-and-compile support, or for another reason entirely.
- spiralx 9y ago
  I think you're getting Babel and SystemJS confused - the latter allows you to use TypeScript files as the source attribute in script tags and have it transpiled within the browser, which is sometimes used in examples and tutorials because it avoids any need to use the command line or configure a new TS project.

Arnavion 9y ago

>This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. "amd vs esnext vs systemjs" is about module formats. "Babel vs browserify vs requireJS vs webpack" is about transpilers and loaders.

ComputerGuru 9y ago

Thanks for taking the time to write out this reply - my initial comment sort of took on a life of its own, it wasn't originally supposed to turn into a rant and was never intended to be taken literally or to imply that it had been precisely crafted. I appreciate your responding to it nevertheless. I am actually very aware of the differences between the various components, but I am appalled at just how many cogs it takes to get things working _with 3rd party libraries involved_. It seems as soon as you bring in a single dependency, Pandora's Box is opened and you suddenly have to bring in 12 different build systems along with it. > I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated. In my case, it's the other way around. I don't think you understand how much of a breath of fresh air being able to "just paste a script into your html" was for people that came from complicated build systems that required you to locally download, build, and install each dependency your code relied on because there was no module system and there were no URLs or CDNs or whatnot. What is sad is that JS, after seeing how horrible of a mess the C "module" system was, went down the same road when they could have embraced better alternatives and iterated html/browsers in-step with JavaScript to come up with something that wasn't such a mess. I confess to not being a JS history expert, but as I understand it, require came from node running locally before people tried taking that to the web, and thus requireJS was born. Only it needed a mess of other components to get it to work with existing libraries. And then those 3rd party components were deprecated or replaced by newer iterations, sometimes by the same developers or sometimes by newcomers to the scene. And no one bothered with compatibility with existing systems, except people that drew up a type of "super standard" that encompassed n other types by simply multiplying their complexity instead of reducing it. We went from being able to get a web app up and running with an HTML file and a single JS file, optionally combined into a single document, to requiring a dozen different build systems, separate compilers and transpilers, many layers of abstraction, required preprocessors and optional in-browser on-the-fly compilers, OS-specific tools, library-specific module systems, and a million different ways that a single statement ("export") could be translated into code, or the dozen different gotchas that you need to consider when you type in that one word ("import") because you'll have to dig up the documentation for the library you want to use to find out just how it exports its interface.. and then you need to make it play nice with the framework you already have in place. We went from writing every line that of code that appeared in the browser to writing a simple "hello world" that require an insane 10x or 100x payload to run it... and only after studying the various build systems and trying to figure out which was old enough to be supported but new enough to still be around for longer than it took to learn JS itself. With regards to deprecation, I personally (though not even a web developer by trade) ran into the official deprecation of both bower and typings; and while requireJS and co may not be deprecated per se, if they're not the "right" way of starting a new app today then they are deprecated because your time is better spent learning skills that will still matter tomorrow and sooner or later for a living app you will need to replace them with something else to be able to use the latest version of dependencies and libraries.