7 ms·

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

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.

auxiliarymoose 10mo ago
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.
bobbylarrybobby 10mo ago
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.
- emseetech 10mo ago
  I haven't run into any steps that require one, there's always alternatives. Do you have anything specific in mind?
  - webstrand 10mo ago
    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 10mo ago
      If there is one thing I don't miss using WebComponents is JSX. lit-html is much, much better.
      - claytongulick 10mo ago
        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.
        emseetech 10mo ago
        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 10mo ago
        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 10mo ago
      I recently used Preact and HTM for a small side project, for the JSX-like syntax without a build step.
junon 10mo ago
Webcomponents are a pain in the ass to make, though. That is, sufficiently complex ones. I wish there was an easier way.
- emseetech 10mo ago
  They could have better ergonomics and I hope a successor that does comes out but they're really not that bad.
  - brazukadev 10mo ago
    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 https://github.com/tc39/proposal-signals - And this proposal: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069 which is basically lit-html in the browser
    - junon 10mo ago
      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.
- eric-p7 10mo ago
  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 https://github.com/Vorticode/solarite
- jeswin 10mo ago
  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 https://github.com/webjsx/magic-loop
mmcromp 10mo ago
Why? The half a second for the HMR is taking up too much your day?
- emseetech 10mo ago
  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 10mo ago
    > 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.
    - emseetech 10mo ago
      The Space Jam website from 1996 still renders perfectly almost 30 years later. https://www.spacejam.com/1996/ 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 10mo ago
  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.
odie5533 10mo ago
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.
- emseetech 10mo ago
  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.
winrid 10mo ago
TS is worth the build step.
- emseetech 10mo ago
  JSDoc is TypeScript.
  - KPGv2 10mo ago
    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 10mo ago
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.
mb2100 10mo ago
This. Or use ts-blank-space if you prefer TypeScript over JSDoc. That's what we do in https://mastrojs.github.io https://mastrojs.github.io
fergie 10mo ago
> 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.
kellengreen 10mo ago
Came here to write this exact sentiment. Not everything needs a massive build pipeline.
mmcnl 10mo ago
You don't need a build step anymore with TypeScript since Node 24.
- emseetech 10mo ago
  I'm referring to client-side javascript.

auxiliarymoose 10mo ago

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.

bobbylarrybobby 10mo ago

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.

emseetech 10mo ago
I haven't run into any steps that require one, there's always alternatives. Do you have anything specific in mind?
- webstrand 10mo ago
  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 10mo ago
    If there is one thing I don't miss using WebComponents is JSX. lit-html is much, much better.
    - claytongulick 10mo ago
      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.
      - emseetech 10mo ago
        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 10mo ago
        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 10mo ago
    I recently used Preact and HTM for a small side project, for the JSX-like syntax without a build step.

junon 10mo ago

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

emseetech 10mo ago
They could have better ergonomics and I hope a successor that does comes out but they're really not that bad.
- brazukadev 10mo ago
  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 https://github.com/tc39/proposal-signals - And this proposal: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069 which is basically lit-html in the browser
  - junon 10mo ago
    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.
eric-p7 10mo ago
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 https://github.com/Vorticode/solarite
jeswin 10mo ago
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 https://github.com/webjsx/magic-loop

mmcromp 10mo ago

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

emseetech 10mo ago
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 10mo ago
  > 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.
  - emseetech 10mo ago
    The Space Jam website from 1996 still renders perfectly almost 30 years later. https://www.spacejam.com/1996/ 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 10mo ago
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.

odie5533 10mo ago

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.

emseetech 10mo ago
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.

winrid 10mo ago

TS is worth the build step.

emseetech 10mo ago
JSDoc is TypeScript.
- KPGv2 10mo ago
  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 10mo ago

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.

mb2100 10mo ago

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

fergie 10mo ago

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

kellengreen 10mo ago

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

mmcnl 10mo ago

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

emseetech 10mo ago
I'm referring to client-side javascript.