21:43 > _"lot of ppl moved to single page application approach - a JS heavy approach"_ 53:53 > _"teams = friction"_ hehe, reminds me of the vid by Molly Rocket titled "The Only Unbreakable Law" id: 5IUj1EZwpJY which talks in detail about this friction based on a white published paper. == Keymoments == (not suitable as chapter marks - as these are not bound to the start of the topic) (also, not all are covered - only those relevant to my POI) 2:26 | 3:41 | 33:28 | 39:41 Uniform Interface between hypermedia client, server & response 3:22 | 4:06 | 12:52 | 41:54 RESTful APIs, Hideous 6:28 | 1:12:01 HyperVue: Mobile Oriented Hypermedia system 22:22 | 28:22 Lack of interactivity in old Hypermedia UI 31:51 Mix Hypermedia systems & Non-HM ones 47:48 Scripting is not for Network calls 50:45 HTMX is back-end agnostic 53:00 | 1:17:09 Be a Full Stack Dev for DRY, SSoT control & optimisability ;;; split-up teams = friction & repeatition 1:01:37 4 key areas HTMX addresses [backfilled] any tag issues a request; listen to any event; use more HTTP requests; update HTML on-the-fly (using CSS selectors or the like) 1:07:31 | 1:33:25 "rel" attribute of anchor tag for use in AI (artificial intelligence) 1:10:25 Split hypermedia API & json API 1:16:00 React --> htmx port benefits actual example 1:24:53 edge computing/ microservice/ XR (extended reality) 1:36:45 skimmed 2% ; whole 4.5% ; & full/heavy 6% cream milk
@yash1152
10 ай бұрын
4:06 lol, it was not Hideous 😂🤣 * it is HATEOAS - Hm As The Engine Of Application State. a stupid stupid acronym - don't know who hater coined it. * a much better one - like i said in the fireship 's video about htmx is: * HASE: Hm as Application State Engine.
@laughingvampire7555
Жыл бұрын
what about dojo? ExtJS(AKA Sencha)? prototype? have we forgotten about them?
@pookiepats
Жыл бұрын
Lol why do people do this. YES, similar solutions exist - you don’t actually want anything other than to be noticed - so I’m here noticing you brother. You did good, you identified a gap in the medium; good job and be well.
@kphaxx
8 ай бұрын
Books are back, bb
@ryz177
Жыл бұрын
Great content! Kudos & Thanks! I hope this channel or Carson makes a comprehensive HTMX/ Hypermedia Systems tutorial if possible with Rust...
@yash1152
Жыл бұрын
4:49 | 33:15 > _"to understand HTML is not trivial"_ > _"hypermedia client have to understand hypermedia in this uniform way"_ umh, why not use XHTML 5 i.e. XML serialized HTML? It has got stricter syntax, has existing means to validate it, 'can be transferred as parsed xml i.e. doesn't require string serialization - so, transfers can be much faster!
@AlexBunardzic
Жыл бұрын
the web is ubiquitous because it is liberal in what it accepts and strict in what it emits.
@yash1152
Жыл бұрын
@@AlexBunardzic good point; so, how about having XHTML based client as a faster alternate for those who need/want/can tolerate it? > _"web is ubiquitous because it is liberal in what it accepts and strict in what it emits."_
@pookiepats
Жыл бұрын
@@yash1152you tell us, surely you have built something with your arse yanked stack to satiate your desire to denigrate HTMX ? Was it good? Make a video. Surely you’re not just asking a question about something you enjoy never tried in a veiled attempt for validation from a KZitemr? 😂 Learn all of it stop tribing so hard. There’s no reward in it.
@ryanleemartin7758
10 ай бұрын
I think we tried that and that and it was too late. The web was already a beautiful mess and XHTML simply broke to many things. That's my memory of the effort anyway.
@yash1152
10 ай бұрын
hi, thanks for the info.@@ryanleemartin7758 * it's unfortunate that xhtml had such a bad start. * but _xhtml now won't brake any thing_ * as now it is just an xml serialization of html, i.e. it is just html 5 now the reason behind being that only whatwg is the standard authority & w3 has given up; w3 was the culprit which kept pushing xhtml in weird directions, divergent from html. > _"and XHTML simply broke to many things"_
@fennecbesixdouze1794
4 ай бұрын
HTMX doesn't enhance HTML as a hypermedia, it eliminates it. Returning HTML partials is not the same thing as returning an HTML response. Browsers cannot display HTML partials, they can only display full HTML documents. You do not have uniform interface if you build a system based on HTML partials and HTMX directives. A link in HTMX is no longer sufficient to access and then interact with that resource: you need to have the contents of the original page containing the link, and the directives for where the content is supposed to be swapped in. In other words, HTMX's whole approach is not rescuing hypermedia, it's just the jank HTML partials approach people have been doing for decades with all its own host of problems: For example, you could only rescue even basic functionality of Web 1.0 by layering on even more complexity to the server and the client, e.g. so they can both know whether the request is coming from HTMX request or is an initial page load, and respond either with the full page or the partial. This requires buying deeply into the HTMX model, it would be almost unmanageable without even adding new features to your templating language like tagged template partials (which don't exist in the most popular templating languages). If you have a website that you interact with by clicking things and it goes and fetches data and then swaps in content into the document, do you know what an actual hypermedia approach for that would be? Well, using JavaScript would be one hypermedia approach. The page that is fetching data and swapping parts of itself out would be considered one single hypermedia resource, and therefore the interactions of how that document fetches data and swaps it in should be embedded inside that document as client scripting code. Basically, this is the "islands" architecture where backend servers serve up full hypermedia pages and those pages have embedded islands of interactive client code written in JavaScript. Those little interactive islands are why many frontend libraries were developed: Evan Yue who worked at Google labs on little stadalone interactive widgets--islands of interactivity embedded on a page. Rich Harris worked at New York Times again on little widgets of interactivity embedded in news articles. Both of these use cases are very similar to Hypercard and Java Applets and are exactly what has always been described as the hypermedia approach: richly interactive elements are bound within one piece of hypermedia, interacting with the hypermedia is through the uniform interface, but within the individual hypercard/web-page you can embed richer pieces of interactivity: games, interactive widgets, etc.
@laughingvampire7555
Жыл бұрын
there is something that doesn't feels ok about this, I feel like he is confusing html with hypermedia, which aren't the same thing and still his argument of "well the client has to understand" makes no sense because the browser understands JSON & JavaScript, whether we like it or not, they are part of the web, just like CSS and are part of this format of hypermedia. I love htmx, is a great tool but adding this whole explanation of hypermedia makes a lot of noise to me, is like out of place. And reminds me about JSPs and PHPs and XML and that people abandoned those things for JSON/REST for a reason, makes me feel trapped in a loop, like groundhog day.
@AlexBunardzic
Жыл бұрын
Web browsers understand HTML, but they don't understand JSON nor JavaScript. We can run JavaScript code in a web browser, and that JavaScript code may manipulate the DOM, but web browsers have no idea what's going on. They just obey the script commands. Also, web browsers merely render JSON, but cannot act on JSON the same way they can act on hypermedia links and forms by sending HTTP requests. People have adopted REST in a bastardized form, as a glorified Remote Procedure Call (RPC) tunnelling via HTTP. That's certainly not REST, because REST is the exact opposite of RPC.
@pookiepats
Жыл бұрын
Damn OP he torched your arse. It’s interesting how confident folks will be when saying something so incorrect - it’s frustrating that more devs don’t take greater pride in actually UNDERSTANDING their craft versus accepting regurgitated information as fact.
@kphaxx
8 ай бұрын
@@pookiepats????
@fennecbesixdouze1794
4 ай бұрын
Hypermedia means uniting data, representation and interaction all into one piece of media that can be loaded, viewed and interacted with in one standalone application that provides a uniform interface. In the case of web 2.0, the standalone application providing the uniform interface is the web browser, and the hypermedia are HTML documents. I can load up any Web 2.0 application, it can be any type of application from airplane booking to a web forum, and I immediately know how to interact with it because HTML is very limited and enforces a very uniform interface. Of course you're right, you could think of even a Windows desktop application as packaging up data and interaction all into one piece of media (an executable desktop application) that can be loaded up in another standalone application: the Windows operating system. Understanding what is hypermedia and what isn't is contextual. Windows desktop applications can be thought in one sense as having a uniform interface: they're all Windows applications. But in a real sense the interface is much, much less appreciably uniform than something like an HTML document with anchor tags and forms. So it is a matter of degrees. SPA's diverge significantly from the hypermedia model because the degree of sophistication present in the use of JavaScript presents wide divergence from anything that could be seen as presenting a uniform interface. At the extreme, using technologies like WASM and the canvas allow for you to basically leave behind the uniform web interface entirely and create applications with interfaces as diverse and varied as desktop applications. The risk of hypermedia approach for for-profit ventures is that you may face difficulty distinguishing yourself in the marketplace and compete with competitors who are offering strikingly more diverse and varied interfaces. Consumers in the marketplace may love the shiny bells and whistles of fancy SPA's or WASM-driven applications, and may perceive the uniform interface of your Web 2.0 application as "dated", "clunky" etc. What Carson is trying to do at his best, I think, is explore whether maybe just a little bit of enhancement of the interactivity model of HTML can buy you a lot for your applications without you having to completely jump the shark to a full-blown SPA.
Пікірлер: 22