Skip to content(if available)orjump to list(if available)

Reimagining front-end web development with htmx and hyperscript


Using html (and tailwindcss) have been the major productivity gain in web front-end development for us.

The speed on the UI is noticeable for our users (a lot of underpowered androids!) and the interactivity is equal than our prior vue version.

React/Vue is like Nosql: Good for certain niche scenarios but overkill for most use cases. Plain html/css is pretty performant and so easy to do than duplicate the state (+validations, structures, routes,...) between client/server.

So, if you are on the fence: Just try it. Is very likely it will be FAR simpler than you imagine!


I second tailwind as the way, and I'm using it along with web components. I think the important aspect of React/Vue was to inspire Web Components to exist. Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable.

For me, I'm building which is a reactive backend which then makes building reactive/interactive applications very simple.

With tailwind, I can just copy and paste HTML snippets and make it live with data. So much fun!


> Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable.

Except for the long list of issues that WC proponents pretend doesn't exist:


>Except for the long list of issues that WC proponents pretend doesn't exist:

This is the sad reality for web components. You end up needing so many libraries to do basic things that a framework would handle, that your project just becomes a defacto custom framework.


Damn, now I have to pretend those don't exist. I have to investigate how it breaks a11y as that seems to the the core killer in my case.

How does that list square with ?


Alex Russell introduced Web Components in 2011. React was released in 2013.

Web Components originally used a view-model architecture, which I would guess was heavily inspired by the most popular JS framework leading up to 2011: Backbone.

React was a massive departure from Backbone, and sadly the Web Components spec was developed before React had matured and changed the landscape.


I think it was Angular.js the framework that made us jump from JQuery to the modern way to do things. Backbone was never that popular.

Angular.JS was created in 2009 and released in 2010.


Thanks for the correction


> I think the important aspect of React/Vue was to inspire Web Components to exist

Web Components predate React as an idea, don't they? Admittedly it too hella long to get them properly standardised.


React as an idea predates React too ;-P


Sorry to say but you should brush up your UI on mobile firefox


I started as a front-end developer, so doing lots of Angular, React and Vue. But over the past few years I've transitioned back to plain HTML (or at least templating on the server side), and I find it so much more enjoyable and much faster to developer as well. I don't have to constantly switch between front-end/back-end, having to build APIs, just so that my single SPA can consume them.

Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that.


> Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that.

What is Jinja missing here when it has variables and logic in templates? You mean the rendering logic is less powerful so the template file alone can't encapsulate all the logic?


I do find the rendering logic less powerful, I know that in Jinja you have includes and macros, but I miss being able to extract specific logic to methods. I also like being able to use the language that I'm working in, to write extra logic in my templates, in React that would be JSX.

With Jinja it's this "weird" syntax that's completely different from Python and HTML. If that makes sense.


I really think components are an incredible innovation, and I'm constantly shocked that mainstream backend template systems don't have them. Some are beginning to, e.g Laravel's blade.


I feel the same. I tried playing around with server-side JSX in Deno and HTMX. JSX seems like a good solution for backend components, esp. since it's more suitable for reusable smart components with logic or data fetching and not just "dumb" templates.


What are the innovative parts of web components, which have no equivalent in lets say mainstream OOP, lumping state and behavior together?


How dare you call your users underpowered androids!

I’ll see myself out now


If I ever have a web application that I expect _could_ be revisited to add more functionality, next.js is the go to. It's performance on the user end is great, though I would be interested in how it does in the underpowered android scenario. Nevertheless it's hard for me to imagine feeling good about needing to add a feature on a plain Js+html project


This is what makes Svelte so fun and appealing for me. It’s just html with script and style tags… with optional superpowers if/when you need them. And automatically scoped styles, optimized bundles, SSR, and all the DX / UX boosts you could want!


So, your scenarios are mainstream and what React/Vue devs do is niche?


> React/Vue devs

devs probably not (ie: as NoSql, Kubernetes and stuff, some people pick overkill things, and by some I also mean me!), but React/Vue as libraries, certainly!

A SPA is a niche among the most mainstream web site. It makes sense when the interactivity is BIGLY on the cliente (like for example: A paint app).

But most things on web are not 90% client vs 10% server. Is the opposite.

Your todos, mail client, eCommerce site, blog, etc are better served with a server-side approach (note also how much important security is on this kind of apps!).

Your screen that display an interactive map, your game, paint app must certainly need a more client-first approach.

But as SPAs says: Is a "SINGLE" app. One.

Is your full app ONLY ONE? No? Then you are not in the niche, and if you actually have that SINGLE screen/app is likely a fraction of the whole thing.


Another possibility is that single thing consume so much that you say, screw it, lets do the rest similar even if is a poor-fit, but I think that is rarely if ever the best (for the users!). This is what drive adoption, React/Vue solve nicely some hard stuff and naively you think is great for the most basic one. But as show the fact that stuff like "back button" get broken without EXTRA workarounds is not the best fit for them...

P.D: Is my opinion -after try for years do the opposite!- that the majority of the web apps be server-driven and maybe add a little of react/vue/alpine for extra nice touch...


I decided to become a server developer as opposed to front end to avoid the js ecosystem meltdown... however I see server side tools like kubernetes have also become so ladened with exposing complexity we too find little time for actual creative development

watching a time lapse of a single biological cell develop for it's first few hours reminds me of the software tooling landscape... throbbing, twisting, shaking, bifurcating


What? Dont you like to learn 3/4 almost-useless DSLs, have to modify 3 config files for the smallest change and plumb more breaking things than Mario?


Mario doesn't do any plumbing.


It’s-a-me, the SRE!


It solves a lot of scaling problems though


> It solves a lot of scaling problems though

Problems that most devs wish that they had but don't.


So does a beefy server and a nicely parallelized backend service.


Problems that most of Kubernetes users don't have, and could have been solved with some unfashionable 2/3 servers and a load balancer.


Which 99% of users don’t have and never will


You don't have to use Kubernetes. Simple webservers and FTP and SSH still exist.


No need to go back 30 years.

If doing professional work, use heroku, App Engine or any similar PaaS solution.

If doing hobby/side projects, Dokku is a great self hosted heroku alternative. Easy to setup and use.

Kubernetes is a very low level tool. If you want to run it yourself you need s full team of infra experts to not fuck it up. So I think it could be a great tool for large companies with many teams and a lot of money.

As usual the problem is not taking into account context, and single developers or startups thinking they need to do what google does so they go full Go microservices spa Kubernetes crazy. Add some of the Agile bullshit on top of this and welcome to your average startup nowadays.


I'm doing both professional and hobby work with VPSs and SSH and there is no problem with that. Few less layers to take care of


Thing is, as a startup, there might be better solutions to your problem than Kubernetes, but investors specifically look to check the „use K8s“ checkbox on their rating sheet. It’s just as stupid as it sounds, and there’s nothing you can do if you need venture money.


To add to this, one could also learn Erlang or use kubernetes alternatives like Nomad, which, last I checked, has had less levels of abstraction than kubernetes.


All my stuff is fairly simple AWS via CDK, plenty of time for creative dev. But I do agree, k8s is not a requirement.


I’ve helped people use Kybernetes for quite a few things, but I can’t help but notice that there is even a policy agent that allows you to write rules in JavaScript now. There is a minimum level of complexity when you use Kubernetes, but there seems to be absolutely no upper bound.


Its funny to me how all these people who learned js/react (bootcampers/"fullstackers"?) before html are now discovering html. as a web dinosaur like me (15 years) i've watched this whole cycle play out.

not that js/react are not useful, but rarely should be your starting point. much better to use them progressively when the trade off are worthwhile.


I don't think it's funny, it's sad, and i think it s fueled by overvalued tech sector that no longer seeks to innovate but is stuck rearranging the chairs. I can offer the major redesigns of pretty much any online service lately as an example of making an app at times worse than it was before, just for the sake of change.

As a (bad) side-effect, people have stopped creating amateur websites, because it's hard. HTML was easy and fun, and everyone wanted to create their own geocities monstrosity. I'm looking at modern web constructs like WebXR with disbelief: How is it an hypertext standard if it doesnt even involve html tags (it's just a rehash of openGL , but in JS??). Why dont we make it easy for people to make quirky stuff anymore?


You can create an amateur website in exactly the same way as 20 years ago. Is it that hard? It's hard perhaps to step back and just play with web tech if you're indoctrinated into the modern development hellscape, but I don't see any reason you can't be ftping html files into a www directory to your heart's content if you really want to.


I think one of the biggest issues now is for peopling learning is if you just search “get started with web development”, the very first result says “Pick up a Frontend Framework.”

Newbies are immediately plunged into the world of npm, react/vue, and AWS.

Gone are the days where the tutorials are “write a page in HTML and FTP it on to a server”


you can't because everything you might want to embed/add now asks you to either use npm or something of the sort. I can't even find ways to 'just' download JS in libraries lately. In my example, suppose you wanted to add a 3d panorama with a-frame (easiest way), here is the installation:


I have chosen Hugo as my new static page generator.

Markdown and restructured text are both easier than HTML.

Very fast, easy to use, me gusta.


I just look at the installation instructions

easier than HTML, that a lot of people learned in school and with which people interact daily? no


I am one of those people who started reading a book on HTML when I was 10. I didn't understand a lot, but kept reading again and again and with 13 I understood enough context to create HTML websites.

For most projects I have been doing since it was either pure HTML, CSS wirh a few sprinkles of handwritten Vanilla JS, or Jinja2 templates with occasional PHP. When it got really complicated I used Flask or Django.

But to this day I never understood people who use js/react for pages that could have been handwritten with zero js in half a day (including a handwritten fluid CSS layout).


> But to this day I never understood people who use js/react for pages that could have been handwritten with zero js in half a day (including a handwritten fluid CSS layout).

I think people tend to improve their knowledge of some specific tool/language (JS in this case) and wanting it to apply to everything, not just what they initially learned it for and even if it might not be a great fit.

If all you know (because its what the schools/bootcamps teach) is generating HTML via DOM operations in JS, you might not even know better/simpler ways of doing it.

A bit like if someone just knew C and haven't really explored other languages/environments, then they might think that building a server serving HTML is a great thing to build in C, rather than using pre-built tools that serve static files or even using a safer language.


HTML is hard to compose (as in composing a page out of modular components), reuse (your toolbar everywhere has to recreate a bunch of components, like the nav section, logged in state, etc.).

Sure you can do that with server-side templates, but it's more readable (especially in a team) to use React components.

For me the main benefits of React didn't really shine until I had to maintain complex state and component trees among multiple devs. What is overkill for a simple blog is an absolute godsend for more complex apps.

Although frankly I still think Angular had a much better architecture, and I'm kinda sad React took over. But hey the frontend landscape gets a revolution every year or two (sigh) so who knows what the dominant paradigm will be by 2024.


I still don't get the love affair with CSS in JS. It defeats much of the purpose of CSS.

Also, my idea of a FE component is that of a class. A black box if you will. It the markup structure with the details as properties. Reusable because all properties are set from outide.

If you're hardcoding CSS within the "component" then it's not a component. And then having to effectively rebuild the entire app because a hardcoded bit of (Tailwind) CSS needed to he changed?? That's a step forward?

From a professional / career stand point I'm interested in React. But its model of thinking feels like 1999 in some ways.

I'm missing something? What am I missing?


The CSS in js components can be fully reusable between compatible frameworks, without any wiring of separate CSS files, and can also utilize theme configuration. Also just like how jsx is a form of html in js, having your style definitions in the same place makes it a lot easier to immediately grok what the component does and how it will look


As a react dev, I don't like CSS in JS either. It brings back the old font tag approach of individually styling components.

As an alternative, you can just assign class names to components and use global CSS like the old days, if you prefer. Sass is pretty great, basically CSS with better selectors and variables.


I'm building a simple page. Ok let's do simple html. Now I need popup for email capture, ok add a bit of hacky js. Now add a menu, could potentially be done with css only.

Now add responsive images. Good luck. You need to process then on server side, then handle them on client side etc...

Now add some customer area...

Add a few more features and it becomes complex.

Why would you want to now throw away all this and rewrite in react when you could just start with react.

In addition I can even migrate my old app to the new one and sometimes I can just copy paste certain components and css styles (thanks to css in Js) and it just works.

Honestly I don’t want to write responsive images manually. I just wrote a system once, now any app reuses the same thing. Same for other stuff. Plus I only need to know react and I can build anything.

You telling me now to learn htmlx syntax and use it sometimes, then use react other times just because… it’s simpler. The benefit is minimal, but now I need to know 2 worlds: react and htmlx.


Not meant as a criticism, but if this is the way you build websites, you are doing it wrong. If you are building a website in a way where you can not anticipate beforehand what will be needed a few steps later because you skip the one most essential step — the planning phase — you are gonna have a bad time.

Of course customers change their mind constantly, which is why you anticipate this in you choice of architecture to leave some wiggle room. The scenario you described tho: I never even remotely had a situation where it bit me in the arse that I wrote HTML with JS sprinkled in. For more complex stuff I have flask, django, websockets, htmx, custom REST-APIs I can built in any other language interacting with custom JS on that webpage (most of the software I write is server side). Or I could just take something like Grav CMS and write a custom Theme and some plugins for it. What is a good starting point depends on the kind of website.

There is so many ways to skin the cat it is not even funny. And if you don't know what cat it is beforehand it is your fault for not asking.


You are not going to be promoted if you quickly build something using simple tools. Complex and overengineered systems is where the golden opportunity is.


I just want to thank you and also chime in. I'm not even 40 years old and all this frontend crap from the last decade or so makes me feel old. I started learning this webdev stuff from an HTML book in the nineties. A time when 'frontend' meant HTML and CSS, and maybe some plain JS.

I'm not here to piss on JS frameworks, it's good that devs push the limits of what's possible, I guess. But there's something to say for simplicity and stuff that's so matured that you can really rely on it. Making sound decisions for your product, your stack and your architecture is a skill.


As someone who's a similar age, I wonder if that's a bit of rose colored nolstagia? Sure, these days the JS ecosystem is incredibly fragmented.

Back then it was CSS that was so rapidly evolving nobody could keep up. Remember the ACID tests? And that was even before flexboxes made things both simpler and more complicated.

Then there was the streaming wars, where RealPlayer and Flash and ActiveX and whoever else competed to be able to deliver <video>.

And what we solve now with CSS layouts and React components used to require frames and iframes and sprinkled JS drop downs that spoke to ColdFusion templates served from a single old Apache instance shared between a thousand users and constantly crashed, and https cost like a thousand dollars and couldn't be used internationally...

The web was never simple. We were just younger then and our neurons weren't so degraded yet. /sigh


These new technologies allow me to build websites about as fast now as I could build applications 25 years ago with FoxPro.

The HTML and CSS from the nineties require about five times more work just to get the same results.

This is progress.


> making sound decisions ... Is a skill

I agree! It sucks that most jobs don't care about paying for that skill though.


The author is a backend developer whose tech stack (as described in his profile) is:

Also sort of a web dinosaur here (remember when VRML was supposed to change the web forever?). Even today 90% of the web is static pages with JS sprinkled on top because much of the process of creating that was automated years ago. Contrary to popular belief people aren't actually that generous in their usage of SPAs because it's expensive.

Also while React has the highest market share, it's not the only framework out there.


What's really saddened me isn't so much the inevitable change in tech stacks, but the incredible centralization of websites. There isn't really meaningfully a "web" anymore. For most people the internet is just FAANG and that's it. Indie sites and good personal projects are totally gone, replaced by click bait and Medium SEO spam.

It's just a corporate hellhole now, with Facebook owning the frontend via React, Google and Apple owning the hardware, and Amazon owning the network.

I miss those one person passion project pages that you used to be able to find on Yahoo.


It feels weird to read this on HN, where a sizeable fraction of the links on the front page often go to websites built by internet randos.

If you're talking about web sites as art projects, there are communities like that although they are fairly small. Neocities is one of the more prominent ones.

The small web still exists, but you have to stray quite a way off the beaten path to find it.


I think this web is still there somewhere, it's just that in the meantime FAANG et consortes started expanding at an exponential rate, so on one hand there's a lot more web out there, on the other the fraction of it that looks like the old web fell drastically.


I think the “web” is still very strong, but it is now extremely commercial. If a person wants to create a website these days is mainly for business purposes. Pretty much all other uses had migrated to the FAANG (or MAANG, rather).


>as a web dinosaur like me (15 years)

2022 - 15 = 2007.... Which means you aren't even in the IE era. Hardly a dinosaur if you ask me :)


Something it took me some time to understand, and I feel very dumb for that, is that with these modern "SPA" tools such as Next, you can still do quite easily dumbed down non interactive websites that do traditional form posts. It works perfectly fine.

The other way around, using the dumber tools and trying to do highly interactive apps, is a lot harder.

That might be part of the reasoning most things are nowadays built with these spa like frameworks.

Not that I agree. Just trying to understand.


I don't know, sometimes doing very simple concepts in modern SPA is much harder than with traditional technologies.

Have you ever had to debug non-functional SSR in React or Next.js? I very much doubt SSR is simpler than plain HTML or PHP or AJAX.

After all, SSR is just rendering plain HTML. It doesn't have to be that complicated full of gotchas and quirks like it is in the React world.


But Nuxt/Next SSR is not "just rendering HTML". Funny how htmx threads always revolve around largely dishonest arguments.

"I very much doubt SSR is simpler than plain HTML or PHP or AJAX"

What does that even mean?


Correct - SSR the way Next does it is basically the same as HTML+AJAX but simpler to reason about as an implementer and, if you use Typescript, type-checked and far less likely to be buggy.


Yes, I agree. The "minimum complexity" is way higher this way, even for simple things.

But my fear is that when things get complex in the frontend, at some point there is a peak point at which these tools become easier and the more traditional ways more difficult. And it is not easy for me to day where that peak point is.


It's possible to agree with or refute you based on the definition of the definition of "highly interactive apps". But I can qualify it this way. If htmx (maybe with hypertext or alpine.js) is enough for your app then I would say it's much easier to do it with htmx than a js framework. The frameworks come with the kitchen sink and are not trivially easy to even keep running due to node updates, bundlers etc. They are also very complicated and as with every framework, you start to see the limitations as you start doing more complicated stuff or go out of the happy path. Another way I can qualify it is, I can write a semi interactive website with htmx at my current experience level with Javascript but I can't do that with most frameworks. Where you are probably right without qualification is when the programmer/team is already using said framework and has experience with it.


An issue with Next is that it still loads a complete React app after delivering it pre-rendered.

Astro might solve that with selective hydration.


the js ecosystem is built on romance. what this article describes is not even the tip of the iceberg for a large application.


The JavaScript ecosystem is insanely successful, even though the language, node_modules, and the entire process of building a SPA are disorganized and clearly poorly designed. What makes it successful though is those flaws exist because individual developers in aggregate have decided that they’re worth the trade off. All the JavaScript killers seem more precisely designed, but that’s only possible because they haven’t been shoe-horned into thousands of different use cases they weren’t meant to solve. Those edge cases add complexity and rough edges, but make for a more practical toolset in the long run.


For a large interactive single page application you probably still want to use React/Vue or similar.

But for a small, simpler app, maybe one you are working on alone, only having a “backend” is appealing.

I’ve been using Alpine on a project recently and removing the overhead of a frontend to manage has made progress faster.


great article showing how htmx and hyperscript can play together

i know they aren't going to be everyone's cup of tea, but htmx is a pretty pure take on "what if HTML had kept going as a hypermedium", generalizing the various limitations currently placed on HTML. htmx stays within the original, REST-ful model of the web, exchanging hypermedia with the server in a way that is extremely compatible w/ Roy Fielding's description of the web architecture.

hyperscript is an event & DOM oriented scripting language, based on HyperTalk, the old scripting language for HyperCard. definitely not everyone's cup of tea, but it fills a need for a general, event oriented language that is easily embedded directly in HTML. This complements htmx really well in many cases. hyperscript is definitely much more speculative, but it has some pretty interesting features, such as async-transparency:

anyway, it's a different take on web dev, but I'm glad to see some folks running with it and I'm happy to answer questions


I miss hand-writing webpages in Notepad and then FTP'ing them to the public_html directory on the server to make them live. The amount of infrastructure, libraries, build tools, pseudo-languages, etc layered on top of each other some developers/orgs use to make a simple form today is crazy to me. It also feels super fragile: deploy a website today, come back to it in 5 years to make some changes, and half the tools and libraries you need will be gone.


In 5 years? I think you misspelled weeks here.

Last six months with my last employer I spent immersed in the full Next, React, Prisma ecosystem. I swear that 80% of developers' time was wasted on fighting compatibility issues. Actual work happened in the small crevices of time left between endless stream of build breakages or chasing random bugs caused by changes in transitive dependencies.

My God, never again.


I feel like es modules have killed javascript. They have enough momentum that everything supports them (or needs to support them). But they’re not good enough, or compatible enough to actually integrate well.

Recent example: bundler X insists on import statements including file extensions. But the typescript compiler refuses to let you import foo.js and won’t rewrite an import of foo.ts to foo.js when you build. There’s giant GitHub issues about this but nobody wants to fix it on their end. In short, everything is awful.

Writing javascript in the browser used to be just the same as nodejs, with the exception that you needed a bundler like browserify - which mostly just concatenated everything together. Now I dread setting up new projects. Will typescript work with svelte? Will this webassembly module work with rollupjs? Will it pull in my type definitions correctly? Will the url path system magically work or break? Urgh.

I feel like I’m no longer competent enough to get arbitrary tools working properly together. We need bespoke build systems now because it seems like they’re the only thing that works any more. And that means I can’t throw together a simple server side rendering system like I used to be able to do.

Bryan Cantrill once joked that javascript was the failed state of programming languages. That doesn’t feel like much of a joke any more.


The thing you described about tsc not liking file endings ... I wasted a whole free day on this and my whole motivation for a side project. How the f is tsc not able to output whatever module I need in 202X??? And that means you need an extra tool to do the job. Good luck setting up shitty bundlers for another whole day, until you finally get a simple output directory with normal JS file, one per ts file and simply deliverable to the browser. It is such a PITA. It makes me question whether all the type safety of TS is actually worth the trouble. Once I start writing plain JS, I slowly but surely get the feeling of that project being lost, unless I use a proper programming lang and output to JS. Maybe one of these days I will learn Clojure or something. All just because the JS ecosystem of tools sucks so much. And this is what people put up with all day long. How have we strayed so nuch from the path?


I once set out a simple goal, instead of shipping a production Node package with all the js files and node_modules, just have it all in one js file that can be executed by Node. After trying several compilers and messing with their settings, I ultimately failed exactly because of the different ways to import/export modules. My own code was all esm with .mjs files, but many npm libraries aren't so basically you're stuck.


You don’t need bundlers or build systems. ES modules work in all modern browsers without any build tooling, imports and all.

HTTP/2 mitigates the TCP overhead.

You can have an unbundled, unminified web app load quicker than the average bundled and minified React app.

Best of all, you can’t use NPM modules so your codebase can stay ultra-clean!


> Recent example: bundler X insists on import statements including file extensions. But the typescript compiler refuses to let you import foo.js and won’t rewrite an import of foo.ts to foo.js when you build. There’s giant GitHub issues about this but nobody wants to fix it on their end. In short, everything is awful.

That's wrong. The latest TS version allows you to import .js files with extensions just fine! In fact, one of their recommendations is that you write the your JavaScript code as you would if they were intended for a browser (which doesn't automatically append any file extension, doesn't support importing directories by appending /index.js, only supports file-relative or absolute imports (outside of import maps) etc).


You see, it's not that ESM killed JavaScript, all the hacky build tools did. ESM was in the pipeline for an eternity and everyone took their sweet time to support it.

You can use ESM without issue in browsers, Node and using proper ESM bundlers like Rollup, as long as you don't expect `import 'a/b'` to arbitrarily load `./node_modules/a/b.js` or `./node_modules/a/b/index.js`

npm also keeps actively harming the community by not validating packages in any ways whatsoever, so everyone keeps pushing broken crap into the ecosystem.


Next is the worst name for a JavaScript framework. It might as well be called "yet another JS framework." It's things like this that make me ponder self deletion. So much pointless work we create for ourselves.


It’s layers on top of layers on top of layers, etc.

I’m looking for a framework that compiles to web assembly to generate next.js to spit out react components that generate JavaScript that prints html.


I experienced this with multiple npm packages where I can no idea how to fix it. My most recent was with, and I did not have fun. This is how I'm getting myself back to basics:

Here, I believe in taking HTML and then finding the absolute minimal extensions. My most work is to embed a mustache like primitives into HTML. For example <div rx:iterate="posts"><div><lookup path="title"> - <lookup path="body"></div><div> will iterate over an array and render the title and body appropriately.

I then take it a step further by making the binding reactive such that updates flow in real-time.

I am having a great deal of fun with this approach as I continue to explore this approach.


You should check out the OP. This is exactly what htmx does.


The name alone already makes me feel dread. htmx - as if HTML needed an x for extended ... also has a feeling of docx and its ilk. Why do people feel the need to change HTML instead of changing the logic, that outputs HTML? HTML is just the damn view layer! This smells of mixing logic into the view layer again.


This is so relevant. The current “bundle of bundles” approach has very low longevity potential.

I swear this whole design pattern in the article looks just like cold fusion did in 2000.


What’s stopping you from using these tools today? I still use vim for editing and rsync for deployment whenever I can.

Unless you mean for clients.


For Lua, just to be safe, I fork all my dependencies and when I work on a project I add those forked dependencies as git submodules. Just to feel a bit more secure any dependencies never disappear.

Not sure if this is good practice.


Its good to have dependencies archived for continued access to them, but there are efficiency issues with doing that. Using git submodules (or vendoring or similar) means that you and everyone who uses the project is stuck on the exact commit you have chosen for each submodule until they go and modify the git tree to use a different commit for each submodule. This makes it higher friction to update a submodule. You can't just go `git pull` or `apt upgrade` to update the submodule, you actually have to go modify every project that uses the submodule, update and redeploy each one, instead of just updating and redploying the submodule itself.


That sounds amazingly slow, in a good way.


Well, I only use git submodules in private projects. From what I read most devs hate it :)

In the past I did came into contact with git submodules through freelancing for another company, and I agree it was quite a hassle it times using it in a team setting.


With node some people commit the heresy of comitting the whole node_modules folder.


I would do that, but node puts compiled bits in there, so nothing works if you switch machines.

It's not like linux distros figured out this stuff was an issue decades ago...


I think that's called vendoring and it's part of the 12 factor app.


Good luck with that approach in the JS world, where a package can have, without exaggeration, a thousand and more dependencies. Hopefully in the Lua world things are saner.


I’ve found most Lua game related libraries don’t have any dependencies, so it’s indeed a saner world :)


What about transitive dependencies?


I've found most Lua libraries don't have any other dependencies.

Perhaps this is the reason I've found this approach work well with Lua. I've never tried it with other languages that I use, like Swift, Objective-C, C#.

I did work in a company in the past that used Nexus [0] for their dependencies across various platforms. Perhaps Nexus has some tooling build in to deal with transitive dependencies, not sure.




It's forking all the way down. I run my code on a fork of Linux, just in case.


Theres a few nice lightweight CSS/JS frameworks like and bootstrap that are still relevant, react apps get lost in a mess of callback caches and useEffect, unclear side effects seem to happen on rendering in most large react apps.

I developed some games like in a fairly simplistic jquery style i developed where i purposefully avoid using features of JS like "this", it trips most developers up when you pass functions around and the reference to "this" gets lost.

Agree with lots of the comments here about complexity of both JS (new es module compatibility issues etc) and JS frameworks that are limiting what people can actually build these days from cognitive overload and bugs.

a tonne of technologies (like components) died in a sea of complexity and much technology we use is going to go the same way unfortunately.

Another gripe i think unpopular but true is that we as coders prefer complex things like static site generators like Jekyll/ghost etc, normal people can use a CMS and get stuff done without having to resolve packaging conflicts and SSL issues, we have to resist the urge to pretend coding/setting up complex software is easy because its not... also Kubernetes...




I built a website for my girlfriend's business using almost exactly this approach. Handwritten HTML, deploy to CloudFlare pages on git push, Stripe payment pages for ecommerce. It's great, more people should try it.


Angular -> React -> Vue -> Svelte -> Solid -> Marko -> Hotwire

Please stop.

The reason why React is so powerful is because of the maturity of React Native.

If you're a startup deciding your FE framework and you have mobile to consider, then chances are that React is best fit.

Unless you have capital to blow on a separate native team, lest it even be more separated to kotlin / swift, then sure you can possibly afford all these niche FE frameworks.

Lets not even talk about hiring pools.

React is good enough, and it's a shame that many of you think the answer is a new framework with better philosophy.

Trust me, I love reactivity > virtual dom, but React is good enough.

It doesn't need to be the best, it just needs to do its job.

The only thing I'll ever consider switching to is when WASM comes out with a framework - till then I'm betting on React.


React is not good enough. It sucks for both time and space complexity. It's slow, it's bloat. I don't want to tie myself with the word "engineering" for doing software development these days. It's shameful compared to other engineering fields.


While I agree that Front End "engineering" isn't as complex as other fields, calling it "shameful" is a bit much.

There is a huge requirement out of web apps today that SPAs are more and more required than your simple html + css blog posts.

Posts like these is where I feel the age of HN, that are becoming bitter about fields that were once very simple, ending up complex to suit the needs of the times.

Everywhere I look around, people on HN feel like we're still in the age of blog posts and form submissions, when in reality, there are people trying to port applications like Photoshop towards the web.

If Photoshop was available on the web, wouldn't you think that the Front End required an honest amount of "engineering"

And it doesn't even have to be a front-end heavy application like photoshop - it could just be a simple chat application that needs to be on the forefront of the site while you can still browse.

You can use whatever framework you'd like to solve your "bloat" issue, but the problem is, especially for startups, you're not going to get anywhere near the hiring pool, nor or you going to have an ease of choice for your native platform.

This is what makes React so strong right now.

I wished you had addressed this, instead of just deriding the entire front end community.


You are conflating the root comment of this and the OP's point. It's not about SPA. It's about network effect / marketing / cult / lack-principle insanity of frondend or web market that's heavily into React specially.


Adding React is a big decision.

You’re adding a lot of complexity to your project which may be unnecessary if you’re app is a simple website with a few interactive elements.


Choosing any front end choice is a big decision.

But you're not going to get anywhere near the hiring pool nor are you going to have an ease of choice in native platforms.

React is easily the best decision a startup could make right now.

> If your app is a simple website with a few interactive elements.





You're missing the point here. It's not "another framework". It's more like "no framework" at all. Please read:


No you're missing the point.

What's easily the better decision for a startup that has to deal with mobile and native platforms?

I seriously don't know what you people are building that you think low/no js is viable.

Collab tools like Trello Asana need high js

Chat applications need high js

Drafting applications like FanDuel, DraftKings, Sleeper need high js

Music apps like Spotify or Soundcloud need high js

Financial apps like Coinbase or Robinhood need high js

Seriously, what are you people building that you think low/no js is okay.


What is the lesson of this article? Instead of using React or Vue, you should use htmx and hyperscript to have less stuff under node_modules?


I'm not really understanding what hyperscript brings. It's neither back end nor JavaScript, and only AppleScript users will be comfortable in it. It seems like just another library that needs to stay current with the DOM and might become brittle.


It’s basically another framework that lets you add interactivity to server side generated HTML views, ala Stimulus, Knockout, etc.

A lot of devs like approaches like this because they can do more with their server-side language and frameworks that they’re used to/more familiar with, since trying to do everything server-side doesn’t give you the interactivity UX, product, etc wants.

(I personally prefer client side HTML view rendering like React, and only talking to the backend via API calls, but I understand the use case for this sometimes)


htmx is a little different in that its focus is on extending HTML as a hypermedium, exchanging html (rather than some other data format) with the server, and staying within the original web network architecture articulated by Roy Fielding:


I totally get htmx. Just not hyperscript.


You can have no node_modules


The first comment on that page is that this approach produces inaccessible UIs, not sure if that would be the absolute case or not, as it didn't look like the article was taking accessibility into consideration.

All that said I don't think this gives any real benefit over JS, sure, fix node_modules bloat, but I guess I'm a little bit skeptical if there wouldn't end up being hyperscript bloat if it became the biggest programming language in the world powering what for many is their defacto platform and thus everything needed to be solved in it.




it's a good fit(alpine also fits well here) for 'legacy' server-side-rendering framework like django. rails and php already have their own similar approaches.

SPA still has its own place though: a backend provides the data, and a frontend renders it. the separation of two concerns still has lots of benefits not just for traditional website, but also for browser-based GUI(e.g. Electron apps).


Why is server-side rendering considered "legacy" nowadays?


Agreed, Alpine and the like work great when building your app in Laravel.


I feel complex UI development becomes a ease with SPA ecosystem than server side.


I think people in comment should not try to compare HTMX to SPA directly, but have a broader view of the whole pros/cons of the tech stack.

For example, let's say you need to write an admin dashboard with many pages, no fancy stuff. Odds are you'll be very productive with a good old Django/Rails, having no API to write and a single simpler project to maintain.

Once that monolithic framework choice is made, before HTMX, as soon as you needed interactivity, you had to mess with jQuery and the code was quickly awful. The only solution was to plug a SPA framework and develop an API (this is not trivial!). HTMX (and other tools like Alpine.js) solve that problem well.

So, the question is not "is HTMX better than SPA frameworks", but rather: "Knowing that I can now build decent front-end with Django/Rails, does a more complex stack with Next worth it?"

HTMX-like tools make SPA frameworks a little less indispensable in some use cases. That's it.


"A backend web and desktop application developer" whose "preferred frameworks are Django for Python and WPF for C#" has, unsurprisingly, a naive impression of what's needed out of a UI framework.


Alternatively; a backend developer writes about their exploration of a relatively new/emerging frontend approach which provides an interesting read on one of many alternative options for frontend from pure HTML to canvas for everything.

I write React in my day job and I think it's the bees knees, but I am interested to learn about alternative approaches and projects aiming to create new/revive old paradigms.