←back to thread

367 points lemonberry | 1 comments | | HN request time: 0.219s | 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 #
svachalek ◴[] No.24647004[source]
The goal keeps moving though. If I need to process TypeScript files into JS to load them in the browser, why stop at modules and not just go ahead and link and tree shake and all that too?

Maybe things will settle down and browsers will actually run the code that web developers are writing, but the way things are going I don’t see that ever happening. Likely we’ll end up coding in any language and downloading WASM.

replies(2): >>24647483 #>>24652935 #
1. WorldMaker ◴[] No.24652935[source]
> The goal keeps moving though.

I think the goal posts have stayed the same:

1) Module support in browsers. (Now ~92% per caniuse.)

2) Optional: Wide support for HTTP/2 in browsers. (Now ~95% per caniuse.)

3) Optional: Wide support for HTTP/2 in servers. I don't have good statistics on this one, but things feel "close" to ready.

(2) and (3) are desirous for performance, and we've known that all along as modules balloon the number of HTTP requests.

Maybe you also want to count super option (4) "smart HTTP ES module push preloading", but that seems unnecessary gilding to me.

> If I need to process TypeScript files into JS to load them in the browser, why stop at modules and not just go ahead and link and tree shake and all that too?

If you are outputting modules you shouldn't have to "link"; admittedly performance is still a concern, but that's what HTTP/2 (and/or HTTP/3) are supposed to help with.

If you are outputting modules rather than "linking"/"packing" you shouldn't have much to tree-shake and the browser will naturally tree shake in terms of simply not requesting modules outside of the execution path.

Just because you have a build step doesn't mean you have to "build all the things", and it shouldn't be a surprise and should be obvious that a type-checking-and-stripping only run of Typescript is faster than a Typescript+Webpack+Rollup+Terser or whatever stack.

> Maybe things will settle down and browsers will actually run the code that web developers are writing, but the way things are going I don’t see that ever happening.

That's an orthogonal issue, though. Does it matter that the browser is running code "exactly as authored"? Even then, Typescript outputting ES2015+ modules is more often than not just stripping types. The distance between ES2015+ and Typescript today is often minuscule. Typescript has been pretty focused on sticking to TC39 Stage 3 so even features that aren't currently supported by browsers are most often tomorrow's features (not "next decade's features").

Plus, Typescript even gives you the option today of moving all your type checks to JSDoc comments and running as a type-checker only and you can feed the JS directly to browser as is, if that really is a concern that you think the browser should be using the same files that you are writing. (But again, does that really matter? And also, that isn't stopping you from using ES2015+ modules today. It doesn't matter if you are using a Typescript build step or not.)