Stuff I wrote 10 years ago has gone from; in-date, out-of-date, wildly out-of-date, legacy, outright shunned, and finally full circle to back in fashion. Got to love the web
Your point only works when API's only client is a single UI application. Often, server has to provide data to multiple UI clients and act as a data provider. JSON acts as a use-agnostic data format, where HTML would not be acceptable.
I'm sure it's got to do specifically with my niche, but I haven't had a major project in the last several years that HASN'T required multiple UI clients w/ a single API data provider. I've been using JSON for this reason as I can't find a good reason to use any alternative. At this point I'm used to going against the grain on this stuff though and just doing what works.
Just return JSON or HTML as required...? It only takes an if check for the Hx-Request header (if working with htmx), and if it doesn't exist, dump the data object to a json render method. It's really not a big issue.
totally agree... you can't call it an API when you are only returning HTML 'views' for a single app. Not saying is bad, if you only have a single app it might be better solution... but is not an API.
@@vaisakh_km he starts thinking that JS with JSDoc ain't that bad lol, I quote: "JSDoc is good enough type system" Though of under the pretext that SSR is the way. React and JSX still bad.
I prefer simplicity. That could be html or json, but devs will find a way to make either of them complex and then blame the tech stack, and then add more complexity to try to solve it.
its ironic to me that one of the supposed to be biggest mantra of dev is to not reinvent the wheel, but time and time again, you see reinvented wheels pop out and become a trend and now everyone needs to hop on that trend or else they would be left out... theres also the nail-hammer, but then after people get a new hammer everything becomes a nail for that specific hammer.. then after getting bored with that hammer, they would switch to another hammer, then everything becomes a nail for that newer hammer then theres separating presentation, with data, with processes, with other components.. then you just see trends popping out of using something as a way to merged them... are people just getting bored or something?
Hi, Web dev who started in the late 90’s here 👋 I remember when AJAX was really starting to take off, and a good portion of the time the returned response was an html partial that could be used as is. And then… uh oh, here comes a template or style change… The reason we went to serialized data exchange is so the dev responsible for the server side could send what they needed to, while the Frontend designer could then choose what they wanted to use if it and how. That separation of business and presentation was a key factor in keeping websites big and small agile to rapid changes HTMX is just a return to those early aughts sensibilities, and makes great sense for solo full stackers
Same boat. Honestly I think developing a modern SPA is just a thing of beauty. You have such clean separation. Your Backend serves a REST-API and your Client calls that. Perfectly testable, beautifully separation between backend-logic and ui, etc. HTMX is nice, but I feel like we are nearing the peak of the hype-cycle now and soon people will realize the massive issues you get mashing frontend and backend together like this en.wikipedia.org/wiki/Gartner_hype_cycle It's a cool framework and will have it's place, but SPA are just too good for too many different scenarios. HTMX could be used for mostly static websites maybe. Though honestly there is like a 99% chance that HTMX will stay super niche, like Svelte or Solid.
No problem with that, love HTMX, but in many cases you still have to maintain a data API for external users who are not rendering a ui. It means that in those cases you’re supporting a data api and a ui api separately, which is not necessarily bad or hard to do, but it is different. Also this approach may require backend engineers to know more about the front end than in previous models
Totally agree. The complexities of managing CSS in a sane way (Tailwind _really_ helps with this), handling animations and interactive state with UX and usability in mind -- these are central to being a good front-end dev. I'm still of the mind that full-stack engineers will never really cover the breadth of all that a good front-end has to offer. I'm a huge proponent for separated roles. The most successful projects I've seen operate this way, because engineers can finally focus on their area of concern and make it exceptional, rather than just okay.
@@docmars It is possible to learn both CSS and SQL at the same time. Assuming a computer science degree and decent general programming & problem solving skills, becoming a good DBA is a year of work, and becoming good at writing beautiful CSS for your semantic HTML documents is a year of work. Most people's careers are longer than two years. As long as you spend both of these years directly aiming to learn the core skills as well as possible instead of learning a frontend framework, you can definitely end up becoming a very good full stack developer.
@@docmars Enterprise full stacker here 👋 hi, how are ya. It’s entirely possible, honestly I do it every Day. Oh trust me, I’ve asked and requested to have another hire that strictly deals with design integration and templating, but for the past 13 years I’ve had to ride that road solo and do literally everything myself. Its not hard, it’s just tedious, and becomes a mental drain when you really want to focus on the server layer that day but the next 10 tickets are all about front end. I’ve now given talks and presentations about different tools, techniques, frameworks, and design aspects that focus explicitly on the presentation layer, while also doing the same thing separately for the engine layer. It’s whatever, the nature of the beast, I do what I must to stay competitive regardless.
I worked with JSON in many projects and never had a problem. JSON is very simple, which is both a weakness and a strength and you can either embrace it or fight it. And HTML being much more complex to parse, I’m doubtful it will be easier 🤷♂️
If you need to parse and use the data, JSON would be the defacto way to go. I think the point of the video is if you want to just render something on the client from the server, just send plain HTML (rather than send JSON and parse to HTML on the client).
Browser can display HTML directly, for JSON you need JS to generate HTML on the client and the update DOM ( HTML browser is showing ) sounds like a bit more work.
I have the feeling this is another hype train from developers who haven't seen the evolution of web. Sending HTML already was commonplace during jQuery days. It was a complete mess. Perhaps the new improved frameworks will make it work, but I wouldn't be hyped before we see more examples of actually large apps using this successfully.
Nah it would not be the same like before. sending HTML is a mess when user state is complex but locality of behavior does not exist. Nowadays, languages have robust templating engine by default, web component exist, and hey, htmx exist.
It depends on what you are trying to send display, CSS has come a huge way to help with the problems of the old days. Come on none of the browsers conformed to any standard back then
What the hell is this timeline? We've gone from HTML -> SHTML -> PHP -> Ajax -> Jquery -> SPAs (React). And now we're going in reverse with Astro Islands -> React Server Components -> HTMX. Yes I know it's more complex but the trend is funny. Return to monke, embrace HTML.
If you have multiple front-ends (or back-ends for that matter) using the same data, it makes much more sense to use a UI-less data format. But if your data is heavily coupled with your UI, then you might as well. For the sake of consistency, I think JSON payloads introduce a separation of concern that while on a basic level can seem excessive, as the app grows, this separation is more and more appreciated. If you start with an HTML API and later realize you need to extract specific data values for other purposes, now you suddenly have to maintain 2 different API formats.
To me it's not JSON vs HTML but javascript vs HTML. Either JSON or HTML are roughly the same size. However React compiles down to 1MB minimum. Most of my projects are the size of an mp3 file: roughly 4-5MB. That's crazy. I know to younger devs that doesn't sound crazy but to me that's crazy. My HTMX project ships roughly 200kB to the client total. It's React that's huge, not JSON.
I don't think the focus is about which one's huge and small, he said it's basically the same. The problem is the state management. Right now the client have to figure out how to render from a json data, why don't the server just tell them how?
@@MickenCZProfi React the library maybe but I've never seen a React project compile down to less than 1MB. Just doing a single component `Hello World` is almost 1MB
@@slebetman What are you bundling dude? Most of the react projects I made hardly reach 250kb or even 200kb. Are you looking at the bundle size in dev mode or somethin? Because the prod React version (react + react-dom) is around 44kb minified + gzipped. The dev mode adds a lot of descriptive warning and error tracking that result in 1.2MB dev mode builds. Prod Is waaaay smaller.
some large companies already did this. this is not new. The thing im oppose to is the data/api should be in separation of the ui, as data/api can be use in any ui (mobile/web/future). reason why you have transform service or graphql. ui changes constantly, and data/api cant keep up.
API's and JSON are never going away, because JSON works in android, iOS and many platforms not just the browser. HTMX is useless for native mobile app devs or even command line apps that need to connect to an api. Comments in JSON and maybe types would be cool tho.
Nope! HTML=markup, JSON = data transfer, I like that distinction and I think it makes sense and I'm going to die on that hill. It's just a more portable dichotomy. One that transfers to whatever rendering or layout system is used. What if another Flash comes along or maybe more current and relevant which I regard as a runtime within a runtime. Sending html back and forth just won't cut it in those cases. We limit systems to web-based and browser-only. As good and as portable HTML as a layout and rendering system is. and as much as I think it should be used EVERYWHERE that involves a screen... it just doesn't fit the bill as being the payload itself being sent back and forth. We have xml, json and even yaml to serve that role, decoupling it. Here's still *a like* of course, cause you know, discussions like this need to happen.
One problem is servicing multiple frontends (Android and iOS apps, web, etc), specially when mixing native apps with web. Decoupling the data model from the view allows reusing the same endpoints and schemas to be consumed by multiple clients. It depends on the context and requirements of your project
one could still perform the decoupling in their backend architecture, without requiring any json or extra public API layer until it was actually necessary, most web projects probably will never need it.
An architect I worked with in the past really pushed the idea of APIs providing multiple media types to represent the same schema so that you could use the same API to fire off the same data in HTML or JSON depending on what the end user actually needs.
@@avidrucker what do you want to know about it? It's an email client with a sidebar and 2 panes. You can create different inboxes on the fly. There are 2 level modals, tabs, infinite scroll.
The issue with anything other than JSON is having to create multiple APIs just to support different clients. Like ok... I use tRPC, but now I also have to create another rest API to handle a different client or whatever... It's just bonkers to me. I do agree that maybe JSON isn't the best thing to handle data transfer, but it is definitely the best we have right now. Anyone suggesting we go back in time to HTML is just ridiculous unless it's specifically for browser apps, which isn't always the main client for any project. If you take Tinder for example, the browser based app came after the iOS app, same with Instagram.
If you generate HTML server side or client side you still generate it. In the world of micro services what is really the difference between client consuming JSON to generating HTML and server consuming same API ( potentially using protobufs or being same process ) to generate HTML that is shipped to the client?
@@fulconandroadcone9488 not all clients want HTML. Some clients want JSON or some other... when you deal with apps that have to talk to other apps for integration purposes or if you have a mobile app that consumes the same data as your web app. Why would you add extra complexity to your backend to respond in multiple ways, especially when you scope it all out and realize that those are in fact responsibilities of the client.
I think (as always) that it depends on your precise use case, not saying that your frontend should consume JSON per se but that if you have multiple frontends consuming the same data, you'll probably end up consuming a common api (be it server side if you use RSC or HTMX)
This used to be the standard 15 years ago, I remember working on dozens of sites that would just pull html to render page, it gets muddy and slow pretty quick. Obviously it was done differently than some basic API call but we seem to be going full circle to the basics of programming in 2008.
My initial response when Prime started talking about HTMX was the same, isn't sending JSON always going to be faster. Then at some point a couple of weeks ago it clicked in my head and I started building out a couple of demos, I am obsessed with HTMX now and baffled with the perspective it gives me of how many layers of complexity we introduced over the years in order to work with the decoupled/json based architecture.
It's also funny because JSON is a _really_ slow format to both encode & decode, and is one of the noisiest markup languages in terms of wasted characters out there. Kinda baffling that it became the de-facto standard if you think about it!
@@dpgwalter I think it's just misused. It's excellent to serialize and deserialize binary objects and send them over the wire or safe to disk without having to worry about endiannes of the systems where it ends up.
@@monishbiswas1966 XML is more noisy for sure, but it also has less weird parse-time semantics so it's easier to interpret. JSON was explicitly _created_ as a JS-native tool (JavaScript Object Notation and all), so it makes sense for that domain.
@@dpgwalterthat’s both not true. JSON is very simple. A couple of accolades, quotes and commas doesn’t make is noisy. Have you seen XML? And slowness? It’s just serialisation/deserialisation. Data inside HTML would also be serialised 🤷♂️
An alternative to JSON I have been using lately is Protocall Buffers since they: - Serialize into something smaller than JSON - Are compatible with many languages - Have more data-structure's built-in - Allow for deprecating old fields or reserving unused fields However, I would love to dive deeper into HTMX. Foregoing the API data fetching in a client-side UI would be super helpful.
I’ve used them on the backend, but publishing the proto files is a pain. Do you use them on the front end and how to you ensure the correct proto file is used when the schema changes ?
@HenriqueNewsted Sort of - protobuf is more complicated to consume as you need to get the proto files and parse them, as the schema is separate from the data. Protobuf does not have a standard way of making this schema available, unlike Avero which includes a schema registry, so this is one extra hurdle for clients. I can think of a use case where I stream data using websockets - using protbuf would make sense in this scenario as each message has the same schema.
If you've got a lightweight frontend - sure do htmx, heck you could even do classic asp or php. However, we got to where we are because we wanted the client to do some work some of the rendering and some of the viewstate management, we had separate front-end & back-end teams, we had security concerns, we had architectural concerns which necessitated splitting the front from the back. Now - we're rewinding the clock to 1997? Theo, were you alive in 1997?
Yeah, I agree from a technical point of view. What really hurts is the team communication and culture. People want to be isolated as a backend or frontend developer. And when we try to force them to do something else, then they start to introduce a lot of tech debit because they don't want to learn the basics about the new language. After one decade of people isolating themselves in a small technical area, it will be hard to change everyone back to be a "full stack"
One side effect of this model which doesn't get recognized much is that you can cache responses at the "component" level! No need to re-compute a view for a post/user/whatever if you are smart about your cache headers.
You can switch on the accepts header to send JSON if the client looks for it, and HTML otherwise. You can still use the same backend, just represent the data differently.
Isn’t this just CSR vs SSR? Also the whole big user object would be fetched nonetheless, it’s just computing the html with server side code instead of JS, which essentially is just CSR -> SSR
JSON is good for remaining platform agnostic. We already live in a multi-client world, and more platforms like AR/VR are on the way. The way that we interface with technology is always changing, and having the flexibility to create a new client that can consume the same API as another is valuable.
It's nice to see the snake eating it's own tail, but what about native mobile apps, can they utilize htmx? One of the reasons pitched to me for building via an API is that you can build a mobile app or anything else with the API you already built for your site.
“JSON not behaving consistently across languages” isn’t a json problem. It’s a library in that language problem. JSON is well defined, yet people insist they know better and can deviate from the standard without consequence
Still json for decoupled apis to multiple uis. Different uis may render things differently and providing that data decoupled from the render makes sense in a lot of cases.
I agree with your points, and it looks like we are returning back to good'ol server-side rendered HTML, but way more interactive and dynamic. However, one thing you did not account for is the flexibility of API. You can consume an API not only from your frontend app, but basically any other service, different app, or anything really. Where as if you send rendered html, you remove this, and can only render 1 specific view of the data, compared to consuming API 10 different ways in 10 different apps, or even other services to compose the data.
I have some reasons to believe that HTMX is an awesome step forward in web development and you just gave me more reasons from a different perspective. Thank you.
I like clean separation between client and server. It's important for security policy, it's important for error handling, and it's important for understanding time and what can impact the user experience.
I see compatibility issues when it comes to supporting multiple targets beyond just web based stuff. At a certain point, you have to realize the tradeoff is between network, compute, and storage. Even if you are using tech stack for the client that renders html...why lock yourself into that unnecessarily? Using JSON and REST APIs allows for greater compatibility in a variety of front-end scenarios. Plus, now the development of the web UI, Android/iOS app, and PC client are all separate from the concerns of building and maintaining the server back end. JavaScript and JSON exist for a reason. Use it for those reasons.
Oh my lord. Have the frontend trend-chasers finally rediscovered HTML? They kept inventing stuff to fix the problems with the last thing they invented, leaving behind a trail of deprecated mess. The rest of us pragmatic folk were doing it this way for years and skipped all that nonsense. Watch, they're going to discover PHP next.
JSON is slow and expensive, so I use Protobuf for server-to-server communication and send plain text whenever possible for client-side. I still use JSON for some metadata and structured variables, but I try to avoid it when I can.
I remember well when everybody started bad-mouthing XML: "XML is so slow and expensive, JSON is the best thing since sliced bread". Protobuf is a hot thing now but I'll wait for the next 😅
"If you have a problem with JSON behaving unexpectedly..." I was like "When does it ever behave as expected?" I do tons of data engineering, and it's mind numbing how much time I've spent figuring out how exactly to parse a JSON so that the data isn't an abominable mess.
@@JisonHyunnot sure if this is what they are referring to, but my immediate thought is, datetime handling and other data conversions that happen when the server and client use different languages.
@@NickMarcha Yeah, that would be it, but imagine using HTML for different languages also, keeping in mind that Theo's main focus is HTML vs JSON on the web, I don't see any language that doesn't support ISO 8601 date format, or Booleans or even Strings, (Standard data), if your sending something other than that, the use case is not web anymore, I feel like people started to want a harder life for themselves for no reasons, not sure hahaha, hey all have their views and views are beautiful to share.
I'm suprised - I've never had issues generating or parsing JSON assuming proper libraries are used. There may be issues interpreting the JSON you get back, such as inconsistent schema or semantics, but thats not specific to JSON.
I think the benefit of JSON is that it decouples UI from data. That means you can use the same endpoints across many applications. Or even use the same endpoint in multiple places in one codebase. But still, valid points!
as an PHP dev that had in the past was partially rerended and injecting into the dom using jquery of vanila js....... i feel like influencers just don't know what to think also just dont get into into the mobile world, they: 1. hate html with all their life, adding CSS is even worse 2. companies make a lot more money writing simple mobile apps when a faster and cheaper way to do it was a simple responsive website
Amen to point 2. Unless your app really needs access to some native behavior of a smartphone (notifications, access to phone address, share trail, etc..), you should always build a responsive website, specially with the technology that we have now.
@@rubendacostaesilva8442 Even then you can just use Ionic, which basically lets you build an app as a responsive website and still access native phone APIs. The slight performance difference doesn't really matter for 99% of apps anyway.
I mean, it seems to me like what you’re comparing is the data + html vs data + javascript rules to render it. And html is probably better for one off things, and javascript & json might be better for repetitive things, where you only need to load the javascript rules once and can reuse them multiple times for different data
I can imagine an app with real time updates where you would push potentially hundreds of mb of updates to clients vs simple interactive blog page where most responses can be long term cached. The only thing I would miss with HTMX is CSS modules, I am yet to run into something like that for server side render. Maybe I just missed it somewhere :(
4:33 I think this is a point many people understate - having the server tell the client what actions it can take is powerful. doing this means the behavior of your app is defined on the server, and thus the behavior of your app is client agnostic.
Regardless of what's sent over the wire, I'll still always want a strict separation of concerns via an API, even if the API is just a function call in the same process.
I don't like to mix data and what the client does with that data. So I can have one API that is used by several different clients in very different ways.
I like SPAs still. I like doing things on client rather than server - its a bit cheaper for the developer, gives more control to the user if they want if they reverse engineer your api (there's less coupling of frontend and backend ig, so maybe its worse for speed of development or complexity but better for flexibility and collaboration), and it provides more privacy for the user, since everything could happen on the users device instead of your servers, and you could end to end encrypt all the data to your server. But yeah different strategies have different tradeoffs
I badly disagree for so many reasons, like maybe 20+ reasons, some of them are sorting/filtering/using in other platforms (and don't tell me to use headers because that's very weird in this case)/etc. Can you do sorting and filtering with HTML YES you can, it is worth the effort, in my opinion, hell no lol, makes no sense to me, using HTML for extremely specific use cases sure, other than that, it's slapping yourself right and left without explaination.
You'd do the sorting and filtering on the server, and send the client the already sorted data to display. That may sound slow, but if you look at HTMX' examples it really isn't.
@@dpgwalter I see where your coming from and I kinda like it, but still, I wouldn't in my opinion justify to sacrifice the cross platform support, unless it's a small application and I wouldn't need to rewrite it's API's to be cross platform, because I really don't like serving the API differently using headers, unless it's extremely worth it, I will keep investigating HTMX, but for now I'm not so convinced yet.
@@JisonHyun It's really not that difficult to serve multiple response types (JSON and HTML in this case) based on the request, and you could also have a separate endpoint to serve each if you really wanted to (I think the HTMX docs mention this as well). Internally you can also use the same methods to get the data, you can just select a different function to create the response text in the very last line.
1. You create a successful project on htmx, everything works well 2. The manager says “now let’s start making native mobile applications” 3. Completely rework front + back to json, and forget htmx as "shit for clickbait video" 4. Bingo
What are you talking about? If you have to rework your backend because the API changed, or in your case, you added additional API because why would you delete your web app due to a new mobile app, you did something very wrong.
@@kaffeetscherl Hi. Ok, f.e. you create a new project front + back based on htmx pattern. Your API responds to every request with raw htmx string. You can't work with this API from kotlin or swift. Create duplicates API with json only for mobile, may be, I think it's the wrong way, hard to support
@@АртурДемидов-г7ф I don't think it's hard to support. Quite the contrary. Having just one general purpose API that is consumed by your web app, mobile app and customers is harder to maintain. Once you're live, changes to this API are expensive. You need to keep your old API up and running if you introduce breaking changes. Changes that are mobile only may impact your web app. Sometimes you need functionality internally that the customer doesn't need. Additionally, having an htmx API means you're free to change the API whenever because you always serve the correct version.
Just start out with a XML implementation and use XSLT to transform to HTMX/L(Browser), XAML (Win), XIB (Apple), or layout.xml (Android). All native UI implementations use XML-adjacent notation for defining structure. If you are just dancing around it with a JSON parser then it's not truly native. 😏
Good point Theo - it reminds me of old days when we did jquery xhr fetch and $.(#div).append(html) HTML is used only/mostly in web apps, JSON is universal and can be used by many clients (not only browsers), but mobile apps, third party apps, other APIs, so yet for most of the cases except for web does not make sense to serialize things in HTML, in that case JSON is still the right way to go. But yeah, server components is so exciting because its just cuts an entire abstraction and all we need is deliver the HTML the client needs, plus whenever we need interactivity we just use client components+hydration, so right on spot, no more API routes/fetch. Definitely the SPA boom helped with this pattern - i's almost a standard to just deliver a massive JS payload and JSON and let the client figure things out - but this comes with another layer of abstraction, fetch, json, etc. I think JSON + HTML does not "replace each other" but is more like SPA vs SSR (ofc we could do a fetch in a SPA to fetch HTML and append it, but definitely not a common pattern in React and other frameworks). RSC fetch JSON data and returns HTML. e.g we have a mobile/web app, just built an API and calls it from RSC and react native app. e.g when we have React Query + trpc being used in RSC. export async function Page() { const data = await trpc.data.getData(); // yeap we love json and it still json that can be consumed from everywhere return .... //yeap we love HTML! }
I've always preferred sending raw html and css to the client, despite my youth, I'm from the pre-2011 days of writing PHP which renders the whole DOM on the server and no fancy tailwind / react or tools of that sort to make things heavier, just keep things simple, the simplest solution to your problems is often the fastest... Obviously, don't compromise on security though
The problem with HMTX is that it doesn't have any built-in way to prevent XSS injections and nobody is warning you about them. You should use some templating library to prevent XSS authors of HMTX wrote. So what is the gain there if you need additional templating library to just render your code on server?
It's really rare that you'd _ever_ be working in a language where you send html without validation on the way. Django does it, go & its templates do it, and if you don't you're just doing it wrong.
@@dpgwalter For Node.js in an examples there's just template strings without template engines. It's showing devs "how easy it's to use htmx" without warning about XSS
React server components still use JSON. Check your response when you request a server component, you get HTML + JSON. The only reason HTML streaming works is because there's a JSON representation of the components loaded in the browser that client-side react uses to place the html correctly on the page.
Thank you, I learned about HTMX today. I love it when we try to repurpose evergreen tech like HTML instead of adding more and more layers and complexity with new tools. I rarely have issues with JSON, but I understand the overall argument.
Never had a problem with JSON, but i don't use crapy js tech, only aspnet core with razor pages, if i need a BFF i can just leverage minimal apis, if i need a component to be the result of some async call i can just create it as a cshtml file then use some light js to call it on a specific route i replaced the custom js with HTMX a while ago.
Others have said it already, but when you have multiple teams, apps, and backend, all of which need to talk to each other, you need a consistent format. You can go protobuff, or you can go REST. There's more to the world than self contained React SSR apps...
Not to be dismissive but I need to see the problem for the proposed solution here. The idea is that we were never for json to begin with. We were for the idea of ReST(representational state transfer). The idea that we could simplify an app down to an immutable data object that can be shared across environments and the apps just take shape around that object. This idea started with SOAP and XML and it was later adapted to use JSON because you don't need to ship DTDs with JSON. Its why an effort was made with graphql and why we have document based data storage nowadays to begin with. All of this effort was made so that UIs can be decoupled from the server and everything can be reconfigured as apps tied to a shape of data. This is not a server performance issue but assignment of responsibility issue. Both HTMX and server components are both a step back in that regard because we are dialing back the freedom of the UI just so we could have the server write some data to the html response and breaking a contract. Thats how it looks to me and this trend looks confusing and frankly asinine to a lot of developers. You need to be clearer on how this is a benefit and this video is not enough to make your case.
Somewhat agree, but I don't think we cover all UI scenarios, like the editing of a document. You want structured data and be able to mutate it on the client. You can't send requests for each keystroke so the solution should match the impedance of the problem you are addressing otherwise you inject noise into your design, ux and dx. Maybe this works for pages more than it does data apps, but it doesn't negate thoughtful consideration (which is what most devs who follow trends will do)
Stuff I wrote 10 years ago has gone from; in-date, out-of-date, wildly out-of-date, legacy, outright shunned, and finally full circle to back in fashion. Got to love the web
Stand still long enough and eventually everyone will catch up 😂. That’s been my strategy all along.
Lets hope we learn from the mistakes and not do another circle (spoiler: wont happen)
Then stay with old technologies.
let's see when the lamp stack will be cutting edge again lol
@@matthiasoberleitner5942 punch cards are the future!
Your point only works when API's only client is a single UI application. Often, server has to provide data to multiple UI clients and act as a data provider. JSON acts as a use-agnostic data format, where HTML would not be acceptable.
I'm sure it's got to do specifically with my niche, but I haven't had a major project in the last several years that HASN'T required multiple UI clients w/ a single API data provider. I've been using JSON for this reason as I can't find a good reason to use any alternative. At this point I'm used to going against the grain on this stuff though and just doing what works.
Just return JSON or HTML as required...? It only takes an if check for the Hx-Request header (if working with htmx), and if it doesn't exist, dump the data object to a json render method. It's really not a big issue.
@@nodidogIt is additional work for little benefit imo
@@Fernando-ry5qtIt's LESS work - you don't have to manage state on the frontend, and there are plenty of other benefits. Do what you like though 👍🏻
totally agree... you can't call it an API when you are only returning HTML 'views' for a single app. Not saying is bad, if you only have a single app it might be better solution... but is not an API.
Great to see Theo slowly get HTMX-pilled.
Yea Prime getting JS-pilled, and Theo getting HTMX-pilled
@@muhwyndham wait what? when prime started getting JS pilled??
@@vaisakh_km he starts thinking that JS with JSDoc ain't that bad lol, I quote: "JSDoc is good enough type system"
Though of under the pretext that SSR is the way. React and JSX still bad.
Or Hotwired 😂. DHH will be happy.
@@vaisakh_km he is also no longer sure that rust is the best language for some of his projects.
I prefer simplicity.
That could be html or json, but devs will find a way to make either of them complex and then blame the tech stack, and then add more complexity to try to solve it.
its ironic to me that one of the supposed to be biggest mantra of dev is to not reinvent the wheel, but time and time again, you see reinvented wheels pop out and become a trend and now everyone needs to hop on that trend or else they would be left out...
theres also the nail-hammer, but then after people get a new hammer everything becomes a nail for that specific hammer.. then after getting bored with that hammer, they would switch to another hammer, then everything becomes a nail for that newer hammer
then theres separating presentation, with data, with processes, with other components.. then you just see trends popping out of using something as a way to merged them...
are people just getting bored or something?
@@ViewportPlaythroughapparently saving 2 cpu cycles per 8,000,000 computations is just something we never knew we needed ❤😂
seriously..
Hi, Web dev who started in the late 90’s here 👋
I remember when AJAX was really starting to take off, and a good portion of the time the returned response was an html partial that could be used as is.
And then… uh oh, here comes a template or style change…
The reason we went to serialized data exchange is so the dev responsible for the server side could send what they needed to, while the Frontend designer could then choose what they wanted to use if it and how. That separation of business and presentation was a key factor in keeping websites big and small agile to rapid changes
HTMX is just a return to those early aughts sensibilities, and makes great sense for solo full stackers
Yup I was thinking about that . What happened to separation of concerns and loose vs tight coupling 😅 interesting times ahead
Same boat. Honestly I think developing a modern SPA is just a thing of beauty. You have such clean separation. Your Backend serves a REST-API and your Client calls that. Perfectly testable, beautifully separation between backend-logic and ui, etc.
HTMX is nice, but I feel like we are nearing the peak of the hype-cycle now and soon people will realize the massive issues you get mashing frontend and backend together like this en.wikipedia.org/wiki/Gartner_hype_cycle
It's a cool framework and will have it's place, but SPA are just too good for too many different scenarios. HTMX could be used for mostly static websites maybe.
Though honestly there is like a 99% chance that HTMX will stay super niche, like Svelte or Solid.
Server side includes!
No problem with that, love HTMX, but in many cases you still have to maintain a data API for external users who are not rendering a ui. It means that in those cases you’re supporting a data api and a ui api separately, which is not necessarily bad or hard to do, but it is different. Also this approach may require backend engineers to know more about the front end than in previous models
Totally agree. The complexities of managing CSS in a sane way (Tailwind _really_ helps with this), handling animations and interactive state with UX and usability in mind -- these are central to being a good front-end dev. I'm still of the mind that full-stack engineers will never really cover the breadth of all that a good front-end has to offer. I'm a huge proponent for separated roles. The most successful projects I've seen operate this way, because engineers can finally focus on their area of concern and make it exceptional, rather than just okay.
@@docmars It is possible to learn both CSS and SQL at the same time. Assuming a computer science degree and decent general programming & problem solving skills, becoming a good DBA is a year of work, and becoming good at writing beautiful CSS for your semantic HTML documents is a year of work. Most people's careers are longer than two years.
As long as you spend both of these years directly aiming to learn the core skills as well as possible instead of learning a frontend framework, you can definitely end up becoming a very good full stack developer.
@@docmars Enterprise full stacker here 👋 hi, how are ya. It’s entirely possible, honestly I do it every Day. Oh trust me, I’ve asked and requested to have another hire that strictly deals with design integration and templating, but for the past 13 years I’ve had to ride that road solo and do literally everything myself. Its not hard, it’s just tedious, and becomes a mental drain when you really want to focus on the server layer that day but the next 10 tickets are all about front end. I’ve now given talks and presentations about different tools, techniques, frameworks, and design aspects that focus explicitly on the presentation layer, while also doing the same thing separately for the engine layer.
It’s whatever, the nature of the beast, I do what I must to stay competitive regardless.
how the data is structured in the api? like small chunks of everything all over the place? isn't that cumbersome?
agree, although they are different use cases. data comes from the same place and gets rendered differently. a good design should allow that to be easy
Hell Froze over, both Prime and Theo like the same frontend thing (htmx).
There is a good reason for this ...
I worked with JSON in many projects and never had a problem. JSON is very simple, which is both a weakness and a strength and you can either embrace it or fight it. And HTML being much more complex to parse, I’m doubtful it will be easier 🤷♂️
If you need to parse and use the data, JSON would be the defacto way to go. I think the point of the video is if you want to just render something on the client from the server, just send plain HTML (rather than send JSON and parse to HTML on the client).
Browser can display HTML directly, for JSON you need JS to generate HTML on the client and the update DOM ( HTML browser is showing ) sounds like a bit more work.
@@fulconandroadcone9488 ironically, in practice, the reverse of your view is the case
@@fulconandroadcone9488 But then you need different backend for you mobile, desktop and web apps!
How do you represent an int that hasn't been assigned a value?
I have the feeling this is another hype train from developers who haven't seen the evolution of web. Sending HTML already was commonplace during jQuery days. It was a complete mess. Perhaps the new improved frameworks will make it work, but I wouldn't be hyped before we see more examples of actually large apps using this successfully.
Nah it would not be the same like before. sending HTML is a mess when user state is complex but locality of behavior does not exist.
Nowadays, languages have robust templating engine by default, web component exist, and hey, htmx exist.
It depends on what you are trying to send display, CSS has come a huge way to help with the problems of the old days. Come on none of the browsers conformed to any standard back then
Yep - Direct coupling of the server and the view.
it is absolutely that and it's why webdev is embarrassing.
Totally agree been working with those kind of solutions long time ago.
What the hell is this timeline? We've gone from HTML -> SHTML -> PHP -> Ajax -> Jquery -> SPAs (React). And now we're going in reverse with Astro Islands -> React Server Components -> HTMX.
Yes I know it's more complex but the trend is funny. Return to monke, embrace HTML.
HT🙈L
the more things change, the more they stay the same
The only thing wrong here is that PHP is not gone, it will continue forever!
htnl
lol@@saullo934
If you have multiple front-ends (or back-ends for that matter) using the same data, it makes much more sense to use a UI-less data format. But if your data is heavily coupled with your UI, then you might as well.
For the sake of consistency, I think JSON payloads introduce a separation of concern that while on a basic level can seem excessive, as the app grows, this separation is more and more appreciated. If you start with an HTML API and later realize you need to extract specific data values for other purposes, now you suddenly have to maintain 2 different API formats.
To me it's not JSON vs HTML but javascript vs HTML. Either JSON or HTML are roughly the same size. However React compiles down to 1MB minimum. Most of my projects are the size of an mp3 file: roughly 4-5MB. That's crazy. I know to younger devs that doesn't sound crazy but to me that's crazy. My HTMX project ships roughly 200kB to the client total. It's React that's huge, not JSON.
I don't think the focus is about which one's huge and small, he said it's basically the same. The problem is the state management. Right now the client have to figure out how to render from a json data, why don't the server just tell them how?
This is not true, minified and compresed, React only takes about 350 kb.
@@MickenCZProfi React the library maybe but I've never seen a React project compile down to less than 1MB. Just doing a single component `Hello World` is almost 1MB
The company I am working for React project ships almost 20MB, we are lucky it's a B2B product so we don't care much but it's still insane to me
@@slebetman
What are you bundling dude?
Most of the react projects I made hardly reach 250kb or even 200kb.
Are you looking at the bundle size in dev mode or somethin? Because the prod React version (react + react-dom) is around 44kb minified + gzipped. The dev mode adds a lot of descriptive warning and error tracking that result in 1.2MB dev mode builds. Prod Is waaaay smaller.
Sounds like we're slowly moving back to a PHP-esque time on the web. Which I'm totally fine with, to be honest.
I can’t wait to install composer again /s
some large companies already did this. this is not new. The thing im oppose to is the data/api should be in separation of the ui, as data/api can be use in any ui (mobile/web/future). reason why you have transform service or graphql. ui changes constantly, and data/api cant keep up.
API's and JSON are never going away, because JSON works in android, iOS and many platforms not just the browser. HTMX is useless for native mobile app devs or even command line apps that need to connect to an api. Comments in JSON and maybe types would be cool tho.
Exactly. It only works for internal APIs that use web apps only.
True and not true. Wait until the moment when mobile apps can handle HTML responses as well as JSON ...
Nope! HTML=markup, JSON = data transfer, I like that distinction and I think it makes sense and I'm going to die on that hill. It's just a more portable dichotomy. One that transfers to whatever rendering or layout system is used. What if another Flash comes along or maybe more current and relevant which I regard as a runtime within a runtime. Sending html back and forth just won't cut it in those cases. We limit systems to web-based and browser-only. As good and as portable HTML as a layout and rendering system is. and as much as I think it should be used EVERYWHERE that involves a screen... it just doesn't fit the bill as being the payload itself being sent back and forth. We have xml, json and even yaml to serve that role, decoupling it. Here's still *a like* of course, cause you know, discussions like this need to happen.
One problem is servicing multiple frontends (Android and iOS apps, web, etc), specially when mixing native apps with web. Decoupling the data model from the view allows reusing the same endpoints and schemas to be consumed by multiple clients. It depends on the context and requirements of your project
yeah all these htmx fans are blind, they are just grifters following the hype
one could still perform the decoupling in their backend architecture, without requiring any json or extra public API layer until it was actually necessary, most web projects probably will never need it.
@@LukeFrisken Uhhh, HTML rendering microservice?
@@fulconandroadcone9488 no, it can be done at a module or library level.
Doing so is probably necessary for testing anyway.
This is exactly what Turbo Frames, and Turbo Streams does! (The DHH library that dropped typescript)
Love using it!
An architect I worked with in the past really pushed the idea of APIs providing multiple media types to represent the same schema so that you could use the same API to fire off the same data in HTML or JSON depending on what the end user actually needs.
Good old frontend devs finding problems when there aren't any
I'm making a SPA with HTMX right now. It's amazing. I literally have a URL-friendly site and I didn't have to care about state once.
Could you share more about your SPA?
@@avidrucker what do you want to know about it? It's an email client with a sidebar and 2 panes. You can create different inboxes on the fly. There are 2 level modals, tabs, infinite scroll.
The issue with anything other than JSON is having to create multiple APIs just to support different clients. Like ok... I use tRPC, but now I also have to create another rest API to handle a different client or whatever... It's just bonkers to me. I do agree that maybe JSON isn't the best thing to handle data transfer, but it is definitely the best we have right now. Anyone suggesting we go back in time to HTML is just ridiculous unless it's specifically for browser apps, which isn't always the main client for any project. If you take Tinder for example, the browser based app came after the iOS app, same with Instagram.
If you generate HTML server side or client side you still generate it. In the world of micro services what is really the difference between client consuming JSON to generating HTML and server consuming same API ( potentially using protobufs or being same process ) to generate HTML that is shipped to the client?
@@fulconandroadcone9488 not all clients want HTML. Some clients want JSON or some other... when you deal with apps that have to talk to other apps for integration purposes or if you have a mobile app that consumes the same data as your web app. Why would you add extra complexity to your backend to respond in multiple ways, especially when you scope it all out and realize that those are in fact responsibilities of the client.
I think (as always) that it depends on your precise use case, not saying that your frontend should consume JSON per se but that if you have multiple frontends consuming the same data, you'll probably end up consuming a common api (be it server side if you use RSC or HTMX)
Give it a REST Theo! 😊
"I'm Anti JSON, Here's Why"... Description: "I love JSON"...that pretty much sums up all you need to know about this guy.
Sure of course. Getting 404 html response for an api call is a classic. And that’s no big deal
You need to check the status code anyway
This used to be the standard 15 years ago, I remember working on dozens of sites that would just pull html to render page, it gets muddy and slow pretty quick. Obviously it was done differently than some basic API call but we seem to be going full circle to the basics of programming in 2008.
My initial response when Prime started talking about HTMX was the same, isn't sending JSON always going to be faster. Then at some point a couple of weeks ago it clicked in my head and I started building out a couple of demos, I am obsessed with HTMX now and baffled with the perspective it gives me of how many layers of complexity we introduced over the years in order to work with the decoupled/json based architecture.
It's also funny because JSON is a _really_ slow format to both encode & decode, and is one of the noisiest markup languages in terms of wasted characters out there. Kinda baffling that it became the de-facto standard if you think about it!
@@dpgwalter I think it's just misused. It's excellent to serialize and deserialize binary objects and send them over the wire or safe to disk without having to worry about endiannes of the systems where it ends up.
@@dpgwalterahem, XML …
The main draw for JSON would be native decoding in JavaScript.
@@monishbiswas1966 XML is more noisy for sure, but it also has less weird parse-time semantics so it's easier to interpret. JSON was explicitly _created_ as a JS-native tool (JavaScript Object Notation and all), so it makes sense for that domain.
@@dpgwalterthat’s both not true. JSON is very simple. A couple of accolades, quotes and commas doesn’t make is noisy. Have you seen XML? And slowness? It’s just serialisation/deserialisation. Data inside HTML would also be serialised 🤷♂️
I feel privileged to witness this transition and learning but.. at times.. as someone who *just* _had to_ buy into the "current thing".. I'm exhausted
An alternative to JSON I have been using lately is Protocall Buffers since they:
- Serialize into something smaller than JSON
- Are compatible with many languages
- Have more data-structure's built-in
- Allow for deprecating old fields or reserving unused fields
However, I would love to dive deeper into HTMX. Foregoing the API data fetching in a client-side UI would be super helpful.
I’ve used them on the backend, but publishing the proto files is a pain.
Do you use them on the front end and how to you ensure the correct proto file is used when the schema changes ?
They aren't really viable for frontend yet
Protobuf is for sending information between servers. JSON is for sending to clients.
@HenriqueNewsted Sort of - protobuf is more complicated to consume as you need to get the proto files and parse them, as the schema is separate from the data.
Protobuf does not have a standard way of making this schema available, unlike Avero which includes a schema registry, so this is one extra hurdle for clients.
I can think of a use case where I stream data using websockets - using protbuf would make sense in this scenario as each message has the same schema.
If you've got a lightweight frontend - sure do htmx, heck you could even do classic asp or php. However, we got to where we are because we wanted the client to do some work some of the rendering and some of the viewstate management, we had separate front-end & back-end teams, we had security concerns, we had architectural concerns which necessitated splitting the front from the back. Now - we're rewinding the clock to 1997? Theo, were you alive in 1997?
Same thing happens to fullstack TypeScript. He seems to be mostly promoting trends that support lightweight backend, it seems
Yeah, I agree from a technical point of view.
What really hurts is the team communication and culture. People want to be isolated as a backend or frontend developer. And when we try to force them to do something else, then they start to introduce a lot of tech debit because they don't want to learn the basics about the new language.
After one decade of people isolating themselves in a small technical area, it will be hard to change everyone back to be a "full stack"
It's beautiful, how the JavaScript world has reinvented Ruby on Rails' UJS from a few years back. 👍
One side effect of this model which doesn't get recognized much is that you can cache responses at the "component" level! No need to re-compute a view for a post/user/whatever if you are smart about your cache headers.
What about other clients that want to consume the API like android apps, ios apps, or even desktop app?
You are right
You can switch on the accepts header to send JSON if the client looks for it, and HTML otherwise. You can still use the same backend, just represent the data differently.
@@dpgwalter Makes sense, is that how htmx works or is it an addition on top of it?
Isn’t this just CSR vs SSR? Also the whole big user object would be fetched nonetheless, it’s just computing the html with server side code instead of JS, which essentially is just CSR -> SSR
I think this is a pretty cool pattern. The only major flaw I can think of is losing offline mode functionality on a mobile app with eventual sync.
JSON is good for remaining platform agnostic. We already live in a multi-client world, and more platforms like AR/VR are on the way. The way that we interface with technology is always changing, and having the flexibility to create a new client that can consume the same API as another is valuable.
who's json derulo?
If we're talking about sending the smallest possible form of html down to the client with HTMX it's time rethink tailwind classes.
And just like that we’re back in the late 90s
So, Rails was doing it right all that time?? Crazy!
very cool, but the API data is not only for the web, the mobile app need them as well
Front-end client development has always been 'n mess. So glad I am a back-end developer.
Essentially we go back to early 2000 :P
More like the 90s.
It's nice to see the snake eating it's own tail, but what about native mobile apps, can they utilize htmx? One of the reasons pitched to me for building via an API is that you can build a mobile app or anything else with the API you already built for your site.
“JSON not behaving consistently across languages” isn’t a json problem. It’s a library in that language problem. JSON is well defined, yet people insist they know better and can deviate from the standard without consequence
You are not anti Json but anti client side rendering
And again, we are coming back to the glorious fullstack frameworks past.
Still json for decoupled apis to multiple uis. Different uis may render things differently and providing that data decoupled from the render makes sense in a lot of cases.
we're moving fast toward our clients/browsers being thin clients simply showing something rendered on a server.
I agree with your points, and it looks like we are returning back to good'ol server-side rendered HTML, but way more interactive and dynamic. However, one thing you did not account for is the flexibility of API. You can consume an API not only from your frontend app, but basically any other service, different app, or anything really. Where as if you send rendered html, you remove this, and can only render 1 specific view of the data, compared to consuming API 10 different ways in 10 different apps, or even other services to compose the data.
A lot of apps work always online. A lot of apps don’t. Both HTML and JSON have their place.
I have some reasons to believe that HTMX is an awesome step forward in web development and you just gave me more reasons from a different perspective. Thank you.
I like clean separation between client and server. It's important for security policy, it's important for error handling, and it's important for understanding time and what can impact the user experience.
This argument sounds backwards to me. This is not about JSON it’s about application architecture. JSON is great for APIs which are easily consumable.
It's really not. ProtoBuf on the other hand...
I see compatibility issues when it comes to supporting multiple targets beyond just web based stuff. At a certain point, you have to realize the tradeoff is between network, compute, and storage. Even if you are using tech stack for the client that renders html...why lock yourself into that unnecessarily? Using JSON and REST APIs allows for greater compatibility in a variety of front-end scenarios. Plus, now the development of the web UI, Android/iOS app, and PC client are all separate from the concerns of building and maintaining the server back end.
JavaScript and JSON exist for a reason.
Use it for those reasons.
Oh my lord. Have the frontend trend-chasers finally rediscovered HTML? They kept inventing stuff to fix the problems with the last thing they invented, leaving behind a trail of deprecated mess. The rest of us pragmatic folk were doing it this way for years and skipped all that nonsense. Watch, they're going to discover PHP next.
JSON is slow and expensive, so I use Protobuf for server-to-server communication and send plain text whenever possible for client-side. I still use JSON for some metadata and structured variables, but I try to avoid it when I can.
I remember well when everybody started bad-mouthing XML: "XML is so slow and expensive, JSON is the best thing since sliced bread". Protobuf is a hot thing now but I'll wait for the next 😅
"If you have a problem with JSON behaving unexpectedly..."
I was like "When does it ever behave as expected?" I do tons of data engineering, and it's mind numbing how much time I've spent figuring out how exactly to parse a JSON so that the data isn't an abominable mess.
Give me 1 use case that this ever happened to you or anyone else, this got me curios, cuz I heard it many times.
@@JisonHyunnot sure if this is what they are referring to, but my immediate thought is, datetime handling and other data conversions that happen when the server and client use different languages.
@@NickMarcha Yeah, that would be it, but imagine using HTML for different languages also, keeping in mind that Theo's main focus is HTML vs JSON on the web, I don't see any language that doesn't support ISO 8601 date format, or Booleans or even Strings, (Standard data), if your sending something other than that, the use case is not web anymore, I feel like people started to want a harder life for themselves for no reasons, not sure hahaha, hey all have their views and views are beautiful to share.
First mistake is that you shouldn’t parse JSON yourself 😉
I'm suprised - I've never had issues generating or parsing JSON assuming proper libraries are used.
There may be issues interpreting the JSON you get back, such as inconsistent schema or semantics, but thats not specific to JSON.
You send tiny bit of html compared to json, yes. But dont forget you include kilobyte worth of tailwind class names in it.
The reasons you are describing sound very much like the reasons we used SSR for years in the early web.
Before JSON, I build build kind of SPA with XML, sending HTML from the server was for me before SPA's.
I think the benefit of JSON is that it decouples UI from data.
That means you can use the same endpoints across many applications. Or even use the same endpoint in multiple places in one codebase.
But still, valid points!
Cool if I understood that's correctly it's basically what was done by Microsoft in ASPX WebForms Ajax Controls about 15 years ago
I accidentally read No more jobs on the thumbnail, and the first thought was like "Ah yeah, reasonable", that's ironically funny and scary
What about a backend server that will serve a browser and a native mobile app?
as an PHP dev that had in the past was partially rerended and injecting into the dom using jquery of vanila js....... i feel like influencers just don't know what to think
also just dont get into into the mobile world, they:
1. hate html with all their life, adding CSS is even worse
2. companies make a lot more money writing simple mobile apps when a faster and cheaper way to do it was a simple responsive website
Amen to point 2. Unless your app really needs access to some native behavior of a smartphone (notifications, access to phone address, share trail, etc..), you should always build a responsive website, specially with the technology that we have now.
@@rubendacostaesilva8442 Even then you can just use Ionic, which basically lets you build an app as a responsive website and still access native phone APIs. The slight performance difference doesn't really matter for 99% of apps anyway.
I mean, it seems to me like what you’re comparing is the data + html vs data + javascript rules to render it. And html is probably better for one off things, and javascript & json might be better for repetitive things, where you only need to load the javascript rules once and can reuse them multiple times for different data
I can imagine an app with real time updates where you would push potentially hundreds of mb of updates to clients vs simple interactive blog page where most responses can be long term cached.
The only thing I would miss with HTMX is CSS modules, I am yet to run into something like that for server side render. Maybe I just missed it somewhere :(
@@fulconandroadcone9488 Web components with declarative shadow DOM is a better solution than "CSS modules"and it's a built in thing native to the web.
No way to do optimistic updates in that scenario, which is part of why we have the client stuff... For the appearance of super speed.
I've been looking into HTMX and separately ruby on rails and I'm starting to feel the same about the whole javascript framework world
Theo on HTMX: it's typesafe if everything is a string
4:33
I think this is a point many people understate - having the server tell the client what actions it can take is powerful. doing this means the behavior of your app is defined on the server, and thus the behavior of your app is client agnostic.
Regardless of what's sent over the wire, I'll still always want a strict separation of concerns via an API, even if the API is just a function call in the same process.
I don't like to mix data and what the client does with that data. So I can have one API that is used by several different clients in very different ways.
HTML is just XML, it's what AJAX about in first place.
JSON is a javascript thing.
It’s as if we live in a weird world where a desire of creating new content outweighs the common sense. WTF did I just see?
Oh wait… I just realised, we do live in such a world
I like SPAs still. I like doing things on client rather than server - its a bit cheaper for the developer, gives more control to the user if they want if they reverse engineer your api (there's less coupling of frontend and backend ig, so maybe its worse for speed of development or complexity but better for flexibility and collaboration), and it provides more privacy for the user, since everything could happen on the users device instead of your servers, and you could end to end encrypt all the data to your server. But yeah different strategies have different tradeoffs
I badly disagree for so many reasons, like maybe 20+ reasons, some of them are sorting/filtering/using in other platforms (and don't tell me to use headers because that's very weird in this case)/etc.
Can you do sorting and filtering with HTML YES you can, it is worth the effort, in my opinion, hell no lol, makes no sense to me, using HTML for extremely specific use cases sure, other than that, it's slapping yourself right and left without explaination.
You'd do the sorting and filtering on the server, and send the client the already sorted data to display. That may sound slow, but if you look at HTMX' examples it really isn't.
@@dpgwalter I see where your coming from and I kinda like it, but still, I wouldn't in my opinion justify to sacrifice the cross platform support, unless it's a small application and I wouldn't need to rewrite it's API's to be cross platform, because I really don't like serving the API differently using headers, unless it's extremely worth it, I will keep investigating HTMX, but for now I'm not so convinced yet.
@@JisonHyun It's really not that difficult to serve multiple response types (JSON and HTML in this case) based on the request, and you could also have a separate endpoint to serve each if you really wanted to (I think the HTMX docs mention this as well).
Internally you can also use the same methods to get the data, you can just select a different function to create the response text in the very last line.
shit, you just sold me on htmx, that was a legitimately really good explanation.
Meanwhile on an alternate universe where every APIs respond with HTML.
**Theo: I'm Anti HTML, Here's Why.**
1. You create a successful project on htmx, everything works well
2. The manager says “now let’s start making native mobile applications”
3. Completely rework front + back to json, and forget htmx as "shit for clickbait video"
4. Bingo
What are you talking about? If you have to rework your backend because the API changed, or in your case, you added additional API because why would you delete your web app due to a new mobile app, you did something very wrong.
@@kaffeetscherl Hi. Ok, f.e. you create a new project front + back based on htmx pattern. Your API responds to every request with raw htmx string. You can't work with this API from kotlin or swift. Create duplicates API with json only for mobile, may be, I think it's the wrong way, hard to support
@@АртурДемидов-г7ф I don't think it's hard to support. Quite the contrary. Having just one general purpose API that is consumed by your web app, mobile app and customers is harder to maintain. Once you're live, changes to this API are expensive. You need to keep your old API up and running if you introduce breaking changes. Changes that are mobile only may impact your web app. Sometimes you need functionality internally that the customer doesn't need. Additionally, having an htmx API means you're free to change the API whenever because you always serve the correct version.
Just start out with a XML implementation and use XSLT to transform to HTMX/L(Browser), XAML (Win), XIB (Apple), or layout.xml (Android). All native UI implementations use XML-adjacent notation for defining structure. If you are just dancing around it with a JSON parser then it's not truly native. 😏
Good point Theo - it reminds me of old days when we did jquery xhr fetch and $.(#div).append(html)
HTML is used only/mostly in web apps, JSON is universal and can be used by many clients (not only browsers), but mobile apps, third party apps, other APIs, so yet for most of the cases except for web does not make sense to serialize things in HTML, in that case JSON is still the right way to go.
But yeah, server components is so exciting because its just cuts an entire abstraction and all we need is deliver the HTML the client needs, plus whenever we need interactivity we just use client components+hydration, so right on spot, no more API routes/fetch.
Definitely the SPA boom helped with this pattern - i's almost a standard to just deliver a massive JS payload and JSON and let the client figure things out - but this comes with another layer of abstraction, fetch, json, etc.
I think JSON + HTML does not "replace each other" but is more like SPA vs SSR (ofc we could do a fetch in a SPA to fetch HTML and append it, but definitely not a common pattern in React and other frameworks).
RSC fetch JSON data and returns HTML. e.g we have a mobile/web app, just built an API and calls it from RSC and react native app. e.g when we have React Query + trpc being used in RSC.
export async function Page() {
const data = await trpc.data.getData(); // yeap we love json and it still json that can be consumed from everywhere
return .... //yeap we love HTML!
}
PHP welcomes you with open arms
Asp Webforms and update panels were years ahead of it’s time. 😂😂😂
I've always preferred sending raw html and css to the client, despite my youth, I'm from the pre-2011 days of writing PHP which renders the whole DOM on the server and no fancy tailwind / react or tools of that sort to make things heavier, just keep things simple, the simplest solution to your problems is often the fastest... Obviously, don't compromise on security though
Tell me you don't know SSR without telling me you don't know SSR
Can't wait for XSLT to be come popular again 😅
The problem with HMTX is that it doesn't have any built-in way to prevent XSS injections and nobody is warning you about them. You should use some templating library to prevent XSS authors of HMTX wrote. So what is the gain there if you need additional templating library to just render your code on server?
It's really rare that you'd _ever_ be working in a language where you send html without validation on the way. Django does it, go & its templates do it, and if you don't you're just doing it wrong.
@@dpgwalter For Node.js in an examples there's just template strings without template engines. It's showing devs "how easy it's to use htmx" without warning about XSS
React server components still use JSON. Check your response when you request a server component, you get HTML + JSON. The only reason HTML streaming works is because there's a JSON representation of the components loaded in the browser that client-side react uses to place the html correctly on the page.
honestly didn't know json had a logo, thank you theo
Thank you, I learned about HTMX today.
I love it when we try to repurpose evergreen tech like HTML instead of adding more and more layers and complexity with new tools. I rarely have issues with JSON, but I understand the overall argument.
Stop finding problems where there aren't ANY problems. JSON is absolutely fine, it's easy to use and works well.
It's about time that Perl is embraced and we can all go full TIMTOWDY
Never had a problem with JSON, but i don't use crapy js tech, only aspnet core with razor pages, if i need a BFF i can just leverage minimal apis, if i need a component to be the result of some async call i can just create it as a cshtml file then use some light js to call it on a specific route i replaced the custom js with HTMX a while ago.
Others have said it already, but when you have multiple teams, apps, and backend, all of which need to talk to each other, you need a consistent format. You can go protobuff, or you can go REST. There's more to the world than self contained React SSR apps...
GraphDB and RDF might be the future from the past.
Not to be dismissive but I need to see the problem for the proposed solution here. The idea is that we were never for json to begin with. We were for the idea of ReST(representational state transfer). The idea that we could simplify an app down to an immutable data object that can be shared across environments and the apps just take shape around that object. This idea started with SOAP and XML and it was later adapted to use JSON because you don't need to ship DTDs with JSON. Its why an effort was made with graphql and why we have document based data storage nowadays to begin with. All of this effort was made so that UIs can be decoupled from the server and everything can be reconfigured as apps tied to a shape of data. This is not a server performance issue but assignment of responsibility issue. Both HTMX and server components are both a step back in that regard because we are dialing back the freedom of the UI just so we could have the server write some data to the html response and breaking a contract. Thats how it looks to me and this trend looks confusing and frankly asinine to a lot of developers. You need to be clearer on how this is a benefit and this video is not enough to make your case.
theo, i hope you will make nextjs in depth tuts really soon.
Somewhat agree, but I don't think we cover all UI scenarios, like the editing of a document. You want structured data and be able to mutate it on the client. You can't send requests for each keystroke so the solution should match the impedance of the problem you are addressing otherwise you inject noise into your design, ux and dx. Maybe this works for pages more than it does data apps, but it doesn't negate thoughtful consideration (which is what most devs who follow trends will do)