After reading the article I get where they’re coming from when they say “simple”. But before reading the article I was really hoping for something that did not involve npm, let alone build steps like tsc and esbuild. So like PHP or something. If you add nodejs and javascript to the post tags others might not be disappointed like I was. :)
I would be curious/interested to see an example of good practices around this concept of simple. Depending of the level of complexity, I am also waiting to see where _hyperscript ends up.
I appreciate the objective: bootstrap a new frontend project without incidentally dragging in ~400MB of NPM dependencies is hard! I enjoy writing frontend code with all the niceities (TypeScript + language server, hot module reloading, automatic transpilation) but share the original author’s disdain for all the invisible bits that get dragged along.
OTOH, there’s no easy way around the intrinsic complexity of the language stack for modern JS projects, much less package formats, hot-reloading, etc.
Importing a new library? Better make sure your tsc config emits and consumes the right kinds of JS modules. And no, there isn’t a single “works with every library” setting, no matter how many Webpack, Vite, or esbuild config tweaks you throw in there. Everything involves tradeoffs that will leave certain encapsulation + use patterns unavailable.
Hence being very interested in Deno as not just Yet Another V8 Wrapper but as a single, opinionated chokepoint for how modules can be packaged and imported by URL…and then they added full NPM support (b/c of course, right?) and brought back the entire mess above aside from the transpiler from TS->JS (b/c Deno does that).
If you want to use “classic” RequireJS packages, “modern” ESM-based NPM imports, and “native” ESM-imports-by-URL ala browser + Deno you’re gonna spend some “quality time” tweaking compiler + bundler settings. If you want to export code to all of those: good luck.
I’ve spent literally weeks trying to wrap code that took me ~days to build more times than I’m entirely comfortable admitting.
So: I love the relatively minimalist setup being described here, and (sadly) think that the complexity is unavoidably going to ramp as soon as 3rd-party dependencies get in the mix. (And let’s be honest: no one would deal with all this gomi if they didn’t want access to NPM, the single largest archive of potentially-interoperable software source packages ever created. We put up with a lot to tap into those hundreds of millions of lines of code.)
It says simple in the title but then pulls in NPM and even TypeScript - nice bait.
There’s probably no way around npm, but TypeScript is absolutely not worth the trouble for your side project/hacks, just skip it. Embrace Vanilla JS. If you are coming from a background of solid typed languages, TypeScript is not what you think it is. It prevents almost none of the JS problems, you will have plenty of runtime errors. On the contrary, it gives you a fake sense of safety that will bite you over and over again. Embrace Vanilla JS and learn its quirks, instead of learning a leaky, thin veneer on top of it that brings more problems than it solves (in side projects / hacks).
Wow, couldn’t disagree more. As a static-language guy, discovering TypeScript made me willing to work on browser programming again; it is so much better than plain JS. It doesn’t catch all runtime type problems, but I find its type-checking catches a ton of issues at compile time, enough that I have fairly few runtime issues.
But if you’re again looking to stay simple and predictable, I have been happy with Preact, which is an API-compatible implementation of the industry-dominant React framework that is only 3kb.
I tried some Preact examples a few weeks ago. I liked it, but I had to laugh at the total disconnect between its touted 3KB runtime size vs. the 350 megabytes of stuff that got downloaded into the node-modules directory when I installed it. That’s a factor of 100,000! I took a quick peek inside there and the single biggest items looked to be five or six copies of the TypeScriot compiler that various modules had as dependencies.
After reading the article I get where they’re coming from when they say “simple”. But before reading the article I was really hoping for something that did not involve
npm, let alone build steps liketscandesbuild. So like PHP or something. If you add nodejs and javascript to the post tags others might not be disappointed like I was. :)For simple, stable stuff I have settled on plain Javascript and MVC. It removes the need for name, a bundle, a framework, and all the rest.
I would be curious/interested to see an example of good practices around this concept of simple. Depending of the level of complexity, I am also waiting to see where _hyperscript ends up.
Here’s a collection of pedagogical examples: https://github.com/madhadron/mvc_for_the_web An example in the wild would be the hex editor I embedded in this page: https://madhadron.com/programming/serializing_data.html
I appreciate the objective: bootstrap a new frontend project without incidentally dragging in ~400MB of NPM dependencies is hard! I enjoy writing frontend code with all the niceities (TypeScript + language server, hot module reloading, automatic transpilation) but share the original author’s disdain for all the invisible bits that get dragged along.
OTOH, there’s no easy way around the intrinsic complexity of the language stack for modern JS projects, much less package formats, hot-reloading, etc.
Importing a new library? Better make sure your
tscconfig emits and consumes the right kinds of JS modules. And no, there isn’t a single “works with every library” setting, no matter how many Webpack, Vite, or esbuild config tweaks you throw in there. Everything involves tradeoffs that will leave certain encapsulation + use patterns unavailable.Hence being very interested in Deno as not just Yet Another V8 Wrapper but as a single, opinionated chokepoint for how modules can be packaged and imported by URL…and then they added full NPM support (b/c of course, right?) and brought back the entire mess above aside from the transpiler from TS->JS (b/c Deno does that).
If you want to use “classic” RequireJS packages, “modern” ESM-based NPM imports, and “native” ESM-imports-by-URL ala browser + Deno you’re gonna spend some “quality time” tweaking compiler + bundler settings. If you want to export code to all of those: good luck.
I’ve spent literally weeks trying to wrap code that took me ~days to build more times than I’m entirely comfortable admitting.
So: I love the relatively minimalist setup being described here, and (sadly) think that the complexity is unavoidably going to ramp as soon as 3rd-party dependencies get in the mix. (And let’s be honest: no one would deal with all this gomi if they didn’t want access to NPM, the single largest archive of potentially-interoperable software source packages ever created. We put up with a lot to tap into those hundreds of millions of lines of code.)
It says simple in the title but then pulls in NPM and even TypeScript - nice bait. There’s probably no way around npm, but TypeScript is absolutely not worth the trouble for your side project/hacks, just skip it. Embrace Vanilla JS. If you are coming from a background of solid typed languages, TypeScript is not what you think it is. It prevents almost none of the JS problems, you will have plenty of runtime errors. On the contrary, it gives you a fake sense of safety that will bite you over and over again. Embrace Vanilla JS and learn its quirks, instead of learning a leaky, thin veneer on top of it that brings more problems than it solves (in side projects / hacks).
Wow, couldn’t disagree more. As a static-language guy, discovering TypeScript made me willing to work on browser programming again; it is so much better than plain JS. It doesn’t catch all runtime type problems, but I find its type-checking catches a ton of issues at compile time, enough that I have fairly few runtime issues.
I tried some Preact examples a few weeks ago. I liked it, but I had to laugh at the total disconnect between its touted 3KB runtime size vs. the 350 megabytes of stuff that got downloaded into the node-modules directory when I installed it. That’s a factor of 100,000! I took a quick peek inside there and the single biggest items looked to be five or six copies of the TypeScriot compiler that various modules had as dependencies.
lol, I was hoping for: