I'm Anti JSON, Here's Why
HTML-код
- Опубликовано: 7 июн 2024
- I love JSON. I'm thankful I don't have to use it anywhere near as often anymore. In a world with React Server Components, HTMX, Astro, and more, the need for such a primitive protocol is less and less every day.
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4se0n3 for the awesome edit 🙏 
Наука
![Eminem - Houdini [Official Music Video]](http://i.ytimg.com/vi/22tVWwmTie8/mqdefault.jpg)
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.
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
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..
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??
@@vaisakhkm783 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.
@@vaisakhkm783 he is also no longer sure that rust is the best language for some of his projects.
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 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.
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!
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.
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.
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
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)
How are you setting up event listeners on the rendered html though? Vanilla JS? Heck, that's how my old school site always did it - but that would feel insane if I had a SPA lib like react on the client.
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?
It is interesting how we do diffing when an updated HTML comes from server? Or is it a complete re-render? What's the optimizition benefit of only sending HTML from server?
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.
Rendering HTML on the server side can result in, for example, high vulnerability warnings in CheckMarx.
One of the reasons I like JSON is exactly that point of power as a programmer to define what will be done with the raw data.
Would adding a layer of protection / filter be worth it, in terms of not sending more JSON but a full HTML? I was curious just now about this point...
What about mobile? Are we just bound to use React Native/Flutter/Kotlin - Swift + JSON APIs, or is there a good way to use HTML alongside the native part of mobile?
progressive web apps are the answer
What about event listeners? If the server returns a chunk of HTML, what's the protocol to attach listeners to portions of that html?
What do you do when you have a native mobile consuming the backend server
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.
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.
How do you outsource the UI development with html ssr?
You make the HTML rendering layer consume a logic/data layer, the same logic/data layer that you would have had using CSR.
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.
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
What is the React Native way? Alot of apps have a web and mobile aspect and would love a solution for both.
This makes me think: There's probably a very efficient way to serialize HTML into binary, since so much of it is repeating text strings. Could it even be possible to write a Protobuf or Cap'n schema representing HTML? And could this be more efficient than general-purpose text compression?
In HTTP/2 you have huffman coding built in. HTTP/3 uses something else I believe.
What do you think of rendering markdown?
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 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.
With htmx, if you are sending the html, wouldn't you then need different endpoints/params to render different html structures for different use cases (where the css is not enough)?
I don't think HTMX work for that use case
ah oke @@neociber24
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.
Give it a REST Theo! 😊
who's json derulo?
So how do you send data to iOS/android clients? Have them parse html?
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.
Can you do a simple tutorial on how you would build ui data on the server and render in on the mobile?
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.
What is your solution if you also need mobile apps? I tend to default to JSON since it covers everything, but what's the approach if you had server side components and still want to have apps?
And that's why JSON is so good
You have to consider mobile clients e.g. Kotlin, Swift etc?
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.
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 🤷♂️
What if the way the app renders the UI doesn’t involve HTML? Android? iOS?
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 ...
Would like to hear your opinion on Phoenix LiveView.
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
But having a JSON API has ensured that certain subset of clients who need webhooks/API access has it resolved with the same APIs which is needed by the client. And cos, data has been standardized by JSON, frontend is loosely coupled which is better for good number of apps right?
What about servers which serve multiple clients like iOS, Android, and web? Returning HTML limits to web only.
I just found this channel. yall lit 😂. I thought I was the only one 😂. Json will be key for setting a standardized instruction tuning format for LM's though.
This is exactly what Turbo Frames, and Turbo Streams does! (The DHH library that dropped typescript)
Love using it!
You are not anti Json but anti client side rendering
what's the solution for mobile then? htmx on android works?
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.
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"
theo, i hope you will make nextjs in depth tuts really soon.
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.
very cool, but the API data is not only for the web, the mobile app need them as well
The standard return using php is a direct html for rendering before json is a thing. Are we going back to before now. 😁
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 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 😅
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
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.
"I'm Anti JSON, Here's Why"... Description: "I love JSON"...that pretty much sums up all you need to know about this guy.
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.
How does this apply to mobile apps?
Good old frontend devs finding problems when there aren't any
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.
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.
Will htmx not destroy tRPC?
I'd like to see the return of microformats as people adopt HTMX - standardized div/span structure that allows code to understand data in HTML. Facebook used to be a huge supporter of microformats with vCard and FOAF embedded in their HTML
and what about native Apps ?
I have seen an infoQ presentation years ago about using HTML as an API layer and how forms could be used for describing actions with browsers being first class clients to those APIs.
I think with HTMX such solution could be better DX than most current solutions ever could be
What about offline first apps?
Why not graphql? It’s dynamic, doesn’t have to be text protocol.
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
A lot of apps work always online. A lot of apps don’t. Both HTML and JSON have their place.
And again, we are coming back to the glorious fullstack frameworks past.
I work on a really interesting low code platform project that actually describes the entire UI in JSON. Imagine an entire page described in a hierarchy parent and child component objects with all of their properties and events described in JSON. Similar to JSON forms but taken much further. The most horrific offense is stringifying the event functions lol. I'm curious what your thoughts are on this type of model though.
Which platform is this?
Internal platform@@arnach
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.
Great video Theo.
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.
I agree that there is a pretty significant benefit for HTML over json being returned from the server.
Doing this without one of the JavaScript frameworks however becomes real messy real quick if you want even a small amount of interactivity.
Currently working on a Django project where we are trying to do this and it’s taken barely a week for the code to be filled with sprinkles of hand written interactivity. It’s a god damn mess.
htmlx is just php?
I love sveltekit in that regard i can write with my structured data in mind so i have the UserObject on the Server and just sende and rendern the stuff that I need and svelte kit will make sense of that and neither just make it Server side generated or senden the JSON and rendern it. Depending on the context. And I can specify witch one i want. I find sveltekit to be magical honestly there is so much usefull stuff that you use it for a year and stiff reguarly find things that are extremly specific to one use case but make perfekt sense for that usecase.
what about graphQL that you spewed a word and left?
I’m surprised that you would like HTMX. Very glad to see your objectivity on the subjects you cover.
PHP welcomes you with open arms
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.
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.
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
It's beautiful, how the JavaScript world has reinvented Ruby on Rails' UJS from a few years back. 👍
If we're talking about sending the smallest possible form of html down to the client with HTMX it's time rethink tailwind classes.
I remember some years ago returning raw HTML from my PHP API, and just dumping it wherever I needed using jQuery :D
shit, you just sold me on htmx, that was a legitimately really good explanation.
Audio on this vid seems wonky.. Hardcore noise reduction or something?
And just like that we’re back in the late 90s
I'm pro "send only what is absolutely necessary at first, then whatever is beneficial once the necessary stuff is done, and nothing else". Often times that usually means just html + css, potentially a minor bit of JS at first, then only the necessary json and whatever else is immediately necessary when it's needed. For those that are adamant on using rendering frameworks - Qwik does a really good job with this right out of the box.