11 ms·

Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back

by qrohlf 4y ago

Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke route. Not this. [1] https://htmx.org/ https://htmx.org/. [2] https://javascript.works-hub.com/learn/a-javascript-free-frontend-61275 https://javascript.works-hub.com/learn/a-javascript-free-fro.... https://slimvoice.co/ https://slimvoice.co/

ramesh31 4y ago
>I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no understanding of why and how we got to where we are, and the tradeoffs that were made along the way.
- whatever1 4y ago
  SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
  - JackMorgan 4y ago
    A lot of dev managers like that they can turn one team into two teams by splitting everyone into front and back end. This makes hiring easier. I cannot emphasize this enough. Easier hiring is a huge deal. As a secondary effect it also allows for more kingdom expansion. It's much easier to have two teams of five than one team of ten. That being said, I'd rather manage a team of five good full stack engineers than ten average front/back end engineers. The communication cost of trying to get features out the door with two teams of five is very high.
  - claytongulick 4y ago
    Or maybe people don't like waiting for a page to load each time they click a button?
    - ryanbrunner 4y ago
      People want responsive interfaces, absolutely. Whether the interface is implemented as full page requests to servers or AJAX requests is irrelevant to users. Bare AJAX itself almost always will perform better than a full page request, but as you layer on additional requirements, frameworks, libraries, etc. that isn't always true. I think old reddit and new reddit are a great example of this - both are processing the same data and presenting a very similar UX. But at least for me, the relatively javascript light old reddit interface with full page reloads feels much more responsive and usable than the new site.
    - yetanother12345 4y ago
      IMHO this is a false argument. Ask yourself: Do "people2 prefer looking at "spinners" or more-or-less animated "page loading..." texts? Waiting time is the issue, the technology is not. A server generated page that loads fast beats a Framework-generated page hanging every time! As for technology: With "classic" server generated pages "people" will know what is going on (browser indication tht page is loading) and they will know what to do (wait a few seconds at most). With frameworks "people" are left out in the cold with no indication what the problem really is and no apparent remedy or path for solution as a page refresh might interfere with state logic or whatnot bringing totally undesired results.
  - jrochkind1 4y ago
    That seems strange to me as being an "old school" developer I have a lot more trouble trying to get a hang of the new front-end stuff than I do learning a different back-end framework. But I guess that is just me/generational? Ironically, I feel like there are a lot more job openings for front-end than for back-end now, and I'm much more comfortable on the back-end.
  - AtlasBarfed 4y ago
    Then why is every JS-bro "full stack"?
    - knightofmars 4y ago
      IMO, I think this is a valid question (though asked a bit crudely). To generalize, it's because someone who has done JavaScript programming can point to NodeJS and say, "I'm full stack." Which, while technically true, skates over the reality of NodeJS as a less than ideal backend (see Ryan Dahl and the dawn of Deno). Second, it's more lucrative to bill oneself as "full stack" even if in reality a person isn't. At one point in my career I would have considered myself "full stack". Over time I realized that a "full stack" engineer is a jack-of-all-trades type, which in theory, can be valuable in the right circumstances as an individual doing work alongside non-full-stack engineers. Asking a room full of "full stack" engineers to design and build a product of any complexity above CRUD will naturally lead to a self-sorting of UI/UX and server side engineers.
      - eurasiantiger 4y ago
        Exactly. Full stack engineers are sorely needed in every project because they can see the forest from the trees, not because they are experts in everything from botany to carpentry.
  - _gabe_ 4y ago
    We use SPAs and a pretty strict typescript/react stack. And I still have to know: Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc. Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics. Github actions for setting up deployment and CI. Maybe you need redis for intermediate caching, etc. In addition, before you kind of sort of had an intuition of how the data flowed through your basic stack from the database to the web page. Nowadays who the heck knows what's happening. You'll hit some api gateway endpoint which auths through a random lambda who knows where on what server, then it will go hit the actual lambda that holds the function you want to call which may reach out to a database but get intercepted by the redis cache etc etc etc. Yes modern web dev is definitely much simpler /s.
    - whatever1 4y ago
      I wouldn’t say modern web dev is simpler, I just think it is more decoupled. This helps with training for & staffing the more specialized roles that emerged.
      - deleted 4y ago
        [deleted]
    - misterpurple45 4y ago
      I see this “AWS for everything” Well-Architected stuff everywhere. AWS benefits greatly from inserting itself in between all our architectural layers. There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ tune on how to architect software.
      - epolanski 4y ago
        Architects in my company are required to have aws certificates. They can be monkeys but if they can list a dozen of AWS products and put everything there they are given the keys of everything.
  - strife25 4y ago
    Labor wasn't the issue, it was UX. Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc. Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON. As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.
    - pjmlp 4y ago
      Ajax was created by Microsoft to show Outlook on the browser....
      - diroussel 4y ago
        Not quite what I remember. XMLHttpRequest was invented by Microsoft and used in a outlook webaccess. This was only possible in IE6. But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.
    - t8sr 4y ago
      AJAX in early Gmail was a massive improvement. It was mostly hand-coded javascript in a relatively thin page and it was the sweep spot. Today's version of gmail is the most bloated pile of spaghetti framework code imaginable and is far less responsive and usable than the plain HTML version.
- qrohlf 4y ago
  I both agree and disagree with this take. I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal tools are vanilla express apps with very little client-side code. It's true that a lot of newer devs really don't have a great deal of context for why React & company became the de facto default for building websites and how much we used to get done with largely server-based architectures. I wish we did a better job of teaching fundamentals here rather than bootcamping everyone straight into building SPAs. However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols, we still need to accept that there are many cases where just shoving full HTML documents over the wire isn't enough to satisfy user & stakeholder expectations. That's where stuff like LiveView, htmx, and Web Components become interesting to me. The web has evolved, and finally the server-side-application paradigm feels like it's starting to evolve along with it, and these evolutions do feel like they're novel & useful enough to deserve being called "new ideas".
  - chiefalchemist 4y ago
    Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need. Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).
    - TranquilMarmot 4y ago
      I think the basic divide is something like "CRUD forms" vs "interactive applications". I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages. Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creating an _insanely_ complex app that you could not have done five years ago with Rails (or, like this presentation is about, something like Unpoly). I think a problem is that React is just more _fun_ to work with than basic server stuff so devs want to work in it. The added complexity is worth it to have more fun. Maybe that's just me, though. I know a lot of people see React as a hammer to hit every nail with, and I was like that for a long time, but I'm starting to come back around to more server-driven use cases for simple sites. I've been messing with Fresh a lot lately and it's a nice middle ground of defaulting to rendering _most_ stuff on the server, but you can have "islands" of interactivity that get sent to the client as JS. I'm not sure if it will end up gaining traction, but it's pretty nice. https://fresh.deno.dev/ https://fresh.deno.dev/
- duxup 4y ago
  > What's old is new again. I work on some old ColdFusion apps. Some aspects feel very modern.
- robertoandred 4y ago
  What’s new is being able to use the same templating on the front and back ends with the same code, libraries, languages, and concepts.
- bandrami 4y ago
  As somebody who started in the days of cgi-bin and SSIs, I've lost track of how many wheels I've seen re-invented over the past 25 years. Fortunately I do backend which is at least slightly more stable (modulo the fact that I'm sending more or less opaque-to-me javascript rather than html). OTOH I have really surprised some PMs by producing a Perl cgi wireframe site during the course of the meeting where we designed the wireframe so we could actually try it. It's a skill more devs should really have in their back pocket.
dinkleberg 4y ago
Just want to point out that unpoly has been around for ages (looks like since 2015). This isn’t a copy of htmx.
- lewantmontreal 4y ago
  Would be interested to know if they stuck with it
  - triskweline 4y ago
    Author here. Yes, we stuck with it and evolved the concept into Unpoly 2 and soon Unpoly 3: http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly3-slides/ http://triskweline.de/unpoly3-slides/ I'd say 95% of the apps we build are now based on Unpoly, the rest on React. We now believe SPAs are not a good default for the type of apps we're building. We're still reaching for SPAs when requirements demand high-frequency user input and optimistic rendering, e.g. for a chat or online game. YMMV!
sph 4y ago
Unpoly is pretty good, and operates on a slightly different level than htmx, which is all about AJAX. Also, this slideshow is from 2016, when htmx was pretty much unknown.
- hoistbypetard 4y ago
  > Also, this slideshow is from 2016, when htmx was pretty much unknown. HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.
  - recursivedoubts 4y ago
    htmx is intercooler.js 2.0 intercooler.js started in 2013 https://github.com/bigskysoftware/intercooler-js/commit/62d3dbdb5c056ee866aba3575e148de649fc3efe https://github.com/bigskysoftware/intercooler-js/commit/62d3...
zozbot234 4y ago
I'd try to optimize logic on the client before moving more logic back to the server. This is essentially what Svelte and SolidJS do - they clean up a lot of the existing overhead of SPA solutions. Of course, rendering server-sent HTML as in the HTMX model (or perhaps HTML generated in-client via WASM) instead of doing costly fine-grained DOM updates could then be added as a further optimization.
0xblinq 4y ago
To me it looks like the opposite. It’s more batteries included, easier to use and has been around for longer. I like htmx too, but too me it’s only better on the marketing side.
t8sr 4y ago
Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 functions that make up the websockets API? Do they really need a special framework named after a coffee bean? This kinda crap is why the gmail tab uses a GB of memory.
- afavour 4y ago
  > This kinda crap is why the gmail tab uses a GB of memory. It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.
  - t8sr 4y ago
    I really don’t agree. When I worked at Google, I filed a couple of bugs for memory leaks in the new gmail, and to my knowledge they still haven’t been addressed two years later, because there are a million dependencies and the thing is so complex no one can debug it, or even come up with a reliable repro.
  - sph 4y ago
    Memory leaks, like bugs, tend to scale linearly with code size. You better believe your 100k line framework has more leaks than my 1000 line script.
    - afavour 4y ago
      Strong disagree. Frameworks are almost always going to be better profiled, better tested and have more eyes than any home crafted code. The number of lines isn’t really that relevant.
- Throwaway23459 4y ago
  React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.
dmix 4y ago
The way it componentized the different ‘cards’ or fragements with URL-style lego blocks seems to be the primary novel feature that’s layered on top of HTMLX. This is already the direction that Remix and Deno’s Fresh framework seem to be taking, at least spiritually. Isolated server-rendered-first approach and only bare minimum JS loaded for fragments/islands that need to be interactive beyond what can be loaded on pageload. The html attributes vs JSX style templates is really a matter of taste IMO. Although I haven’t used htmlx I get the feeling it would be limiting for more complex cases and involve a lot of hackery or pigeonholing complexity better served by straight up Typscript.
boxed 4y ago
I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.
- ducharmdev 4y ago
  I had this same experience. I thought it sounded like an interesting idea, but in practice I didn't think it lived up to some of the hype it often gets on HN.
- recursivedoubts 4y ago
  htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out it does, however, have an extensive event model to hook into, including pre and post request processing: https://htmx.org/reference/#events https://htmx.org/reference/#events as well as an extensions API: https://htmx.org/extensions/#defining https://htmx.org/extensions/#defining for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx, but I wouldn't call it half baked: a lot of people are using it successfully in production a less-esoteric alternative would be to use alpine.js, which is similarly embedded but uses plain ol' javascript (and offers reactivity as well, hyperscript is more of a pure event-driven language)
  - hliyan 4y ago
    Just checked alpine.js. While it's very nice, was a bit worried about this potentially risky eval use: <div x-html="(await axios.get('/some/html/partial')).data">
    - remram 4y ago
      What's risky about evaluating your own code on your own pages?
  - boxed 4y ago
caseyf 4y ago
More like a hotwire but instead of being extracted from Basecamp's work it feels like it could have been extracted from Makandra's work maintaining many different Rails apps. I think it's very good and for me, the best of the bunch. I'm moving a very large app to it (from old school RJS) and it seems to have thought of everything that I need.
cphoover 4y ago
My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me. It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.
- say_it_as_it_is 4y ago
  A web application requires connection to the web, which only exists with network connectivity. What you're trying to do is create a desktop application with tools built for the web. Therein lies the problem.
  - cphoover 4y ago
    This is not true. Applications only require network connectivity for the initial resources to be downloaded. After that they can be cached, service workers can also be used to provide for offline support. Plenty of applications can run only in the browser and don't need to have a constant connection to a back-end. I can think of a calculator app, where all of the application logic exists on the client in JavaScript, in this case a network connection is an unneeded dependency. But once you build it with a framework like liveview it cannot work without a constant connection.
- 0xblinq 4y ago
  Livewire is intended to be used where you’d otherwise need to do an API call anyway. It is not intended to handle every single click and toggle and key press. You still do that on the front end, usually with Alpine. It is a way to avoid writing backend APIs. If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.
  - sodapopcan 4y ago
    They said LiveVIEW not LiveWire. Same-ish deal, though.
smrtinsert 4y ago
I had this going back around late 2000s with jQuery and Spring Web Flow. It was absolutely glorious. Server side declarative navigation (great for dev coordination), seamless transitions, less bandwidth consumed, super simple client side rendering, no more issues with the PRG pattern and user interference, and I even think I put in even listeners to execute animations based on the return fragment. Never was allowed to put it into prod - "didnt need it". Oh well.

by qrohlf 4y ago

ramesh31 4y ago

>I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no understanding of why and how we got to where we are, and the tradeoffs that were made along the way.

whatever1 4y ago
SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
- JackMorgan 4y ago
  A lot of dev managers like that they can turn one team into two teams by splitting everyone into front and back end. This makes hiring easier. I cannot emphasize this enough. Easier hiring is a huge deal. As a secondary effect it also allows for more kingdom expansion. It's much easier to have two teams of five than one team of ten. That being said, I'd rather manage a team of five good full stack engineers than ten average front/back end engineers. The communication cost of trying to get features out the door with two teams of five is very high.
- claytongulick 4y ago
  Or maybe people don't like waiting for a page to load each time they click a button?
  - ryanbrunner 4y ago
    People want responsive interfaces, absolutely. Whether the interface is implemented as full page requests to servers or AJAX requests is irrelevant to users. Bare AJAX itself almost always will perform better than a full page request, but as you layer on additional requirements, frameworks, libraries, etc. that isn't always true. I think old reddit and new reddit are a great example of this - both are processing the same data and presenting a very similar UX. But at least for me, the relatively javascript light old reddit interface with full page reloads feels much more responsive and usable than the new site.
  - yetanother12345 4y ago
    IMHO this is a false argument. Ask yourself: Do "people2 prefer looking at "spinners" or more-or-less animated "page loading..." texts? Waiting time is the issue, the technology is not. A server generated page that loads fast beats a Framework-generated page hanging every time! As for technology: With "classic" server generated pages "people" will know what is going on (browser indication tht page is loading) and they will know what to do (wait a few seconds at most). With frameworks "people" are left out in the cold with no indication what the problem really is and no apparent remedy or path for solution as a page refresh might interfere with state logic or whatnot bringing totally undesired results.
- jrochkind1 4y ago
  That seems strange to me as being an "old school" developer I have a lot more trouble trying to get a hang of the new front-end stuff than I do learning a different back-end framework. But I guess that is just me/generational? Ironically, I feel like there are a lot more job openings for front-end than for back-end now, and I'm much more comfortable on the back-end.
- AtlasBarfed 4y ago
  Then why is every JS-bro "full stack"?
  - knightofmars 4y ago
    IMO, I think this is a valid question (though asked a bit crudely). To generalize, it's because someone who has done JavaScript programming can point to NodeJS and say, "I'm full stack." Which, while technically true, skates over the reality of NodeJS as a less than ideal backend (see Ryan Dahl and the dawn of Deno). Second, it's more lucrative to bill oneself as "full stack" even if in reality a person isn't. At one point in my career I would have considered myself "full stack". Over time I realized that a "full stack" engineer is a jack-of-all-trades type, which in theory, can be valuable in the right circumstances as an individual doing work alongside non-full-stack engineers. Asking a room full of "full stack" engineers to design and build a product of any complexity above CRUD will naturally lead to a self-sorting of UI/UX and server side engineers.
    - eurasiantiger 4y ago
      Exactly. Full stack engineers are sorely needed in every project because they can see the forest from the trees, not because they are experts in everything from botany to carpentry.
- _gabe_ 4y ago
  We use SPAs and a pretty strict typescript/react stack. And I still have to know: Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc. Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics. Github actions for setting up deployment and CI. Maybe you need redis for intermediate caching, etc. In addition, before you kind of sort of had an intuition of how the data flowed through your basic stack from the database to the web page. Nowadays who the heck knows what's happening. You'll hit some api gateway endpoint which auths through a random lambda who knows where on what server, then it will go hit the actual lambda that holds the function you want to call which may reach out to a database but get intercepted by the redis cache etc etc etc. Yes modern web dev is definitely much simpler /s.
  - whatever1 4y ago
    I wouldn’t say modern web dev is simpler, I just think it is more decoupled. This helps with training for & staffing the more specialized roles that emerged.
    - deleted 4y ago
      [deleted]
  - misterpurple45 4y ago
    I see this “AWS for everything” Well-Architected stuff everywhere. AWS benefits greatly from inserting itself in between all our architectural layers. There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ tune on how to architect software.
    - epolanski 4y ago
      Architects in my company are required to have aws certificates. They can be monkeys but if they can list a dozen of AWS products and put everything there they are given the keys of everything.
- strife25 4y ago
  Labor wasn't the issue, it was UX. Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc. Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON. As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.
  - pjmlp 4y ago
    Ajax was created by Microsoft to show Outlook on the browser....
    - diroussel 4y ago
      Not quite what I remember. XMLHttpRequest was invented by Microsoft and used in a outlook webaccess. This was only possible in IE6. But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.
  - t8sr 4y ago
    AJAX in early Gmail was a massive improvement. It was mostly hand-coded javascript in a relatively thin page and it was the sweep spot. Today's version of gmail is the most bloated pile of spaghetti framework code imaginable and is far less responsive and usable than the plain HTML version.
qrohlf 4y ago
I both agree and disagree with this take. I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal tools are vanilla express apps with very little client-side code. It's true that a lot of newer devs really don't have a great deal of context for why React & company became the de facto default for building websites and how much we used to get done with largely server-based architectures. I wish we did a better job of teaching fundamentals here rather than bootcamping everyone straight into building SPAs. However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols, we still need to accept that there are many cases where just shoving full HTML documents over the wire isn't enough to satisfy user & stakeholder expectations. That's where stuff like LiveView, htmx, and Web Components become interesting to me. The web has evolved, and finally the server-side-application paradigm feels like it's starting to evolve along with it, and these evolutions do feel like they're novel & useful enough to deserve being called "new ideas".
- chiefalchemist 4y ago
  Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need. Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).
  - TranquilMarmot 4y ago
    I think the basic divide is something like "CRUD forms" vs "interactive applications". I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages. Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creating an _insanely_ complex app that you could not have done five years ago with Rails (or, like this presentation is about, something like Unpoly). I think a problem is that React is just more _fun_ to work with than basic server stuff so devs want to work in it. The added complexity is worth it to have more fun. Maybe that's just me, though. I know a lot of people see React as a hammer to hit every nail with, and I was like that for a long time, but I'm starting to come back around to more server-driven use cases for simple sites. I've been messing with Fresh a lot lately and it's a nice middle ground of defaulting to rendering _most_ stuff on the server, but you can have "islands" of interactivity that get sent to the client as JS. I'm not sure if it will end up gaining traction, but it's pretty nice. https://fresh.deno.dev/ https://fresh.deno.dev/
duxup 4y ago
> What's old is new again. I work on some old ColdFusion apps. Some aspects feel very modern.
robertoandred 4y ago
What’s new is being able to use the same templating on the front and back ends with the same code, libraries, languages, and concepts.
bandrami 4y ago
As somebody who started in the days of cgi-bin and SSIs, I've lost track of how many wheels I've seen re-invented over the past 25 years. Fortunately I do backend which is at least slightly more stable (modulo the fact that I'm sending more or less opaque-to-me javascript rather than html). OTOH I have really surprised some PMs by producing a Perl cgi wireframe site during the course of the meeting where we designed the wireframe so we could actually try it. It's a skill more devs should really have in their back pocket.

dinkleberg 4y ago

Just want to point out that unpoly has been around for ages (looks like since 2015). This isn’t a copy of htmx.

lewantmontreal 4y ago
Would be interested to know if they stuck with it
- triskweline 4y ago
  Author here. Yes, we stuck with it and evolved the concept into Unpoly 2 and soon Unpoly 3: http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly3-slides/ http://triskweline.de/unpoly3-slides/ I'd say 95% of the apps we build are now based on Unpoly, the rest on React. We now believe SPAs are not a good default for the type of apps we're building. We're still reaching for SPAs when requirements demand high-frequency user input and optimistic rendering, e.g. for a chat or online game. YMMV!

sph 4y ago

Unpoly is pretty good, and operates on a slightly different level than htmx, which is all about AJAX. Also, this slideshow is from 2016, when htmx was pretty much unknown.

hoistbypetard 4y ago
> Also, this slideshow is from 2016, when htmx was pretty much unknown. HTMX 0.0.1 was released as "kutty" in May 2020. That was its first release. It wasn't a thing in 2016.
- recursivedoubts 4y ago
  htmx is intercooler.js 2.0 intercooler.js started in 2013 https://github.com/bigskysoftware/intercooler-js/commit/62d3dbdb5c056ee866aba3575e148de649fc3efe https://github.com/bigskysoftware/intercooler-js/commit/62d3...

zozbot234 4y ago

I'd try to optimize logic on the client before moving more logic back to the server. This is essentially what Svelte and SolidJS do - they clean up a lot of the existing overhead of SPA solutions. Of course, rendering server-sent HTML as in the HTMX model (or perhaps HTML generated in-client via WASM) instead of doing costly fine-grained DOM updates could then be added as a further optimization.

0xblinq 4y ago

To me it looks like the opposite. It’s more batteries included, easier to use and has been around for longer. I like htmx too, but too me it’s only better on the marketing side.

t8sr 4y ago

Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 functions that make up the websockets API? Do they really need a special framework named after a coffee bean? This kinda crap is why the gmail tab uses a GB of memory.

afavour 4y ago
> This kinda crap is why the gmail tab uses a GB of memory. It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.
- t8sr 4y ago
  I really don’t agree. When I worked at Google, I filed a couple of bugs for memory leaks in the new gmail, and to my knowledge they still haven’t been addressed two years later, because there are a million dependencies and the thing is so complex no one can debug it, or even come up with a reliable repro.
- sph 4y ago
  Memory leaks, like bugs, tend to scale linearly with code size. You better believe your 100k line framework has more leaks than my 1000 line script.
  - afavour 4y ago
    Strong disagree. Frameworks are almost always going to be better profiled, better tested and have more eyes than any home crafted code. The number of lines isn’t really that relevant.
Throwaway23459 4y ago
React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.

dmix 4y ago

The way it componentized the different ‘cards’ or fragements with URL-style lego blocks seems to be the primary novel feature that’s layered on top of HTMLX. This is already the direction that Remix and Deno’s Fresh framework seem to be taking, at least spiritually. Isolated server-rendered-first approach and only bare minimum JS loaded for fragments/islands that need to be interactive beyond what can be loaded on pageload. The html attributes vs JSX style templates is really a matter of taste IMO. Although I haven’t used htmlx I get the feeling it would be limiting for more complex cases and involve a lot of hackery or pigeonholing complexity better served by straight up Typscript.

boxed 4y ago

I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.

ducharmdev 4y ago
I had this same experience. I thought it sounded like an interesting idea, but in practice I didn't think it lived up to some of the hype it often gets on HN.
recursivedoubts 4y ago
htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out it does, however, have an extensive event model to hook into, including pre and post request processing: https://htmx.org/reference/#events https://htmx.org/reference/#events as well as an extensions API: https://htmx.org/extensions/#defining https://htmx.org/extensions/#defining for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx, but I wouldn't call it half baked: a lot of people are using it successfully in production a less-esoteric alternative would be to use alpine.js, which is similarly embedded but uses plain ol' javascript (and offers reactivity as well, hyperscript is more of a pure event-driven language)
- hliyan 4y ago
  Just checked alpine.js. While it's very nice, was a bit worried about this potentially risky eval use: <div x-html="(await axios.get('/some/html/partial')).data">
  - remram 4y ago
    What's risky about evaluating your own code on your own pages?
- boxed 4y ago

caseyf 4y ago

More like a hotwire but instead of being extracted from Basecamp's work it feels like it could have been extracted from Makandra's work maintaining many different Rails apps. I think it's very good and for me, the best of the bunch. I'm moving a very large app to it (from old school RJS) and it seems to have thought of everything that I need.

cphoover 4y ago

My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me. It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.

say_it_as_it_is 4y ago
A web application requires connection to the web, which only exists with network connectivity. What you're trying to do is create a desktop application with tools built for the web. Therein lies the problem.
- cphoover 4y ago
  This is not true. Applications only require network connectivity for the initial resources to be downloaded. After that they can be cached, service workers can also be used to provide for offline support. Plenty of applications can run only in the browser and don't need to have a constant connection to a back-end. I can think of a calculator app, where all of the application logic exists on the client in JavaScript, in this case a network connection is an unneeded dependency. But once you build it with a framework like liveview it cannot work without a constant connection.
0xblinq 4y ago
Livewire is intended to be used where you’d otherwise need to do an API call anyway. It is not intended to handle every single click and toggle and key press. You still do that on the front end, usually with Alpine. It is a way to avoid writing backend APIs. If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.
- sodapopcan 4y ago
  They said LiveVIEW not LiveWire. Same-ish deal, though.

smrtinsert 4y ago

I had this going back around late 2000s with jQuery and Spring Web Flow. It was absolutely glorious. Server side declarative navigation (great for dev coordination), seamless transitions, less bandwidth consumed, super simple client side rendering, no more issues with the PRG pattern and user interference, and I even think I put in even listeners to execute animations based on the return fragment. Never was allowed to put it into prod - "didnt need it". Oh well.