Live data from Hacker News

Writing JavaScript without a build system

jvns.ca

101–110 of 187 posts

Re: Writing JavaScript without a build system

#101

Earlier quoted context omitted.

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 dis…

Mostly because you want your project to just work. You've tested your project with a certain version of Node, and you want to ensure that you use the same exact version when you come back to the project in a year and want to perform some minor updates. You can set the node constraint in package.json, but that doesn't install the correct version of Node for you, unlike nvm.

Well that makes sense, as long as the developer running the code has nvm installed. Does nvm-windows read and install the versions in these nvmrc files? If it does your strategy is indeed pretty cool and I might start doing it myself. I wonder if there's any way to force specific versions of NodeJS without relying on nvm or some compatible tool.

edit: someone here in this thread suggested Volta [0] which seems literally like what I was looking for. No need for the nvmrc as it simply follows what's in the engine property of the package.json. Even better is that it's not a weird massive shell script but instead an actual program written in Rust. I'll have to try it out sometime.

[0]: https://volta.sh/

Re: Writing JavaScript without a build system

#102
post #99

Earlier quoted context omitted.

Looks like you need a -- it could map 'lit' to the CDN hosted version or to a relative path. More info: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...

Ah, thanks! I'd never encountered these before. It seems like a handy way to make my code match the code in documentation that assumes a Node environment.

No problem! There's also a polyfill if you need to support Safari:

https://github.com/guybedford/es-module-shims

Re: Writing JavaScript without a build system

#103
post #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.

I lint using Deno, single binary, no need to pollute the system with anything more than that.

Re: Writing JavaScript without a build system

#104

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…

I just want to point out there is a great alternative from Microsoft called `fast-design`[0] which provides a more fleshed out experience than Lit does, in terms of out of the box components.

It does have lower level packages if you don't want ready made components too

[0]: https://www.fast.design/

Re: Writing JavaScript without a build system

#105
Having been away from the JS world for ~5 years, it has been an eye-opener to come back to ES 2022 + VS Code + JSDoc + //@ts-check. I'm writing an application in one big HTML file with one big script tag and no build system, and actually kind of liking it. We'll see if it scales as far as I need it to, but for now I have something with decent DX and minimal bit-rot risk.

Re: Writing JavaScript without a build system

#106

Earlier quoted context omitted.

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.

I'm definitely a fan of Vite personally. You can tell the project prioritized a focus on developer experience outcomes and its very well executed in my opinion.

But the core package is ~27k SLOC with upwards of 40 dependencies. Thats an indirect, but poignant statement illustrating how much work goes into solving just a tooling problem. And while it may hide some of the overhead in its own abstraction, which it does a fantastic job of, the overhead is still there and it can still break in arcane ways.

I think the spirit of the question of "why do we even need Vite in the first place?" is whats really being explored in the original post.

I certainly don't shy away from build tools at all, but I do often try to start projects without them just as an exercise to see if they really ever end up being needed. Especially when its so easy to drop-in something like Vite after the fact if its necessary and/or clearly adds an outsized return on investment.

Re: Writing JavaScript without a build system

#107
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…

nvm is slow when changing directories, fnm is a fast drop-in replacement

How does fnm compare to volta [0] if you don't mind me asking? I see both are written mostly in Rust instead of being bloated shell scripts, although I'm not sure why choose one over the other.

[0]: https://github.com/volta-cli/volta

Re: Writing JavaScript without a build system

#108
post #5

Use npm to install libraries one time only. Try to use as few dependencies as possible. You don't need a framework--components are achievable without vue and react etc. Server side rendering and VDom are really not needed for most projects. Think of Programming in JavaScript, CSS and F5 rather than Typescript and SASS as the equivalent of Marcus Aurelius' Stoicism.

JavaScript and CSS are to Stoicism as Typescript and SASS are to _____?

Hedonistic excess.

Re: Writing JavaScript without a build system

#109
post #94

Earlier quoted context omitted.

Ah, gotcha. Thanks! > I generally don't consider installing from npm a build step. I also don't really consider rewriting import specifiers a build step - it's just locating files on disk. Sorry, maybe this is just my JS ignorance, but I don't understand how this runs without a build step. If I run npm -i lit, it puts lit into node_modules. But then if I put "import {LitElement, html} from 'lit';" into a JS file and…

When one writes `import 'lit'` the browser doesn't know where Lit is. This is called a bare module specifier vs an absolute import specifier: import '/home/user/project/node_modules/lit/index.js' A relative specifier: import '../node_modules/lit/index.js' Or a URL Specifier: import 'https://unpkg.com/lit?module' So you have four-ish options to tell the browser where to look for 'lit': 1. Use a server that will use th…

Cool, appreciate the thorough answer! I'll give Lit another look now that I understand how to run it buildless + static.

Re: Writing JavaScript without a build system

#110

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 Sha…

Web Components suck, Custom Elements is where it’s at ;) Just leave out the attachShadow.

https://github.com/adamghill/dlite/blob/main/src/component.j... ;)
Post reply on HN