14 ms·

Reimagining front-end web development with htmx and hyperscript

• dangrossman 4y ago
  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.
  • happytiger 4y ago
    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.
  • wsc981 4y ago
    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.
    • doodlesdev 4y ago
      With node some people commit the heresy of comitting the whole node_modules folder.
      • danielheath 4y ago
        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...
    • projektfu 4y ago
      I think that's called vendoring and it's part of the 12 factor app.
    • pabs3 4y ago
      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.
      • dhzhzjsbevs 4y ago
        That sounds amazingly slow, in a good way.
      • wsc981 4y ago
        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.
        • pabs3 4y ago
          Even in private projects, its an additional hurdle that can block things like security updates for example.
    • yawaramin 4y ago
      What about transitive dependencies?
      • likortera 4y ago
        It's forking all the way down. I run my code on a fork of Linux, just in case.
      • wsc981 4y ago
        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. --- [0]: https://www.sonatype.com/products/nexus-repository https://www.sonatype.com/products/nexus-repository
    • zelphirkalt 4y ago
      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.
      • wsc981 4y ago
        I’ve found most Lua game related libraries don’t have any dependencies, so it’s indeed a saner world :)
  • mathgladiator 4y ago
    I experienced this with multiple npm packages where I can no idea how to fix it. My most recent was with https://docusaurus.io/ https://docusaurus.io/, and I did not have fun. This is how I'm getting myself back to basics: https://www.adama-platform.com/2022/06/26/making-html-the-best-it-can-be.html https://www.adama-platform.com/2022/06/26/making-html-the-be... 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.
    • yawaramin 4y ago
      You should check out the OP. This is exactly what htmx does.
      • zelphirkalt 4y ago
        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.
        • yawaramin 4y ago
          htmx is very, very close conceptually to a standard HTML <form> tag. (By the way, the fact that there is a <form> tag immediately tells us that HTML is not just 'the damn view layer'.). htmx just goes slightly beyond it to give <form>-like capabilities to every element, and doesn't need a full page reload. It doesn't even necessarily change or extend HTML–you can just use a `data-` prefix on the attributes that it adds–which makes it completely standards-compliant HTML. It's a very natural fit.
  • abraxas 4y ago
    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.
    • ravenstine 4y ago
      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.
      • fijiaarone 4y ago
        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.
        • Nextgrid 4y ago
          In the era of Yarn, Bower, etc I was joking that we need package managers for package managers.
          • flatcakes 4y ago
            I just learned about Volta today...
            • SenHeng 4y ago
              Let me introduce you to asdf. No, that is not a typo. https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf
    • josephg 4y ago
  • tambourine_man 4y ago
    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.
  • deleted 4y ago
    [deleted]
  • moralestapia 4y ago
    I kind of still do this, just Sublime/SFTP instead of Notepad/FTP. Still haven't seen anything from "the new JS" that makes me want to switch.
  • teen 4y ago
    as someone who's been making websites for 20 years now, i think it's actually easier than ever. and pretty simple. the tools are insanely good.
  • crabmusket 4y ago
    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.
  • lee101 4y ago
    Theres a few nice lightweight CSS/JS frameworks like mdl.io 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 https://github.com/lee101/wordsmashing https://github.com/lee101/wordsmashing 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 polymer.io/web 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...
• synergy20 4y ago
  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).
  • gimme_treefiddy 4y ago
    I feel complex UI development becomes a ease with SPA ecosystem than server side.
  • jonwinstanley 4y ago
    Agreed, Alpine and the like work great when building your app in Laravel.
  • 0xbkt 4y ago
    Why is server-side rendering considered "legacy" nowadays?
• tipiirai 4y ago
  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?
  • projektfu 4y ago
    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.
    • gedy 4y ago
      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)
      • projektfu 4y ago
        I totally get htmx. Just not hyperscript.
        • gedy 4y ago
          My bad, yeah I don't see the value-add of that either.
          • recursivedoubts 4y ago
            the idea with hyperscript is to provide a general, event oriented language that can be embedded cleanly directly in HTML normal on* attributes are fine, but they aren't general (e.g. htmx fires a bunch of events you might want to hook into, and you can't use normal on* attributes to cathc them) hyperscript also has a lot of features that are DOM oriented (e.g. query literals like <div.foo/>) certainly not everyone's cup of tea, but it dovetails nicely with htmx and fills a need for a general, event oriented scripting language to complement it
• mamcx 4y ago
  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!
  • FractalHQ 4y ago
    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!
  • mathgladiator 4y ago
    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 https://www.adama-platform.com/ https://www.adama-platform.com/ 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!
    • nickcox 4y ago
      > 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.
      • bigDinosaur 4y ago
        React as an idea predates React too ;-P
• AtomicOrbital 4y ago
  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
  • UmbertoNoEco 4y ago
    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?
    • animal_spirits 4y ago
      It solves a lot of scaling problems though
      • ihateolives 4y ago
        > It solves a lot of scaling problems though Problems that most devs wish that they had but don't.
        • halfmatthalfcat 4y ago
          Infrastructure as Code is powerful; Terraform + k8s (with nginx-ingress/cert-manager/external-dns) and you never need to worry about infrastructure again...
          • watermelon0 4y ago
            At $work we use(d) the following: - Heroku - AWS ECS Fargate - AWS EC2 (AutoScalingGroups) + Docker - AWS EKS (managed K8s) + Helm charts Everything (except Heroku) is/was IaaC. They are listed in the ascending order of how many problems they cause, and how much we have to worry about them ... I will never ever touch K8s if I can possibly avoid it.
• bzmrgonz 4y ago
  I am keeping my fingers crossed and saying a few our fathers for www.redwoodjs.com JAMSTACK for the WIN.
• gimme_treefiddy 4y ago
  One of the things that I found lacking, was doing like general computing-esque business intelligence tasks in htmx. For example, how would you set src on image tag upon a click. Ended up having to use jquery.
  • recursivedoubts 4y ago
    you'd use hyperscript for something client side like that: on click set @src to "https://whatever.com/cat.gif https://whatever.com/cat.gif" the htmx approach would be to replace the image tag entirely
  • MonadicSystems 4y ago
    You should be able to do this with hyperscript. <img src="my_cat.jpg" alt="My cat" _="on click set @src to 'my_other_cat.jpg'">
    • ngcc_hk 4y ago
      Any more full example? Interested.
      • bluewalt 4y ago
        Vanilla JS v. jQuery v. hyperscript full examples here: https://hyperscript.org/comparison/ https://hyperscript.org/comparison/
    • mattlondon 4y ago
      I am not sure what the benefit of hyperscript would be here? Why not just use JavaScript + htmx?
      • asciiresort 4y ago
        Why not just use JavaScript + HTML? <img src="my_cat.jpg" alt="My cat" onclick="this.src = 'my_other_cat.jpg'">
• rexpop 4y ago
  "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.
  • UglyToad 4y ago
    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.
• recursivedoubts 4y ago
  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: https://hyperscript.org/docs/#async https://hyperscript.org/docs/#async 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
• shroompasta 4y ago
  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.
  • jonwinstanley 4y ago
    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.
    • shroompasta 4y ago
      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
  • Existenceblinks 4y ago
    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.
    • shroompasta 4y ago
      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.
• asciiresort 4y ago
  > In recent years, a few mavericks and renegades have started to turn away from the world of JS frameworks and the inevitable bloated node_modules folders Some projects claim they are "zero dependencies" but a few sentences into the readme and you see an `npm install` and now you notice there is `package.json` after all . They meant zero runtime dependencies, which is still praiseworthy, but not zero `devDependencies`. For my greenfield web app, I attempted to have zero dev dependencies on Node. I wrote some vanilla HTML, JS, CSS, and now needed to reduce network transfer. Requirements: - minify - inlining CSS file into HTML - compress with Brotli - print out final byte size - nice to have: run a dev server that serves static Brotli We know the story with WebPack. I looked to Parcel instead because it's the "zero-config" tool. It was promising because it inlined my `@import css` into my HTML, and logged out the filesize. The watch and reload feature wasn't working as promised, but that was nice to have anyways. For Brotli compression, which is mainstream at this point, I quickly needed to add a `.parcelrc` config. Their code sample didn't work because it turns out that in the real world you need to make your .parcelrc extend/inherit "@parcel/config-default". Parcel stopped logging at the compressed file sizes and not the final Brotli file sizes. Finally, Parcel's dev server is useless to me because you can't set encoding headers for "Brotli" files so the browser just attempts to download it. I didn't have a .gitignore file, and adding this one Node dependency on Parcel added 3,000 new files. To be fair, that's miniscule for a Node project. I asked myself if I can achieve the same results with CLI tools that are not Node. I first looked to the Golang ecosystem. I stumbled upon https://github.com/tdewolff/minify https://github.com/tdewolff/minify. It just does minification. It's comparable in output size to other Node minifiers, but faster and just works. The lexer code is very readable, even for me who is not a compiler or systems expert. It's one command to install the CLI, and one command to Minify. You can do `npm install global -g` to get CLIs, but Node supply chains tend to be much deeper. This bespoke one-liner does the CSS inlining for me: RUN sed -i "s/@import \"style.css\"/$(cat style.css)/g" index.html` For Brotli compression, I went with the official first party CLI ( also Go based ) instead of using a third-party wrapper like you'd have to do with JavaScript. One thing I was missing in NPM scripts as a self-documenting way of describing what commands to build, run, test. I've seen cases where people are beholden to a `package.json`, sometimes when their project doesn't even involve JavaScript. When you have a hammer, everything looks like a nail. It turns out Makefiles are a better way of doing this, especially if you don't already have a active relationship with Node .PHONY: help help: ## This help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) # DOCKER TASKS build: ## Build the container podman build -t ${APP_NAME} . run: ## Run container on port configured in `config.env` podman run -it --rm -d --env-file=./config.env - p=$(HOST_PORT):80 --name="$(APP_NAME)" It's even better than self-documentation, because the documentation is self-documenting: $ make help help This help. build Build the container run Run container on port configured in `config.env`
• 5350-uiop-1130 4y ago
  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.
  • atoav 4y ago
    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).
    • capableweb 4y ago
      > 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.
    • ttty 4y ago
      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.
• likortera 4y ago
  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.
  • pictur 4y ago
    the js ecosystem is built on romance. what this article describes is not even the tip of the iceberg for a large application.
    • codechicago277 4y ago
      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.
    • jonwinstanley 4y ago
      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.
  • sph 4y ago
    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.
• beebeepka 4y ago
  What the htmx anti js crowd refuses to accept is the existence of applications that do not fit their world view. Serving html is trivial but do we really need every back-end juggling this stuff just to make these guys happy? What do they do when they have to support a number of clients. Oops...
  • asciiresort 4y ago
    > back-end juggling this stuff just to make these guys happy? I don't see this design pattern as forcing a particular back-end framework? It's merely shifting the frontend<-->backend contract from JSON to HTML. Some backend engineers arguably would prefer HTML. Especially if their backends weren't Node. Backends were originally C servers that sent a string of HTML back. I think backend engineers are fully capable of "juggling" with this new/old paradigm.
    • ducharmdev 4y ago
      The problem with using HTML in this way is that it couples the view with your data. What happens when non-browser clients (e.g. mobile, other servers) need to easily consume the same API? I know some projects plan to only ever use browser clients, so this may seem irrelevant for them. But I'd rather not try to predict how a business will want to use it's data in the future, and would prefer to design a backend that can be adapted to many scenarios without being bound to a particular client.
      • asciiresort 4y ago
        > But I'd rather not try to predict how a business will want to use it's data in the future Sure, then the backend can expose a gRPC / protobuf interface instead. Mobile apps can readily deserialize this and it will be more performant, both in network bandwidth and data parsing, too, especially with first-party to first-party SDKs. It's strongly typed and serves as a better data contract language than both HTML and JSON. JSON is loosey goosey because of JavaScript. Then the frontend server now plays the role of aggregating data from gRPC backends and converting it to HTML. The gravitation to JSON is a case of web developer familiarity.
• bryanrasmussen 4y ago
  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.
  • deleted 4y ago
    [deleted]
• projektfu 4y ago
  The article uses as its first example one of my most-hated fashions as a user of a website--the modal dialog entry form in html. Makes it hard for me to stay interested. Honestly, this is one thing I like about the multi-page app flow over single-page apps.
• bluewalt 4y ago
  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.
• dgut 4y ago
  I prefer Stimulus vs htmx + hyperscript for two reasons: 1. You can easily reimplement all htmx and hyperscript functionality and fine-tune to your liking 2. You are not limited by htmx and hyperscript
• moltar 4y ago
  That syntax just smells like a leaky abstraction and is jarring. Also probably lacks typing and poor intellisense support. Not sure why I’d pick that over conventional offerings.