←back to thread

367 points lemonberry | 1 comments | | HN request time: 0.209s | source
Show context
rektide ◴[] No.24641170[source]
It would have helped a lot if JS had a working modules systems on the web.

> What hope do those who can’t write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.

JS has been in a dark & ugly spot, & WebComponents feeling janky & weird is probably 50% the fact that JS is this dark twisting maze where each project has it's own very unique assumptions about how to turn authored JS into usable, deployable JS. We're still hoping, praying that import-maps eventually give us modular javascript code that we can deploy, without having to push it through a handful of compile/build tools: https://github.com/Fyrd/caniuse/issues/4810

By compare, Big Framework land often adopts some suggested normative best paths people can work with (ex, create-react-app bundling build/test/&c tools). Alas, the language itself is still, a decade latter, trying to proceed to useable modules on the web.

The other major point of this article tends towards a JS vs HTML problem, another area I am very sympathetic to & have hopes for.

> Far more people can write HTML than JS. Even for those who do eventually write JS, it often comes after spending years writing HTML & CSS. [...] If components are designed in a way that requires JS, this excludes thousands of people from using them.

There are ongoing efforts with HTML Modules ( https://www.chromestatus.com/feature/4854408103854080 ) to try to make, among other things, bringing in WebComponents much easier, and Declarative Custom Elements ( https://blog.usejournal.com/w3c-declarative-custom-elements-... ) to make building modules much more HTML-centric & declarative versus today where most of the authoring of a custom element has to be done in JS.

There are very real problems, there is too much js, the js module system is still in a 1/2 complete state on the web, & these very much dog Web Components. But the future is exciting, & I continue to have hope that a much better, much more web native way of building emerges on the web platform. Lea talks a lot to how scattershot the last decade of work has been, how inconsistent, but given the other ecosystem constraints I'm not fully surprised, & I'm delighted that we are spending so long building & experimenting & learning, that for many of us, the hunger is very real. Also missing, the big adopters of WebComponents have been pretty silent, their thought-leadership seems missing: Youtube, Github. There are visible people from these worlds talking about WebComponents, but to my knowledge the real experience of WebComponents at scale from the very successful adopters remains a story not told.

replies(3): >>24641396 #>>24641781 #>>24667340 #
WorldMaker ◴[] No.24641781[source]
caniuse statistics say that ES2015 module support has reached something like 92% of browsers:

https://caniuse.com/es6-module

replies(2): >>24647004 #>>24647472 #
1. rektide ◴[] No.24647472[source]
this deserves a good write up, because it's complicated.

it's not that hard to write a es6-module. it's pretty easy, and you can ask for it, and it'll work, behave like a ecmascript module in an ok way.

but. but if that module has other modules that it wants to pull in, the author of that module has to hardcode a bunch of assumptions about how & where that module that it depends on is. the module, in short, is not modular, because there's no way for users of that module to help it find the modules it depends on.

the best example of a work-around for this absolutely tragically-impotent pretty-much-useless es6-module system is dynamic rewrite engines like unpkg.com javascript cdn, which, on their home page mentions the ?module query parameter you can ask for. this will dynamically resolve & re-write all the dependencies of a module, to point to other unpkg.com modules. let me re-iterate: it has to re-write each module you ask for in a way where all of that module's depenencies are now also resolved unpkg modules, who themselves will also be rewritten such that their dependencies are also solved, & so on & so on, until the whole tree of modules is all rewritten to use unpkg modules. each module has to be rewritten such that there's now some kind of way to import dependencies. es6-modules provides no means to do that. each module has to resolve it's dependencies fully, ahead of time. so modules here are not actually modular: each host is left to copy, resolve, & modify the original module & make it their copy of the module, resolving dependencies however the consumer can figure out.

this is completely hosed & absolutely unbearable. modules are not modular. es6-modules are ok syntax, are ok language, but they are categorically useless on the web. it's truly tragic; es6-modules stopped while being only 33% of the way done. for what it's worth, import-maps is the only work anyone has suggested to resume progress & let modules work in any kind of inter-operable manner, & i have heard no good protest against it: i sincerely wish it would advance much much faster & be released so we can stop being stuck with terrible, unusable, non-modular modules on the web.