Live data from Hacker News

Writing JavaScript without a build system

jvns.ca

41–50 of 187 posts

Re: Writing JavaScript without a build system

#41
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.

Why is this opinion resulting in negative points? It speaks to the sentiment of the post. Happy to discuss the topic constructively.

I'm not sure why its getting negative points, totally valid take to have.

In my own experience though, python is far from batteries included. Ill tackle one vertical: packaging & dependency management. Historically you didn't get much out of the box for this problem.

You have pip, virtualenv, virtualenvwrapper, pyenv, pyvenv, pyenv-virtualenv, pipenv, et al. Almost a dozen different, and sometimes redundant, solutions for a problem that historically python didn't solve natively for free. Poetry has drastically improved this problem, but not enough to really distinguish python from JS in a meaningful way IMO.

Re: Writing JavaScript without a build system

#42
post #27

One of my favourite hacks I did recently was in 2020 when soup.io was unexpectedly discontinued with short notice; to promote my scraping framework, Skyscraper, I quickly whipped up a content downloader. It produced an archive of assets, and I also added a rudimentary browser. The beauty of it was that it was a single static HTML file, copied verbatim to the archive. The only moving part, apart from the actual images…

> I was amazed at how far I could get with such a rudimentary tooling.

Are you just 1 person working on a project?

A lot of "best practices" aren't particularly needed when you're flying solo and know your code and mental processes inside and out.

Where this starts to get hairy is when you have multiple developers all trying to understand one person's mental model of how the code is structured, all in one file that they have to work in.

Re: Writing JavaScript without a build system

#43
That node SSL issue is such a doozy.

The fact that they added a breaking change to the way node runs, with no information in the error message about how to fix it, or even what to fix is unbelievable. We're still running node 16 just because some libraries don't work with the new SSL system.

It's a massive pain.

Re: Writing JavaScript without a build system

#45
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 usable without build tools. We support plain JS (in addition to TypeScript). Our libraries work straight from CDNs like Unpkg. When installed locally you can use a dev server that rewrites bare module specifiers or use an 8-line import map to make all of our core packages importable (we carefully keep all of our import specifiers compatible with the web and compact import maps). Components are inspectable with regular DevTools. You can even write components right in DevTools, or in a script tag in plain HTML.

I honestly wish this weren't a unique selling point of Lit, but as far as I can tell, of the "major" frameworks or component libraries out there (including React, Vue, Angular, Solid, Ember, Svelte, Stencil, Preact, and more) we're the only ones that fully work with plain JS within our regular mainstream usage patterns.

Re: Writing JavaScript without a build system

#46
When I was learning HTML and JS in the early 2000s, most web pages had hand-written source code, and most JS I encountered was hand-crafted and unminified. So I learned programming by just reading the code of the pages I was on.

That's the main reason for me not to use a build system. You lose that "transparency" and accessibility of the code. With "raw" HTML/JS, the user can just copy paste your HTML/JS (often it was just 1 file for both combined!) into notepad, save as HTML and have their own website/"app"!

At least, that's how I felt until I got comfortable with TypeScript, and now I will refuse to use raw JS even for small projects... Alas! (Would be nice if V8 could strip type annotations and just run the plain JS hidden underneath... would also help with pasting TS snippets into the dev console!)

Re: Writing JavaScript without a build system

#47
post #33

Getting older projects to run was a huge pain for me when I started working with JavaScript, but I have found two easy steps to get around this: 1. Use nvm + an .nvmrc file in your project to pin the major version of Node.js you are using. I recently got a five year old Node 8 project up and running with no issues using this method. 2. Try to avoid packages that has binary dependencies (like node-sass). 99% of binary…

Why rely on nvm to pin the NodeJS version you are using? That's natively supported as a field in your package.json [0], assumimg you're using npm/yarn/pnpm (you are).

Example:

  {
    "engines": {
      "node": ">=0.10.3 
Also, god forbid you are actually running anything using Node 8 and whatever dependencies you have there, that's a recipe for security disaster.

The truth is that to use the NodeJS ecosystem we must have the discipline to keep projects up-to-date. I personally have a policy to update all my NodeJS projects at least yearly, even if they are abandoned, this includes all dependencies and the NodeJS version. Because I do it often most of the times there are not many problems to keep it working, and consequently updating is fast, but if I leave it for a few years and then come back I'll be in for a (bad) surprise.

[0]: https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...

Re: Writing JavaScript without a build system

#49
It seems just a few years ago when I was testing out an early version of react, and it had the JSX compiler as a header include. Worked well enough, and with more modern JS supported by default, I wouldn't mind a newer version of this.

Instead of the increasingly silly attempts of coming up with weirder ways of doing server side rendering.

Re: Writing JavaScript without a build system

#50
post #25
post #10

> I’d love more tips for no-build-system javascript 1. MDN has a comprehensive guide on JavaScript modules [0] 2. A build system free way to build interactive websites could be to combine libraries like htmx[1] and or lit[2] or just the sub package lit-html[3]. Or just go with native web components and a bit of AJAX. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... [1] https://github.com/bigskysoft…

+1 for Lit. It seems like they're mostly recommending that you use TypeScript and a build system, but you can 100% still just pull the library from a CDN with native JS modules [0]. It leans into a lot of the web components spec so the library is pretty small, and the templating system is just ES6 tagged template literals parsed by the browser's DOM parser and any embedded variables are updated dynamically [1]. [0] h…

I think Lit is still recommending using web dev server (https://modern-web.dev/docs/dev-server/overview/), which no, its not a build system, but still a bit of a departure from a simple web server. And that's only needed to resolve imports that aren't a full relative path (like if I want to import Lit, I don't have to do import node_modules/lit/whatever). Someone else mentioned import maps here, and it's now supported in all browsers if you include the Safari preview release. I haven't tried it yet because I've been hung up on it being Chrome only until now, but it should complete the no-build experience. Except yeah, Typescript, but if you use it, you can just leave it watching in the background without much intervention.
Post reply on HN