Hacker News Reader

Comment by spankalee | Hacker News Reader

This supports all kinds of non-platform-standard features that may tie your project to this specific bundler, but will tie them to bundlers in general.

It would be much better to have projects that work without bundlers, that can use them as an optimization step.

View on HN

Bundlers also tie clients to developers without them realizing. I work for a webhost and Many people still assume that if they have access to their hosting then they have their "source code". We see often that people migrate a sites after breaking ties with a developer only to find what they have may function, but is unmaintainable.

Sounds like a contractual thing, not like a bundler thing. The client should always include a clause into the contract that the client must hand all work over after closing the partnership.

Yep, just ask for their source code, don't presume that the hosted work is sufficient.

Yeah this is no different than receiving a binary rather than the source, bundled code is close enough for this comparison (though it would be probably easier to unbundle code rather than decompile a binary, it’s still a fair amount of work)

Client should ask, but ideally this will be written into the contract beforehand. I don't mind sharing source code but not for re-use in other projects.

> The client should always include a clause into the contract that the client must hand all work over after closing the partnership.

I think you might have meant that the developer should hand over all source material after the agreement has been fulfilled.

Indeed, thanks.

The same could be said for compilers, too. Deployed binaries and code have never been the "source" of your app.

Source code costs extra, everyone knows that! Get the bag!

You'd struggle to extract a maintainable codebase from a C# or Golang web server after the fact too. As an industry we've been making simple websites on shared hosting for over a generation, clients who ignore the entire world of information about the dangers and pitfalls on this topic are squarely to blame as negligent. It ranks up there with not paying taxes and then acting shocked when the government comes knocking.

While Javascript could potentially be contractually mandated to be written in a way to facilitate production codebase recovery, if you knew enough to ask for that you wouldn't, you'd require them to use your source control and to provide build/deployment scripts instead.

As soon as the browser specs catch up to what the bundlers are doing I’d drop them in a heartbeat. Not holding my breath though

You can get pretty far by using importmaps, you would not have treeshaking or a single bundled file, but it works pretty well. JSDoc can be used to add types to your project (that can be typechecked using typescript). I'm currently building a hobby project using preact, htm and jspm for packages. It's pretty nice to just start building without starting a build tool, having to wait for it to finish, make sure it's not crashed etc. But indeed, I won't use this for production.

The only thing I'm still missing is an offline JSPM/esm.sh.

For offline esm.sh you can use service workers cache, no?

Also why not use this config in production? Http2 should give the same performance for multiple small files than a big bundle and it's much better to cache

It works well for a small website. For anything that requires more than a few dependencies, the package management is hell and load time will be insufferable. Also, not everything you grab from npm can just run in the browser even if written in ESM -- things get complicated quickly.

Websites using lots of JavaScript were built pre-npm and bundlers, the load times were not insufferable. If anything today it would all be easier.

You do have tree shaking: the browser only loads the modules that are imported. Only import what you use (and don't use barrel files) and you're golden.

If you don't have any external library (e.g. npm) dependency you're golden. Unfortunately, this means that you now have to write all your code from scratch, which is ok if you're writing a very light website, but it's unsustainable if you do anything non-trivial.

Plenty of npm dependencies are published as browser-compatible standard JS modules.

You mean EcmaScript Modules? The situation is quite complicated. Some libraries don't publish ESM at all (React doesn't iirc), and the ones that do often publish CJS and ESM side by side. In that case, you need to read the package.json and decide which file to use, which is not trivial (see Conditional Exports for example: https://nodejs.org/api/packages.html#conditional-exports). In almost any non-trivial case you need to write tooling to make it work, so you might as well use a bundler.

The browser specs largely have.

CSS has advanced enough that I haven't used Less or Sass in many years. Modules make loading easy. Import maps let you use bare module specifiers (or you could use a simple transform in a dev server). CSS modules let you import CSS into JavaScript.

I never use a bundler during development.

Imagine if you could just scp your source code tree onto a CDN and it would automatically bundle it based on how clients import it.

Isn't this the idea behind CI/CD wotkflows?

Yes, the difference is I'd like to offload the work of having to think about optimising code delivery.

This sounds similar to https://esm.sh/

Unfortunately singleton peer dependencies (like react) are quite complicated with esm.sh. When esm.sh rewrites a module to import react from the cdn, it kinda "decides" which version of react is it at the moment the module is built on the CDN for the first time. That's why react is "special" and gets a stable build in esm.sh (essentially pointing to a fixed version no matter which version you specify): to avoid the dreaded "two copies of react" error.

Yep definitely. There are a few of these like JSPM that help convert libraries into browser-importable URLs.

Reply on news.ycombinator.com