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.

▲

bobbylarrybobby a day ago | parent | next [-]

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.

▲

prisenco a day ago | parent [-]

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

Do you have anything specific in mind?

▲

webstrand a day ago | parent [-]

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.

▲

brazukadev a day ago | parent | next [-]

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

▲

claytongulick a day ago | parent [-]

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.

▲

prisenco a day ago | parent [-]

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.

	▲	brazukadev a day ago \| parent [-]
		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.

▲

Calazon 20 hours ago | parent | prev [-]

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

▲

odie5533 a day ago | parent | prev | next [-]

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.

	▲	prisenco a day ago \| parent [-]
		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.

▲

junon a day ago | parent | prev | next [-]

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

▲

eric-p7 a day ago | parent | next [-]

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

▲

jeswin a day ago | parent | prev | next [-]

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

▲

prisenco a day ago | parent | prev | next [-]

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

▲

brazukadev a day ago | parent [-]

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

	▲	junon 16 hours ago \| parent [-]
		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.

▲

gedy 19 hours ago | parent | prev [-]

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

It's not a no-build option though.

▲

auxiliarymoose a day ago | parent | prev | next [-]

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.

▲

mb2100 a day ago | parent | prev | next [-]

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

▲

mmcnl 12 hours ago | parent | prev | next [-]

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

	▲	prisenco 12 hours ago \| parent [-]
		I'm referring to client-side javascript.

▲

fergie 19 hours ago | parent | prev | next [-]

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

▲

winrid a day ago | parent | prev | next [-]

TS is worth the build step.

▲

prisenco a day ago | parent [-]

JSDoc is TypeScript.

	▲	KPGv2 a day ago \| parent [-]
		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.

▲

pjmlp a day ago | parent | prev | next [-]

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.

▲

mmcromp a day ago | parent | prev | next [-]

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

▲

prisenco a day ago | parent | next [-]

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.

▲

johannes1234321 20 hours ago | parent [-]

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

	▲	prisenco 17 hours ago \| parent [-]
		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.

▲

xigoi 18 hours ago | parent | prev [-]

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.

▲

kellengreen 16 hours ago | parent | prev [-]

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