[fleddr]

"Sure, it works well enough for the example shown in the article, but won't work well beyond this."

Sigh...the entire bloody point of the author is to use this for light projects, to scale the sophistication of the setup gracefully. With very obvious benefits: easy to understand, not linked to any setup so it works forever, interoperable and transferable.

Typescript isn't universally important for development. It has its advantages for large projects with many developers but it's in no way essential. Most web projects don't use Typescript and the very idea that it's a must-have only a few years old and quite opinionated.

Likewise, Babel isn't important either. You don't need to use some futuristic JS feature on your simple project, you can just stick to well supported ones, thus not needing Babel.

"I have been doing web development as a hobby and professionally for well over a decade and have seen too much of this."

I've been doing web development since 1996, so that makes for 27 years, should such obnoxious statement make anyone's opinion more important. If you need to piss on the idea of somebody scaling a web architecture proportionally to actual needs, you should reconsider who is the "smart" one.

[MrJohz]

I think the criticism is exactly of that ability to scale though. This setup is ineffective but manageable at the individual scale, but it's going to get more complicated as soon as anyone else is involved, or if the project lives longer than six months and needs to be updated, or if you wanted to add any dependency more complicated than a single file.

The other side of it is it's not really clear what the author is gaining here. They're still reliant on NPM package structures, and they're still pulling in third party dependencies. They're just doing it in an overly complicated way.

In contrast, this is what I'd do to get to the same point the author does in this example: (I'm going off the top of my head here, and I don't have a computer to check this, but it should just work.)

    mkdir myproject/ && cd myproject/
    npm init # although I think just doing echo '{}' > package.json is enough here
    npm install -D vite
    npm install solid-js
    # write some actual code
    $EDITOR index.html
    npx vite

And now you've got basically everything that the author has, but you didn't need to write your own shell script to download modules, you don't need to do all the import mapping yourself, and it's much easier to graduate from this simple setup if you ever do need to.

[fleddr]

My objection is that the author is quite clearly describing this as a bottom-up, small scale approach. Criticizing it as an inadequate approach for something much larger is unwarranted, as nowhere was the claim made that this scales up infinitely.

What is gained? No build step, as the article also clearly mentions. Your alternative approach goes against the goal of the author. Which is to not have a tool chain. "You can also do this by installing these 17 tools and 30 dependencies" is quite missing the point.

[MrJohz]

I don't disagree that it's small scale approach, it's just the language of "bottom up" and "scaling gracefully" that I disagree with. The setup in the article will work only at very small scales, and then you'll probably have to rewrite most of it. The setup I provided works at very small scales as well (arguably better), but can be progressively updated as needed (but only as needed - for example, there's no JSX support for now, but it could be added later if it became necessary).

And in a situation like this, I don't know that I understand the value in avoiding a build step simply for the sake of being able to say you don't have one. This isn't one of those situations where you're saving time by removing the build step because it's not actually building anything here, just rewriting a few paths and adding essentially the same import map. It's probably even quicker overall because it does the reload for you.

Likewise, you're overstating what tools are actually necessary here. It's not "17 tools and 30 dependencies", it's two: one (NPM) to manage dependencies, and the other (vite) to provide the dev server and set the imports up correctly. Everything apart from that is up to you to install as you wish.

[toomanydoubts]

>Which is to not have a tool chain.

In my opinion that boat sailed the moment he implemented `download-package`.

[kitsunesoba]

> Likewise, Babel isn't important either. You don't need to use some futuristic JS feature on your simple project, you can just stick to well supported ones, thus not needing Babel.

I would say even many moderately complex sites/apps have no need for [shiny new feature X]. These days new JS features tend more towards nice-to-have than they do essential. Back in the days when jQuery was ubiquitous it was a different story but things have improved quite a bit.

[fleddr]

Agree, Babel is bullshit in most cases these days. It's for people wanting to use some syntactic sugar that they just learned about 3 days ago.

[WorldMaker]

I think a lot of Babel is for people who haven't kept up with caniuse statistics and don't realize that the "low water mark", the "well supported baseline", has moved to something very close to ES2021 or more recent. To be fair, Babel is explicitly targeting some of those developers that prefer ignorance and don't want the mental overhead of actually knowing what browsers support and like having "just use the presets!" attitude. I think some of them would be surprised how extremely little most of the standard presets do in 2023 because there are increasingly few things to downlevel.

I have especially long been of the strong opinion that you never need Babel and Typescript. There's nothing that Typescript supports that it can't downlevel itself and tslib is a much tinier runtime dependency (if you choose to have Typescript import it rather than embed it in place) than any of Babel's runtimes (including their core-js dependencies) even when a bundler is tree shaking most of it out today (because caniuse statistics say yagni).

It still amuses that for instance the create-react-app "best practice" in its Typescript template is to use Babel for type stripping and downleveling and delegate the Typescript compiler only to type checking. No wonder people find modern pipelines bloated. To be fair, I get why CRA likes the conceptual simplicity that both of their core templates use the same Babel presets and pipelines given to them Typescript is still the opt-in "extra".

(Also, I have no problem with esbuild doing my Typescript type stripping and running tsc as a separate pass in esbuild pipelines, but esbuild isn't pretending to do a lot of unnecessary downleveling in 2023 and adds no further runtime beyond the parts of tslib it bundles for you. It's mostly just Babel's extreme complexity that I find redundant and unnecessary and its labyrinth of presets that don't actually do much in 2023 but give the impression that they do.)

[technion]

Es6 arrow functions are a good example of this. They have been around for a long time and work in most browsers, but people learned they need babel to transpile them out for internet Explorer. People dropped ie support but the knowledge "we need babel for browser compatibility " remained an entrenched fact.

[WorldMaker]

Yeah, it's relevant to remember that arrow functions were defined in ES2015 (eight years ago) and like I said most browsers people are using are caught up through at least ES2021. The nice thing about the ES2015 year-based nomenclature (as opposed to the people still calling it "ES6") is that you can do a quick reasonable first approximation of caniuse statistics off hand with "is that standard at least two years old?" Arrow functions are old.

[nextaccountic]

Here's another thing: if you want to grow from this exact setup, use deno. It has support for import maps and don't require a bundler or a separate compilation step for typescript

https://deno.land/manual@v1.30.3/basics/import_maps

Maybe add aleph too (which is similar to nextjs)

https://alephjs.org/

Deno won't require nearly as much tooling as nodejs, but it still has tooling for the cases you need it.

[klysm]

Why scale “gracefully” though? The boilerplate of bundlers and package managers isn’t difficult or time consuming in practice. Sure it’s a lot of code and bloat but it isn’t actually hard.