41–50 of 85 posts
Luckily, with native javascript modules, there is no need for any of this anymore. We switched our whole codebase to and it's such a joy now. Never going back to bundlers. Never going back to having a compilation step on the server.
Its a good thought, but you're excluding ~15% of all web users[0] from using your product. [0] https://caniuse.com/#feat=es6-module
Earlier quoted context omitted.
You probably won't end up with a dependency tree . Remember development in 2007? Remember this? Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published . There would be no reason to further run a bundler just to turn ~5 such pairs of files int…
That's worse because you lose the ability to "tree-shake". It would go back to importing all of Underscore on a CDN versus bundling the few functions you need into the main bundle.
"Today, it’s nearly impossible to build for the web without using a bundler like Webpack." Is it? I've gotten by just fine, and webpack is a pretty all or nothing approach. Did everyone just forget how things were done before webpack and NPM overnight? What memo did I miss?
Sure, if you only use ES5 then you don't need Babel or Webpack - but devs are tired of this shit and really want to use ES6 or Typescript.
So, "nearly impossible" is an exaggeration, but "would rather gouge my own eyes out" is perhaps not.
Earlier quoted context omitted.
That's worse because you lose the ability to "tree-shake". It would go back to importing all of Underscore on a CDN versus bundling the few functions you need into the main bundle.
OTOH, if you use a "standard" library from a CDN, it's quite possible that the end user already has it cached.
Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic.
Plus if you look at the size of these libraries, especially utility libraries (date-fns, underscore, etc) they are huge, and you usually only need a few functions. Relying on cache will never be a bigger benefit than tree-shaking.
Sure you could manually try to extract those functions, but that's a much much worse developer experience.
Earlier quoted context omitted.
I use rollup with an extremely minimal configuration. No transpilers at all, just standards-based JavaScript.
Sorry if this is a dumb question -- but that means you don't write ES6?
I can get away with not supporting Internet Explorer, though I understand that it's not a trade-off that everybody is comfortable making.
Earlier quoted context omitted.
I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.
We had several other languages once upon a time, but all were proprietary and most only worked through plugins. All were eventally removed from default installs in browsers due to awful security and mobile performance.
I don't disagree about the security issues, mobile performance, and energy consumption though, but as a dev I preferred the experience of writing AS3 apps by a long shot.
"Today, it’s nearly impossible to build for the web without using a bundler like Webpack." Is it? I've gotten by just fine, and webpack is a pretty all or nothing approach. Did everyone just forget how things were done before webpack and NPM overnight? What memo did I miss?
I think we're in a kind of awkward place right now, where browser support for ES6 is inconsistent, and TypeScript has stepped up to fill the "type gap" left by JavaScript in general. Sure, if you only use ES5 then you don't need Babel or Webpack - but devs are tired of this shit and really want to use ES6 or Typescript. So, "nearly impossible" is an exaggeration, but "would rather gouge my own eyes out" is perhaps no…
Everything else is programmers coming from other languages and believing that actually learning javascript is beneath their dignity, and persistently insisting javascript be more like whatever their fave is.
I will say this though about build systems/bundling systems in general: Combined with linting and type checking, it can stop you from accidntally shipping a large class of bugs/mistakes. An out of place semicolon breaking a build is a better outcome than breaking a production website.
This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…
I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.
I still have some array helper methods just to shuffle array or randomly pick one.
I think it's time to put everything in future JS.
This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…
I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.
This is what a lot of people love about Elm: it's a lovely language with a first-rate standard library.
The Elm ecosystem is smaller than the JS ecosystem, but of course that's a hard requirement of a nicer foundation.
More info: https://elm-lang.org
This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…
I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.
This is so incredibly important because the main development of the language is so poorly handled.