Carson Gross - Return To Hypermedia: Solving Javascript Fatigue Using Fundamental Web Architecture
HTML-код
- Опубликовано: 28 авг 2024
- In the last decade, the Single Page Application (SPA) architecture and the JSON API has begun to supplant the original Multi-Page Application architecture of web. This has allowed much more sophisticated web applications to be built and the approach has been formalized by libraries such as React and Vue. In the last few years, however, we have seen the rise of an associated phenomena: Javascript Fatigue in which developers and development teams admit to being overwhelmed by the complexity of the SPA architecture.
Links
HTMX: htmx.org
HTMX Discord & Github: htmx.org/talk/
Hyperscript: hyperscript.org/
Essay: Locality of Behavior: htmx.org/essay...
Essay: Hypermedia APIs vs. Data APIs: htmx.org/essay...
Essay: Hypermedia-Driven Applications htmx.org/essay...
Essay: HATEOAS: htmx.org/essay...
Essay: HATEOAS is For Humans: intercoolerjs....
__________________________________________________
About Carson Gross
Carson Gross runs Big Sky Software, which finds hot, new trends and then does the opposite of that. Big Sky Software has produced htmx, hyperscript, intercooler.js and many other open source tools. He also teaches Computer Science part time at Montana State University. His main interests are hypermedia, programming languages and general development philosophy.
__________________________________________________
About the Conference
The Philly Emerging Technologies for the Enterprise (ETE) is the Mid-Atlantic's premier developer's conference: we bring world-renowned speakers, plus some local favorites to speak about bleeding-edge technologies being used today. Our talks are delivered by down-in-the-dirt engineers; high-level, big-picture folks like CEOs, CTOs, CIOs, SVPs; and architects. Our speakers are the founders of companies you know and love, and you'll learn new technologies from the people who created them: the core committers, pioneers, and leading trainers and authors.
__________________________________________________
About the Host
Philly ETE is hosted by Chariot Solutions, a software development consultancy.
For over 20 years, companies of all sizes and industries have
looked to Chariot as a partner to help them solve their toughest software challenges, and move their business forward. Visit us at chariotsolutio...
We're hiring! Our people make us great, so we make them our priority. For 100% benefits for you and your family, a significant investment in your professional development, and an emphasis on work-life balance, consider working for Chariot. Visit our careers page for open positions, interview process, benefits, and more. chariotsolutio...
__________________________________________________
Our Sponsors
Comcast. Every day we make an impact through innovation. We drive for simplicity. We are problem solvers at heart. We tap into the diversity of our team for ideas and differing perspective. All in the pursuit of building cutting-edge products that are easy to use and accessible across all platforms. Work for Comcast: jobs.comcast.com/
Honeycomb.io. Honeycomb is the observability tool that helps modern development teams understand the systems they build and operate in production. Develop better instrumentation as you write code to reduce toil and delight your users. With Honeycomb, guess less and know more. Learn more: www.honeycomb.io/
Elsevier. Every day, research and health professionals dedicate themselves to improving outcomes for communities, patients and society at large. Elsevier is committed to quality and innovation to improve the value we deliver to researchers, research leaders, librarians, funders, healthcare professionals and educators in an open, inclusive and collaborative manner. Learn more: www.elsevier.com/
My God this is VERY persuasive! It now seems so obvious when presented this information that this is most definitely the best method of building web applications for the browser in at least 95% of situations. I am shocked how off the rails our industry has gone with building web applications. Very well done!
is very persuasive if you do not understand the real problem. the real problem is that the web was not meant for applications. The web is and should be just for static documents, nothing more.
we need to design an alternative distribution and publication mechanism for applications.
@@laughingvampire7555 but htmx also has a funny Twitter account
@@laughingvampire7555that’s ridiculous. You would essentially rebuild the web with different name and corporate DRM built in. HTTP is fine. HTML, if developed further, is more than capable of handling 90% of app needs. The rest would know their constraints and pick either a thick client or a JavaScript only SPA.
this is so simple it's groundbreaking. I'm ashamed I've never considered this before after years of wrestling with FE frameworks and horrible build tools.
PLEASE make this the next HTML standard oh gatekeepers of the web!
is called web components, it appears the problem is that you do not research at all.
web components/htmx are not an either/or, they pair really well together
I think one of the most underrated, or even completely unstated benefit to this approach is not having to waste resources and time serializing JSON. A JS framework has to take a request, serialize to JSON, send the request, then the server has to deserialize, process the request, serialize the response, send to client, which then has to again deserialize it. This is probably the most expensive part of a request cycle outside of complex DB queries, and I assume would drastically cut down round trip times as now it's just: request -> string interpolation (templating) -> response, which is just instantly inserted into the DOM as it's just html. Brilliant.
Great talk. I'm completely htmx-pilled, and excited to see where things go for the framework.
Awesome talk..i'm in!!!
Since I started developing for the web. I was always a big fan of the SSR approach ... May be because I am a java developer. Through the last decade, I saw how heavy the FE has become using new technologies that appear like mushrooms. Almost on every season there are new version, completely different than the former, new frameworks, new tutorials .... things that just added unnecessary complexity for something that built to make life easier (HTML and browser). It so funny to observe how people tend to think of the browser as virtual machine and build whole critical systems on it. I found out that something was going wrong and dedicated some time on research... Then found this wonderful concept which I am considering for migrating the whole applications FE in the future.
html and the browser were always the most complicated stuff for the original solution they attempted, which it was to distribute documents for researchers, there were already solutions like gopher or troff, solutions a lot simpler, and html and the browser made them more complicated by adding a "simplified" version of a standard called SGML, just so then HTML and XML became even more complicated on their own.
wow, that's actually very cool!
That's the way the future HTML should look like. Otherwise, it will be outdated forever.
Could html standard and browsers be upgraded to support this kind of dynamic html ability without using js at all?
absolutely. htmx shoudln't have to exist: it's how HTML should work.
@@carsongross8543 could we call it like html 6 or something or maybe jump straight 10, html 8 got a good ring to it tho..😀
is called web components dude
This is very liberating. I highly recommend watching this sales pitch for Hypercard (the inspiration for Hyperscript) from 1987 from the original creators ruclips.net/video/FquNpWdf9vg/видео.html It's funny how you can just translate much of what they're saying into webby terms instead. Instead of cards we've got HTML pages and components on the web (vs diskettes and local files), and we have (always connected) smartphones instead of a big old desktop computers. Much of what we want to achieve with our code is the same though. JavaScript and DOM manipulation has been a struggle to learn for me personally and this looks like something that can possibly fit in my little head alongside the Python and backend/operations I've taught myself over the years.
The dialectics goes on: Thesis -> Antithesis -> Synthesis (which itself becomes a new Thesis)
Can there be something like a Virtual Dom for htmx? So you do react-like Dom manipulation on the server and that automatically gets transmitted to the browser.
you dont need a virtual dom with htmx. you change the real dom using the hypermedia returned from the web server. dom manipulation on the server is templating/embedding data from your db into html
On the Mobile a pwa will solve most of the issues.
there is a javascript library called hyperscript, is a library that gives you helpers to use Rreact without the abomination of JSX
He also wrote hyperscript and mentions it in the talk
You should visit a psychiatrist dude. You posted like 5 times expressing your disagreement and your fanatic unconditional love + allegiance for React.
Excellent! Talking about the differences between what client / browser has to understand reminded me of this presentation by Scott Wlaschin ruclips.net/video/RqlnWv6NZos/видео.html
Or just use Elm?
that language is dead
@@nonefvnfvnjnjnjevjenjvonej3384 how?
Elm is the answer if you want to do VDOM/SPA stuff and think JS/TS don't have a good enough type-system. That's nowhere near the position the Htmx guy is coming from. Don't make him say Hypermedia another million times!
the main problem is that we moved away from hypermedia for a reason, because it is a mess, and the reason is a mess is the same reason JavaScript and all of the web is a mess, the browser wars, and you can learn about this in the Brendan Eich interviews for instance Lex Friedman's interview with Brendan is great and gives lots of the context about the whole deal, to remind us all or learn what happen. Netscape vs Mosaic started all, Netscape alliance with Sun Microsystems which Sun had no Fs to give, they only cared about people getting to know Java Dabba Doo and then came the evil Microsoft with its strategy of "Embrace, extend, extinguish" and made IE.
HTML was never about hypermedia, the idea of hypermedia is also product of the browser wars, and HTML was just about hypertext, hence the acronym and hypertext is just formatted text + images. Video and audio support were product of the browser wars, originally created as plugins by Netscape and this is how Hypermedia was coined, then Microsoft came with its own way to extend things and then they introduced AJAX.
html5 has given us the ability to have custom tags, is called web components, so this is just a web component library, I still prefer something like ReasonML or Rescript, a single programming language that hides the entire mess of the web from me and allows me to code in a single language using its great features to organize all the mess and by writing in this single language it compiles down to server side and browser and mobile.
this guy also forgets is that during the browser wars, in the last stage, people tried to do this, you can still find some open source programs that do this "returning of -hypermedia- html from the server" and due to the browser wars html had different behavior in each browser and then people found it to be extremely error prone, then people made object mapping to reduce the errors, and then came Microsoft with its embrace, extend extinguish strategy to give us XML and people replaced HTML with XML, XHTML, XSLT because it was a standard and you wouldn't have to use custom HTML for each browser, and people adopted it and it was more complicated and then JSON came to save us all because it was not an SGML descendent nightmare because SGML family syntax is to cumbersome.
Another complaint of back in the day is that sending back HTML was a problem because you couldn't use software to edit html, like dreamweaver and all this other software use by designers
people forget that XHTML was renamed as HTML5, relaxed some of the syntax, and it was decided that HTML5 was going to be the last version and only new tags will be added to it without any big version release other than the year of the standard, which always has been the best way to version anything, the date.
This talk is just BS.
Take his very first example: the active search implementation. There is no uniform interface being described here, the client can't just use the results of the POST to "/search" themselves, they have to have a loaded up page with a # search-results element where they can stick the HTML fragment.
The client still needs to use its in-memory state to interpret interactions with the server. You are not "firmly in the realm of hypermedia" as Carson has (wrongly, historically) defined it here, you are firmly in the same realm as the "SPA frameworks" he's lamenting.
And to be quite clear, because this is just the same as the SPA approach, you won't get any of the benefits of pure HTML from this approach: the /search fragment you return from the server will still be entirely coupled to the parent element holding the "# search-results" div/element. So you won't get the "flexibility" pointed to by the page-by-page navigation approach. You also won't get the benefits of the uniform browser interface: all of the decisions (design and implementation) about how typing in active search should work with, for example, the browser history, the browser navigation buttons, etc, is still to be made. And of course, this approach certainly doesn't give you any kind of graceful deprecation or a functioning client with browser JavaScript disabled.
Returning html fragments and replacing targeted parts of the DOM is nothing remotely new, we've been doing that since AJAX was available. And attempting to define all interactivity declaratively in HTML with frameworks based on data attributes is nothing remotely new, we've been doing that since JavaScript was available. Both of these approaches have a proven track record of not being sufficiently flexible for delivering rich experiences. They have a very good track record for very quickly delivering "good enough" functionality, but paying customers have developed much higher expectations than "good enough".
the difference from the SPA approach is instead of transforming json to html on a thick client, we just deliver the html directly to the browser from the server
Completely agree. It's an interesting approach in that it goes back to the very roots of SPA's. My first SPA app I wrote in 2012 returned fragments of HTML to populate page transitions. It was simple, and I see a point in starting to think in pages and fragments rather than components to scale back on complexity where it's not needed.
But also I don't want to build a datagrid with this. That's where React and all these frontend libraries shine
I think this is all bs, total bs
ok hipster