Web developers need more homotopy type theory, and to curb their NIMH hypermodularization epedemic.
What could this comment mean, I wonder.
I was trying to figure out if it was some Markov chain built from the article.
The Controversial State of JavaScript Tooling
11–20 of 160 posts
Re: The Controversial State of JavaScript Tooling
#12> People take libraries like lodash – or jQuery, as we analyzed earlier – and insert the whole thing into their codebases. If a simple bundler plugin could deal with getting rid of everything in lodash they aren’t using, footprint is one less thing we’d have to worry about.
If you use Google CDN, why does it matter how big jQuery is? If N people use their own "smaller" M-byte copy of jQuery, browsers will have to download M*N bytes, as opposed to 0 bytes if you use the cached full version. A profound waste of bandwidth.
My advice: Use Google CDN, for less common stuff use cdnjs. Don't adulterate libraries!
Re: The Controversial State of JavaScript Tooling
#13It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.
i wouldn't use Ember precisely because it strongly suggests using a command line tool specifically for the framework. I personally ended up with Typescript as a language + Bower for package management. When it comes to frameworks it is either the framework adapts my toolset or I don't use it. I refuse to compromise and embrace yet another asset pipeline or build tool, no matter how "good" the framework is supposed to be. Typescript support both decorators and JSX, so I can tolerate working with either Angular 2 and React. And since build steps are mandatory in Front End development I, at least, can take advantage of static typing.
Re: The Controversial State of JavaScript Tooling
#14It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.
So true. Ember is the antidote right now for the frontend land.
- MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more advantages
plus, as you said, the ember-cli tool, that gets you up to speed fast. The tooling makes the final success, just have a look at go... the language appears fairly weak/trivial, but the tooling is excellent.
I could freak out everytime I have to set up an react project, weighing everyones opinions about every little package for every usecase, IMO react shifts the complexity from the UI to the tooling. Ember is just perfect and the only real option I could recommend right now, and I'm just sick of thousands of "me too!" approaches for everything, this extreme diversification cripples actual progress to a halt.
Re: The Controversial State of JavaScript Tooling
#15Babel got it wrong.
Hypermodularisation is a good thing in user-facing code. Here we should thrive to shave off every last byte.
But Babel is a tool for developers. We don't need configuration explosion and endless plugins. We need all batteries included. The very purpose of Babel is "hey, I want to write hip code like the rest of cool kids of the block; now, let it run everywhere". Who needs to configure that?
Re: The Controversial State of JavaScript Tooling
#16It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.
So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more a…
> Ember is the antidote right now for the frontend land
Sounds familiar: http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-y...
Re: The Controversial State of JavaScript Tooling
#17> People take libraries like lodash – or jQuery, as we analyzed earlier – and insert the whole thing into their codebases. If a simple bundler plugin could deal with getting rid of everything in lodash they aren’t using, footprint is one less thing we’d have to worry about. If you use Google CDN, why does it matter how big jQuery is? If N people use their own "smaller" M-byte copy of jQuery, browsers will have to dow…
I believe the main problem with googles cdn is it can prevent Chinese users from visiting your site
Re: The Controversial State of JavaScript Tooling
#18> People take libraries like lodash – or jQuery, as we analyzed earlier – and insert the whole thing into their codebases. If a simple bundler plugin could deal with getting rid of everything in lodash they aren’t using, footprint is one less thing we’d have to worry about. If you use Google CDN, why does it matter how big jQuery is? If N people use their own "smaller" M-byte copy of jQuery, browsers will have to dow…
Tree-shaking and ES6 modules are coming. Rollup[1] supports them and Webpack will in the future. They can't come soon enough!
[1] https://github.com/rollup/rollup#a-next-generation-es6-modul...
Re: The Controversial State of JavaScript Tooling
#19Are there any documented cases of a business failing because their JS payload was too large? I get that smaller code is easier to understand/work with, but I've never been able to internalize the desire for small payload -- just doesn't seem like it ever matters outside of philosophic reasons for saving user's bandwidth (especially if it comes with a steep tooling cost).
It strikes me as a technical pursuit in search of a problem -- but certainly willing to be convinced otherwise.
Re: The Controversial State of JavaScript Tooling
#20It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.
i wouldn't use Ember precisely because it strongly suggests using a command line tool specifically for the framework. I personally ended up with Typescript as a language + Bower for package management. When it comes to frameworks it is either the framework adapts my toolset or I don't use it. I refuse to compromise and embrace yet another asset pipeline or build tool, no matter how "good" the framework is supposed to…
Fair point. My comment was pointing out how Ember isn't mentioned at all, not that it's necessarily better.