Reimagining front-end web development with htmx and hyperscript

> 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: https://twitter.com/Rich_Harris/status/1198332398561353728

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

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

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

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

Mario doesn't do any plumbing.

It’s-a-me, the SRE!

It solves a lot of scaling problems though

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.

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

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

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

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.

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.

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.

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.

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?

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.

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.

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.

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.

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

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.

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

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.

What about transitive dependencies?

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.

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.

lol

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.

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)