Live data from Hacker News

Writing JavaScript without a build system

jvns.ca

71–80 of 187 posts

Re: Writing JavaScript without a build system

#71

I wonder how hard it would be for Browsers to natively strip TypeScript syntax from the .ts files without checking and run them as .js

So no compile time checks and no runtime checks? What would the advantage of types be?

With decent dev tooling, you are getting edit-time checks equivalent to compile-time checks (the only difference is that there is no compilation after the checking), so there’s no loss. The advantage of compile-time checking has nothing to do with “compile time” except that compile time is inherently before runtime, and edit time is even earlier.

Re: Writing JavaScript without a build system

#72
post #57
post #21

Earlier quoted context omitted.

The problem with build systems isn't the existence of a build step but the necessity of the build system and its configuration. Typescript is baffling-ly complex to use compared to something like python.

> tsc build What's complex about that?

To be fair, tsconfig.json has a ton of options, and you often can’t just use the defaults. It’s necessarily complex, unfortunately.

Re: Writing JavaScript without a build system

#74

If anyone's looking for something like a framework that works with buildless workflows you might check out the project I work on: Lit ( https://lit.dev ) Lit gives you reactive components, declarative HTML templates, runtime encapsulated DOM and styles, interoperability with frameworks and HTML via web components, and a lot more - with no required build tools at all. We take great care to make sure our libraries are…

Thanks for the reference, interesting, I will have a look.

vuejs can work without build system though. it's mentioned in the article, and I used to wwork that way. Eventually i made my own (minimal) build system though using quickjs and esbuild. Precompiling templates and minimising can be useful.

Re: Writing JavaScript without a build system

#75
While I think the goal of being able to write JS without a build system is fine, I'd still never skip setting up a build system. Static analysis, formatting, linting, optimizing, testing, and other such parts are way to valuable to ever give up. The ability to run in a dev environment without a build is valuable from a performance and feedback loop standpoint, but at the end of the day, the tooling needs to be there.

Re: Writing JavaScript without a build system

#76
The fact that ES2015 was not backward compatible opened the Pandora's box to the plethora of build-system-only libs. Now the browser and your application are too distant. Exposes the dev to a world of tooling but increases friction on building, points of failure and complexity. Recently we are trying to fit them again and this post is a useful guide to do it

Re: Writing JavaScript without a build system

#77
post #6

All those extraneous elements to Javascript are a real turn-off. Python: batteries mostly included. Javascript: feels like you need to drag a dozen suitcases along anytime you embark on any non-trivial project.

My own experience is that anytime you have a situation where the included batteries aren't enough (which has been every time), you're left to figure out eggs vs wheels vs distutils vs setuptools vs easyinstall vs pip vs pip3 vs pip3.7 vs pip3.8 vs pipx vs pip-tools vs poetry vs pyenv vs pipenv vs virtualenv vs venv vs conda vs anaconda vs miniconda.

Re: Writing JavaScript without a build system

#78
I'm in the same camp and never want to run a build process for JavaScript ever again. I've been slowly improving https://dlitejs.com/ which is a minimal (5kB minified + gzipped) JavaScript framework which works great loaded from unpkg. It's pretty crazy to see how lean a framework can be nowadays (even with two-way binding, directives, and event binding) when leveraging newer standards like Web Components and the Shadow DOM.

Re: Writing JavaScript without a build system

#79
My strategy for dealing with bit-rotting builds is to use yarn with plug-n-play. It goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo. Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade.

The trade off is that because it’s actually reading JS from the zip files at runtime, a lot of Node packages don’t play nicely with it. Once you get things set up, it’s great, but getting there can be exhausting for a hobby project.

Re: Writing JavaScript without a build system

#80

Use Vite and don't look back. It's so refreshing compared to Webpack.

You’re missing the entire point. That’s still a build process and still has additional overhead for both development and deployment.

Have you used Vite before? If you have a simple project it's surprisingly fast and painless. What's the "additional overhead" you're talking about? I experienced that with Webpack, but not Vite.

The author even shouts out esbuild as being "a little more stable", which Vite uses under the hood.

Post reply on HN