Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
web-starter
Starter for Fastify + Web Components/Lit Web App. Includes Reload and web server restart on dev mode.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> keep the UI in sync with state
This is absolutely true, however there are some newer tools that are appearing that make this much easer with vanilla html - htmx, hyperscript, alpine.js for example.
These newer tools are all made possible due to the “new”(ish) MutationObserver api, it allows you to in the intercept new dom elements being placed into the document. These libraries let you simple decorate your “real” html with extra attributes enabling easer client side state management.
https://htmx.org/
https://hyperscript.org/
https://alpinejs.dev/
I believe you are talking about this hyperscript: https://hyperscript.org/
Whereas the parent post is talking about: https://github.com/hyperhype/hyperscript
Unfortunately, the creator of https://hyperscript.org/ hijacked the name even when the term "hyperscript" is still used to refer to dominictarr's project and the `h('p', 'hello world') API of declaring templates in JavaScript (as seen in React, Preact, Mithril, etc.).
>> Does not trigger when modified from the same page
I'm thinking that's the purpose of https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js... - without dispatching that custom save event, there wouldn't be a way to react at any other locations on the same page to the store updating.
Same here as a backend engineer.
I went into js/ts because I wanted to create something that I can interact with graphically, I don't really care about DOM.
Worked out for me mostly:
https://aperocky.com/cellular-automata
https://prehistoric.tech
These are built with typescript and compiled to js, with HTTP/CSS being static. And basically no framework usage. All of the complexity are essentially the simulation themselves.
> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?
You can even avoid a shadow DOM entirely:
https://github.com/WebReflection/domdiff
https://github.com/WebReflection/uhtml
> I don't understand what problem they're trying to solve
Certainly, not building a website. MAYBE building certain kinds of apps, like a game or a paint app (see: most action is truly on the client-side).
---
I found a simple stack that is super-productive & efficient: https://tailwindcss.com + https://htmx.org.
This is, IMHO, the best way to do "normal" websites, even the ones some are tempted to get nuts with stuff like React (eCommerce, blogs, chat app,...).
The best is that it actually embrace the web as-is and not requiere anything to degrade correctly.
For small sites, I always reach for vanilla rather than a framework. For example, [a super simple QR Code website][1] I made uses less than 100 lines of JS (minus the QR code library of course :)), plus regular HTML and CSS.
Anything larger, however, and using a library just makes things easier: HTML partials and helpers, nesting in Sass, and data flow and component composition in JS frameworks are just easier when a project is large enough.
[1]: https://github.com/romellem/easyqr-codes
Two things:
- adding interactivity to a web page vs building an application. Those are not the same thing, and what you read applies to the first
- there's a widely accepted belief that vanilla js is not suitable to build apps. I don't buy in this belief. I have a built networked Scrabble game written in vanilla js. Both the backend and the frontend. This simplicity allowed external contributors not well versed in the modern web stack to contribute. I also was able to enter the code of Pianojacq (from jaquesm) [1] and contribute quite easily because he also chose vanilla js. This simplicity is very valuable, and lost with modern framework, and nobody is really concerned about this.
I've done some React development, so I know my way in a modern app. I've also contributed to a frontend written in Vue. I think they solve problems but bring complexity to the table, in particular the tooling (bundlers, minifiers, etc), the dependencies and the debugging being much harder.
It seems DOM manipulation through native browser API scares many people, but when it's what you are familiar with, your usual "framework", it's manageable. You need to be disciplined to avoid things getting messy (a discipline frameworks partially enforce), but I really believe you can go far with vanilla js.
I believe React & Co are often picked to ease beginners' contribution, but they actually do require expertise. I'd rather touch vanilla js code from a beginner or an experienced developer than a React code from a beginner.
It's a matter of taste. Vanilla JS has the taste of fresh air to me. It's zen. You write the code and it runs. No tools, no slow compilation, no minification that complexifies the debugging. Minification which is only useful because with those framework you bundle an awful quantity of code in the first place. Yes, source maps exists but they don't do everything.
But today you won't have access to the whole ecosystem of existing React components with vanilla JS. It might be a curse or a benediction.
[1] https://gitlab.com/jmattheij/pianojacq
> keep the UI in sync with state
This is absolutely true, however there are some newer tools that are appearing that make this much easer with vanilla html - htmx, hyperscript, alpine.js for example.
These newer tools are all made possible due to the “new”(ish) MutationObserver api, it allows you to in the intercept new dom elements being placed into the document. These libraries let you simple decorate your “real” html with extra attributes enabling easer client side state management.
https://htmx.org/
https://hyperscript.org/
https://alpinejs.dev/
To that list I'd add Hotwire (especially Stimulus: https://stimulus.hotwired.dev). I use with Rails, but it's framework/backend agnostic.
If you want to stay close to vanilla, I'd recommend lit: https://lit.dev/
I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ (github link: https://github.com/tgflynn/AlgoVis).
The fact that this works, didn't take long to write (though I'm very much still learning this stuff) and is very fast leads me to question your statement that "The imperative DOM api just sucks".
We developed El to be as minimal as possible, while still solving the problem of keeping state and interface in sync:
https://github.com/frameable/el
It's just ~150 lines / 2kb, and leverages existing browser functionality to accomplish most of the hard parts. Has observability, reactive templates, scoped CSS, no need for a build process, etc.
I've always really preferred keeping it simple with HTML/CSS/JS and find most front-end frameworks to be a huge turn-off. You might like Astro (https://astro.build). I love that my sites are still 100% HTML/CSS/JS that I wrote myself. But Astro comes with Sass and Typescript support out-of-the-box (no Webpack necessary), and also makes it easy to do reusable components, scoped styles, supports FE frameworks if you want them, etc. It's the happiest medium I've found yet. :)
You'd dig Joystick: https://github.com/cheatcode/joystick.
I designed it to be a natural transition from learning the fundamentals of HTML, CSS, and JavaScript into full-blown, component-driven UI development. Dirt simple API, no syntax tricks, no specialized knowledge. Just plain ol' HTML, CSS, and JavaScript organized into a system that's more productive than standalone files.
It works on its own in the browser or as a part of a full-stack framework.
> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?
You can even avoid a shadow DOM entirely:
https://github.com/WebReflection/domdiff
https://github.com/WebReflection/uhtml
HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use!
[0]: https://github.com/gofiber/fiber
[1]: https://github.com/codemicro/go-neon
HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use!
[0]: https://github.com/gofiber/fiber
[1]: https://github.com/codemicro/go-neon
Hyperscript (https://github.com/hyperhype/hyperscript) is actually quite nice when you get used to it, and I actually prefer it over JSX. Pair it with something like microh[0], and it gets even better.
[0] https://github.com/fuzetsu/microh
Related posts
- A First Look at HTMX and How it Compares to React
- The Future (and the Past) of the Web Is Server Side Rendering
- How do you do HTML include files? Is there a generally accepted, conventional method?
- _hyperscript: A jQuery and JavaScript Alternative
- Static Site Generators - the WordPress alternative no one's talking about