Hacker News Reader

Comment by emseetech | Hacker News Reader

I'm a fan of anything that allows me to build with javascript that doesn't require a build step.

Modern HTML/CSS with Web Components and JSDoc is underrated. Not for everyone but should be more in the running for a modern frontend stack than it is.

View on HN

On the one hand I can see the appeal of not having a build step. On the other, given how many different parts of the web dev pipeline require one, it seems very tricky to get all of your dependencies to be build-step-free. And with things like HMR the cost of a build step is much ameliorated.

I haven't run into any steps that require one, there's always alternatives.

Do you have anything specific in mind?

Anything that uses JSX syntax, for instance.

Any kind of downleveling, though that's less important these days most users only need polyfills, new syntax features like `using` are not widely used.

Minification, and bundling for web is still somewhat necessary. ESM is still tricky to use without assistance.

None of these are necessary. But if you use any of them you've already committed to having a build step, so adding in a typescript-erasure step isn't much extra work.

If there is one thing I don't miss using WebComponents is JSX. lit-html is much, much better.

It's such a lovely and simple stack.

No Lit Element or Lit or whatever it's branded now, no framework just vanilla web components, lit-html in a render() method, class properties for reactivity, JSDoc for opt-in typing, using it where it makes sense but not junking up the code base where it's not needed...

No build step, no bundles, most things stay in light dom, so just normal CSS, no source maps, transpiling or wasted hours with framework version churn...

Such a wonderful and relaxing way to do modern web development.

I love it. I've had a hard time convincing clients it's the best way to go but any side projects recently and going forward will always start with this frontend stack and no more until fully necessary.

This discussion made me happy to see more people enjoying the stack available in the browser. I think over time, what devs enjoy using is what becomes mainstream, React was the same fresh breeze in the past.

I recently used Preact and HTM for a small side project, for the JSX-like syntax without a build step.

I have not written a line of JavaScript that got shipped as-is in probably a decade. It always goes through Vite or Webpack. So the benefit of JS without a build step is of no benefit to me.

Dare to dream and be bold.

Seriously, start a project and use only the standards. You'll be surprised how good the experience can be.

Webcomponents are a pain in the ass to make, though. That is, sufficiently complex ones. I wish there was an easier way.

They could have better ergonomics and I hope a successor that does comes out but they're really not that bad.

web components need 2 things to be great without external libraries (like lit-html):

- signals, which is currently Stage 1 https://github.com/tc39/proposal-signals

- And this proposal: https://github.com/WICG/webcomponents/issues/1069 which is basically lit-html in the browser

It's a shame Surplus (Adam Haile's, not my succession of it) isn't cited nor is he mentioned, given that at least two of the listed frameworks were heavily and directly inspired by his work. S.js is probably one of the most incredible JavaScript libraries I've used that should be the reference for a signal API, in my opinion.

I've built Solarite, a library that's made vanilla web components a lot more productive IMHO. It allows minimal DOM updates when the data changes. And other nice features like nested styles and passing constructor arguments to sub-components via attributes.

https://github.com/Vorticode/solarite

It's ok now, at least for me. There are still challenges around theming and styling because of styling boundaries (which makes Web Components powerful, but still). A part of it is about tooling, which can be easier to improve.

Try my tiny web components lib if you want to keep JSX but not the rest of React: https://github.com/webjsx/magic-loop

Svelte has a pretty nice support for this via https://svelte.dev/docs/svelte/custom-elements

It's not a no-build option though.

I find Web Components aren't as much of a pain to write if you ignore the Shadow DOM. You don't need the Shadow DOM, it is optional. I don't think we are doing ourselves too many favors in how many Web Component tutorials start with or barrel straight into the Shadow DOM as if it was required.

Agreed on native HTML+CSS+JSDoc. An advantage in my use-cases is that built-in browser dev tools become fluid to use. View a network request, click to the initiator directly in your source code, add breakpoints and step without getting thrown into library internals, edit code and data in memory to verify assumptions & fixes, etc.

Especially helpful as applications become larger and a debugger becomes necessary to efficiently track down and fix problems.

This. Or use ts-blank-space if you prefer TypeScript over JSDoc. That's what we do in https://mastrojs.github.io

TS is worth the build step.

JSDoc is TypeScript.

It is TypeScript in the same way my rear end is the Grand Canyon: they are somewhat isomorphic but one is much less pleasant to look at.

I was already doing that in 2010, with the JSDoc tooling in Eclipse and Netbeans back then.

However I don't get to dictate fashion in developer stacks.

> Modern HTML/CSS with Web Components and JSDoc is underrated.

I've been a front end developer for 25 years. This is also my opinion.

You don't need a build step anymore with TypeScript since Node 24.

I'm referring to client-side javascript.

Why? The half a second for the HMR is taking up too much your day?

No, because layers of abstraction come at a cost and we have created a temple to the clouds piled with abstractions. Any option to simplify processes and remove abstractions should be taken or at least strongly considered.

Code written for a web browser 30 years ago will still run in a web browser today. But what guarantee does a build step have that the toolchain will still even exist 30 years from now?

And because modern HTML/CSS is powerful and improving at a rapid clip. I don't want to be stuck on non-standard frameworks when the rest of the world moves on to better and better standards.

> Code written for a web browser 30 years ago will still run in a web browser today.

Will it? - My browser doesn't have document.layers (Netscape) It seems to still have document.all (MSIE), but not sure it's 100% compatible to all the shenanigans from the pre-DOM times as it's now mapped to DOM elements.

The Space Jam website from 1996 still renders perfectly almost 30 years later.

https://www.spacejam.com/1996/

Those (document.layers and document.all) were both vendor-specific, neither were part of the w3c. I don't recommend ever writing vendor-specific code.

The w3c and standards have generally won so it's easier than ever to write to the standard.

Having all your code go through a multi-step process that spits out 30 different files makes it impossible to know what’s really happening, which I’m uncomfortable with.

Came here to write this exact sentiment. Not everything needs a massive build pipeline.

Reply on news.ycombinator.com