Recorded live on twitch, GET IN / theprimeagen MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord Have something for me to read or react to?: / theprimeagenreact
Пікірлер: 265
@daedalus507010 ай бұрын
FireShip just dropped 100 seconds of HTMX and now this. Are we all finally done with JS?
@dungeonmir10 ай бұрын
we NEED to add HTMX to official V8 engine to finally forget about js frameworks
@MobiusCoin10 ай бұрын
@@dungeonmirlfg!
@universaltoons10 ай бұрын
when JS gets overthrown, our pleas shall be known
@zekodun10 ай бұрын
@@dungeonmir yeah well after that, six months later there's hypermedia frameworks
@rawallon10 ай бұрын
HTMX Alpine HYPEE
@JoseTrigueros10 ай бұрын
As a backend developer, this gives me enough interactivity that I can create usable HTML pages. I needed a UI for a backend and was dreading trying to figure out how to tap into the React ecosystem. HTMX paired with a bit of Hyperscript, has enabled me to go further. If you're on the fence, check it out!
@heroe148610 ай бұрын
The problem is that even if you're more on the backend side of things once you know React/Vue (which doesn't take much time if you don't buy into some meta framework nonsense functionalities) it's not overwhelming at all and is easier cleaner and more versatile than those solutions, and it really starts to shine when you actually have "complex" needs and can benefit from those frameworks' large ecosystem rather than having to write them yourself or use vanilla JS.
@JoseTrigueros10 ай бұрын
@@heroe1486 100% if that's the goal, choosing some other tech might be more viable. For me specifically, I don't see myself switching to frontend React development, and HTMX is a stopgap solution that allows me to get a UI working reasonably well while not spending a lot of time onboarding. Another big plus is that I don't need to add any more tools to my development stack. Thanks for bringing up those points tho!
@sadboisibit10 ай бұрын
HTMX + Tailwind UI is amazing. I use it for internal applications whenever I can.
@laughingvampire755510 ай бұрын
dude, react can be very simple, the problem is that lots of frontend developers want to make things complicated to alleviate their insecurity with backend developers, because backend developers have this talks of "we have to make a system that has to deliver 1 billion messages per hour" and they only were saying "look, it spins and its centered" so they felt bad and then started all this overcomplicated rendering strategies. React is simple, and is simpler when you don't use JSX, there is a js library that simplifies a lot the generation of virtual DOM from JavaScript itself that you don't need babble or any compilation step, tags become function calls like hello world becomes p("hello", span("world"))
@arnaudpoutieu13319 ай бұрын
@@sadboisibit This is the path I would like to explore. In the meantime, how do you integrate security (user authenticated) into the HTTP background calls made by HTMx?
@fyasla10 ай бұрын
Is this HTMX in 1000 seconds ?
@larryd957710 ай бұрын
yes
@dummypg612910 ай бұрын
I sense this is a coordinated release with fireship!
@felipedidio469810 ай бұрын
That ramble about how to get a job and transition into the role you want should be posted as a stand alone shorts (it's at around 16:00) it's so good
@rileypaulsen10 ай бұрын
Specifically from 13:30-16:15
@stephanb.32210 ай бұрын
I build many applications using this pattern from 97 to 05 on internet explorer 4 before AJAX was a thing. simply by avoiding the full page reload by requesting new html to put in any container on the page. It was a much simpler way to build applications and the technological limitations kept feature creep in check. nice to see the pendulum goes full circle 25 years later.
@ciano547510 ай бұрын
Yeah it's DHTML again :)
@rileypaulsen10 ай бұрын
Hear me out here… what if we sent the HTML that we want the visitor to see… to the browser??? Somebody spin up a npm package!
@TheNewton10 ай бұрын
and it's even simpler now with fetch, DOMParser, and querySelect,etc being first class features to the point that HTMX is overkill even for it's own contact form example. The complication is SPA sickness has many running stacks incapable of serving simple fragments so they would need to just spit back the entire page which will offend the silliness of API design dogma.
@danailenei995910 ай бұрын
This is the most "junior" theprimeagen I've ever seen and I really appreciate that. I think he is approaching a subject in which he does not have a lot of experience in a profesional way
@nightshade42710 ай бұрын
I've been using htmx/alpine/astro combo and it's great, very simple mental model and allows for some advanced patterns that other frameworks still can't do.
@fennecbesixdouze179410 ай бұрын
Combining htmx with alpine makes less than zero sense. There's nothing htmx does that isn't duplicated by alpine.
@nightshade42710 ай бұрын
@@fennecbesixdouze1794client side interactivity isn't handled by htmx, it integrates with alpine to give these features. This lets you blend spa/mpa to achieve some awesome patterns and use cases. It makes tons of sense and is very cool combo.
@darkness113010 ай бұрын
do you mind sharing those advanced patterns ? =)
@nebulousnomad10 ай бұрын
@@darkness1130+1. Came here to ask for an example
@nattysweg34310 ай бұрын
+2 would like to also see an example
@wcrb1510 ай бұрын
HTMX FE with Bootstrap for the UI and a Go BE is gonna be my go to stack for simple stuff for a while 😂
@tofuman952610 ай бұрын
Exactly my thought
@RandomGeometryDashStuff10 ай бұрын
00:56 actually old scenexe did use json, there was sometimes more than 10 seconds input delay (ping)
@daltonyon10 ай бұрын
I liked this approach!!! We see a lot of "simple" pages with heavy JS libs, htmx is a great option.
@SimonBuchanNz10 ай бұрын
JSON is not the best option in a lot of cases, but you'd be shocked just how fast most implementations are, and depending on context it can be smaller than a straightforward binary, eg where you're doing a lot of optional fields and normally but not always small numbers. I wouldn't expect it to be used over UDP, since if you're putting the work in to get that working then manually parsing the data is probably simpler, but i wouldn't expect a huge difference either way.
@jacobroling228710 ай бұрын
Just want to mention Unpoly to me feels like a more mature version of HTMX. Definitely worth checking out!
@talideon10 ай бұрын
I would say it's more mature, but that it's more "batteries included" and is more of a framework while htmx is more of a library, which is why it often gets paired with alpine.js. Both are fantastic tools to have in your toolbox though.
@user-hx1lp6fc9r10 ай бұрын
React: Ship more js! Next: Ship less js! HTMX: Ship no js! Whats next? Yew in production?
@JabberwockybirdАй бұрын
What's next? Your web footprint is just a single download link to a traditional application. I kid though, I like the hypermedia concept
@tonywtyt10 ай бұрын
I was curious about React, but I had to get off that project after several months of pain. React on a simple web form probably wouldn't be so bad, but this project was creating an feature rich GUI editor that had to over up some specialized content/layout widgets. I feel like you really know what the hell you're doing when your working with React. The project also uses Redux, so you have to understand how to interact with that. I've been somewhat tempted to study alternatives, but I'm retiring soon and it not worth my time really get too much in the weeds with that and get my hands dirty. But, sometimes somethings sounds good until you start to try and use it. I've not heard of HTMX and I'm curious.
@Tony-dp1rl4 ай бұрын
Great article and video ... only problem I had with it was the Hypermedia vs xxxxx, when really HTMX can be used with other techniques as well.
@shavais3319 күн бұрын
To me, there are several distinct scopes of application state: View state, session state (while not logged in), login session state, and global state. Imo, having view state (things like what tabs and/or dialogs a user has open, which elements are highlighted, what's currently being hovered by the mouse, what dropdowns are open, the positions of the various scrollbars, all that kind of thing) stored in client side storage just makes sense. There can easily be quite a bit of this kind of view state that the server should definitely not know or care about and that the user perfectly well expects to go away if they open the page in a different browser or open it on a different machine but which definitely should exist and be saved in client side storage and be taken into account when some or all of the view needs to be repainted for whatever reason. (I could be convinced, maybe, that database data in the view should be updated from the server whenever a part of a view that is displaying it is redrawn, but there are a lot of things that are needed when the view is redrawn that absolutely should be stored on the client and shouldn't need to come from the server.) I like the way htmx can set the value of a css and/or dom attribute of a target html tag to the result of a crud call. That's cool. But I need some way to two-way bind css and/or dom tag attributes to client side storage variables, and then update those based on crud calls.
@jkf16m9610 ай бұрын
It would be really powerful if it can somehow support json. With jquery i made my own event delegations, for a select element that automatically retrieves its elements from the server. But it uses a map function defined as a global, a small javascript, but it could be ommited if the data from the server comes with the right format. Maybe adding attributes like "data-json-prop" to add to the inner text or edit a value, would be enough? Im not sure, ill try to make my own implementation of a generic post request but with json. Json is really useful for table information, last time i tried to generate an entire table, it lagged so much with html from the server.
@TheNewton10 ай бұрын
2:00 Technology fit - a sign of a good tech is one that explains it's "WHY"s, but the sign of a first class tool is one that would explain any simpler approaches before insisting on itself. There has never been a first class frontend library/framework because of this.
@orderandchaos_at_work10 ай бұрын
Our UI is cruddy, does that count as a good fit for HTMX?
@randomseed10 ай бұрын
[18:20] There is this ancient story about two realms and the afterlife. There was this developer who died, and angel took his soul to this special place where a single server was sending data and UI elements expressed with HTML to multiple clients. There were no issues with the availability and the team maintaining it looked happy. The developer asked "wow, what's that place?" - it's heaven, angel responded. Next the angel (named Metaprog) transferred the developer to a similar place with the same application and the same hardware. But, instead sending everything to a client as hypermedia, the back-end was transferring pure data as JSON, and there were multiple API endpoints provided by multiple micro-services. On the client side there was also a separate application taking all that data and rendering it. The team of the exact same size was working day and night, without having any minute to eat or to sleep. "That looks similar, but everyone is so unhappy" - developer observed. "Well, this is a micro-service RPC hell" - Metaprog explained.
@avalagum795710 ай бұрын
Is htmx a good choice for an app that edits a db table? That app displays a db table in a html table where each row can be edited or deleted. I think if we use htmx, then the server will needs to talk to the browser in htmx (not html), right?
@hosseines27610 ай бұрын
I was wondering, where do you gather articles from? medium? edit: I saw you road some from reddit and personal blogs, but I mean in general, How do you find them?
@TheKennyWorld10 ай бұрын
So it's like Phoenix LiveView and Laravel Livewire but you still have to write apis?? What's the point? I am confused.
@kiffeeify10 ай бұрын
What immediately comes to my mind right now is: could this be used as a dom based backend in slint?
@BlackwaterEl1te10 ай бұрын
I like this nuanced approach to plusses and minuses on why to use a thing...
@mikerollin407310 ай бұрын
Transitioning from front to backend is also known as a "reach around" - George Hotz
@windows9910 ай бұрын
But is it good or bad?
@gabrielpauna6210 ай бұрын
@windows99 depends, I would not do it, how fast do you need the website to be? And can you not just make it faster on front-end with async lazy loading or cache ... who are you catering for and why ?
@mikerollin407310 ай бұрын
@@windows99 Depends on what ur into
@windows9910 ай бұрын
@@mikerollin4073 Women
@gabrielpauna6210 ай бұрын
@windows99 🤣 then go with the simple stuff you'll have more time for what your into
@Matthew-eu4ps8 ай бұрын
According to wikipedia, hypermedia is a "nonlinear medium of information that includes graphics, audio, video, plain text and hyperlinks". I think of this a lot like a wikipedia article: text and images mixed with links which take you to other pages with text and images. I'm having trouble seeing how they are using the term in this article.
@MosiurRahman-dl5ts10 ай бұрын
No mention of being Blazingly Fast?
@alexandersemionov57909 ай бұрын
oh, Contexte reference from other video. I loved that french dudes presentation
@bonta755210 ай бұрын
i can only see this as an option if i don't want to use any js framework/library for the project.
@livioribeiro10 ай бұрын
In the few times I had to look at React code, I almost gave up my career in technology and became a farmer
@P886010 ай бұрын
I feel sorry for future devs who have to clean up react codebase when companies decide to switch to a different framework/hype of the week.
@ncubica10 ай бұрын
@@P8860 we have had clean jquery code already, i dont see why we cant do the same with react.
@buc9918 ай бұрын
@@P8860 react is beautiful and it's been here for 10 years already, prob won't go anywhere, but i truly feel sorry for ppl who decided that writing ugly html is better.
@gabrielpauna6210 ай бұрын
The modern problem spans with the issue with 3D imho ... 3d has a huge potential market but load times for 3d renders need to vastly improve, if you could get the server to render it cache it and send it then maybe finally becomes viable 🤔
@00flydragon007 ай бұрын
3 months later, closing in on 200k subs!!
@yuriblanc844610 ай бұрын
I think it's good for simple apps and when your team is mostly backend engineers. Complex ui interaction are easier to implement by having client state. Also developing server endpoint to serve html does have a lot of issues when evolving the ui compared to json. Things like elements, classes, and dom structures need to be in updated on the endpoints too. Also sometimes you may not need certain features from the start, but if happen the case you run out of luck in a self limiting framework
@avid45910 ай бұрын
HTMX can do JSON too and can have state, GitHub follows the same approach and has scaled really well by keeping things simple. If your app isn't an interactive game or something like Google Maps, docs or sheets, and is just a bunch of rectangles inside rectangles, you are likely not competent enough that you call such basic apps as complex and are likely overcomplicating basic stuff. HTMX is more than enough for simple things like email and chat clients and probably should be the defacto one for anything to do with forms.
@buc9918 ай бұрын
backend engineers just love to reinvent the wheel on frontend, because they claim to know frontend better, without doing anything harder than not styled input form in it, it's so easy, right?(why then they are so scared to learn frontend stack i wonder). So just wait they'll soon understand why frontend frameworks were invented 15 years ago, and tons of articles will appear we are dropping htmx, it's a nightmare, how to scale it, like it was many times before with other stuff.
@isaacfink12310 ай бұрын
I feel like much of the hype around htmx is based on the fact people hate js, i used it 3 years ago in a simple project and it wasn't as robust as a full frontend framework
@simoachangli10 ай бұрын
As a nood i still try to figure out if i can use htmx instead of html in my go templates
@paulstaszko3110 ай бұрын
The reach-into-the-backendagen
@dancarter559510 ай бұрын
Seems like a potentially good solution if you make "web sites" but a bad fit for "web applications"
@ThePrimeTimeagen10 ай бұрын
depends... its about what classification of web applications can you not do? twitter, i could see it being htmx... its just view + forms
@heroe148610 ай бұрын
The problem is that everyone is calling his blog a "webapp" because there is a fancy animation when you switch pages. If the distinction is Google sheets vs Gmail then yes, that's what the article says
@jenreiss310710 ай бұрын
how tf do you implement a zero-allocation architecture
@foji-video10 ай бұрын
html sounds so much like doing JSP or equivalent again :D
@h0ph1p1310 ай бұрын
I never did JSP. How is that similar in your eyes?
@halcyonramirez646910 ай бұрын
So this guy is like Doctor Disrespect but for coding?
@ThePrimeTimeagen10 ай бұрын
i would like to say that dr is prime for gaming...
@Draggeta10 ай бұрын
Glad to know that more people thought that. Almost thought they were the same guy the first time I saw him as Dr also codes.
@JabberwockybirdАй бұрын
Maybe like the Donut Operator of programming
@davidhinojosa368010 ай бұрын
Go with HTML templates and HTMX are such a joy to work with.
@lancemarchetti867310 ай бұрын
How do I get started with your setup? I have Win7 x86.
@davidhinojosa368010 ай бұрын
@@lancemarchetti8673 1. Install Linux 2. Install Go 3. Learn how to use HTML templates and HTMX 4. ??? 5. Profit
@stepansmirnov587610 ай бұрын
Prime how could you forget about vim dap? I'll make sure TJ sees it.
@gearboxworks10 ай бұрын
Wondering if they could extend HTMX to support GraphQL in addition to hypermedia? Hypermedia is awesome for long-lived apps where the owners of the server are different from those building the clients. But hypermedia typically requires backend development for the needs identified by front-end developers which can turn tasks that an individual could work on independently into a team task that requires communication and subsequent delays which adds friction and extends time to market; not ideal for those who are building clients for their own servers. Hypermedia is also very chatty which doesn’t work well for lower bandwidth devices like mobile phones whereas GraphQL requests can be one and done. It was seem to me that with some creative architecture HTMX could be extended to support GraphQL as well as hypermedia? 🤷
@Joe_Yacketori9 ай бұрын
"Hypermedia is also very chatty which doesn’t work well for lower bandwidth devices" I was wondering about that. It seems that HTMX necessitates a lot of communication with the back end that wouldn't otherwise be necessary with an SPA that only fetches a big pile of data to populate the model layer and then handles the whole view layer with JS. I get that SPAs are bloated resource hogs, but it seems that HTMX fixes that at the expense of more bandwidth and higher frequency of requests, no? Or maybe the lack of a JS bundle evens it out?
@nojerome49710 ай бұрын
I can't believe I just watched the two time himself, Dr Disrespect, give me a run down on htmx.
@khalilbessaad55539 ай бұрын
Link to article please
@deersakamoto216710 ай бұрын
It would be a mistake to use React (BLOAT!) for 99% of websites instead of something like HTMX
@thewhitefalcon853910 ай бұрын
At 7:15 you say you don't like colocation of related elements on the screen. I'd argue they almost always should be. Why? Because when you click a button you don't expect something halfway across the screen to change. It's really that simple.
@rileypaulsen10 ай бұрын
Yeah but a language/framework that constrains [visual] design decisions is encroaching on other disciplines.
@thewhitefalcon853910 ай бұрын
@@rileypaulsen Then, don't use HTML.
@jonathanrees4710 ай бұрын
You posted this video at the exact same time as Fireship's htmx in 100 seconds🤔
@JordanShurmer10 ай бұрын
Laughed out loud at "The name is 103ThousandAgen
@marcelk65149 ай бұрын
I think you misunderstood the first quote. JSON is an example of a format specific for your application. You need to program your client to understand the specific json you send from the backend, whereas HTML is universally understood by any browser
@szymonbaranowski818410 ай бұрын
because it's helpful and on topic
@GuruEvi10 ай бұрын
So basically, the promises of XML (anyone remember XHTML), HATEOAS or the data-* attribute? What's old is new again.
@JabberwockybirdАй бұрын
Yes, it's HATEOAS. The htmx articles point out that it is the old idea that everyone missed out on.
@timjenkinson2610 ай бұрын
It would be great to see you build a twitter clone using this
@Frexuz10 ай бұрын
Rails' Hotwire (TurboFrames) does not have the "limitation" of HTMX in regards to "updating many different dynamic areas". It's the exact same concept. Dno why HTMX can't implement it better ;P
@skim370810 ай бұрын
"ok, just finished the time machine.. when are we now" "browser request HTML and get innerHTML" "so 2013"
@sunderkeenin10 ай бұрын
what I'm doing with my life is eating beans with some carolina reaper cheddar mixed in and washing it down with string cheese and water while I watch this video.
@nightshade42710 ай бұрын
It's sad that hypermedia is a strange thing to put on job listing vs react, when hypermedia is the web and react circumvents it to render an app over the web. Sounds backwards to me. I mean I get it, but it is sad when web developers only know react and not the the web.
@h0ph1p1310 ай бұрын
Well I don't know react specifically but have written enough code in similar frameworks Oh and i know "the web"... htmx is much better than react for pretty much everything....
@laszlotorhosi186710 ай бұрын
Finally!
@reisvc10 ай бұрын
hahaha Rust Foundation (TM) keeps on creeping into the agenda!
@patricknelson9 ай бұрын
lol, go to the bottom of their essays page with all the memes.
@ze2like10 ай бұрын
Just for fun,french names are hard to pronounce, in this case the t is mute, Guillot should sound like gooey, yo !
@protecta225 ай бұрын
Actually it's more giyo, gi as in gigachad
@AdroSlice10 ай бұрын
HTMX is cool if you want to render your content server-side, however, that in itself blurs the backend and frontend in an in my opinion undesirable way by adding an extra layer, and can easily produce unpredictable results.
@eduantech10 ай бұрын
well the html can be in template files, as it used to be in the past, and with tailwind then there's no additional CSS layer
@bacon-SG10 ай бұрын
@@eduantech What about 2 front ends using the same backend api? To me it feels like going backwards.
@eduantech10 ай бұрын
@@bacon-SG why make the bad problem even worse lol
@Kalasklister133710 ай бұрын
@@bacon-SG This is probably one of the best questions to ask. My gut tells me that most of the time it will be more cost effective and clean to build your main web site in htmx and then design clean public JSON endpoints separately depending on what is needed. Too often whatever public api that is available is a real pain to work with when the endpoints have wonky designs made to fit the front end and not 3rd party devs.
@bacon-SG10 ай бұрын
@@Kalasklister1337 I feel like maintaining two different apis with the same business logic it's a source of bugs. Like implementing one thing in an API and forget or implement differently in the other.
@MikesGlitch9 ай бұрын
133 thousandagen now babyyy 😎😎
@hamzakhiar363610 ай бұрын
13:56 : how to get hired
@Daijyobanai8 ай бұрын
So looking at the HTMX docs, it looks like it could be easy to integrate into most frameworks, and use it most, only using something like React where its absolutely necessary. Like who wouldn't want to replace a function that uses useX, useY, useMutation, AxiosError, mutationFn, several lines of code again, OnSuccess await etc etc, with ... something simple? Never understood why React developers accept this monstrosity, when rxjs has simple subscribe with clean syntax and grammar.
@ordinarygg10 ай бұрын
Till devs don't understand that tech used to market and sell to you some stuff. All these KZbinrs will be not considered "influencers" like in other niches
@ncubica10 ай бұрын
I love how people complaints about a react, but still react get the job done. We often forget that regular users don't care about what technology we use.
@SimplyDoomSlayer10 ай бұрын
I love how people complaints about a php, but still php get the job done. We often forget that regular users don't care about what technology we use.
@ncubica10 ай бұрын
@@SimplyDoomSlayer indeed is also true. picke the technology that works for your use case, users don't care.
@neonraytracer884610 ай бұрын
I love how people complain about work, but still work gets the job done. We often forget that users don't care how much work went into it.
@marcs945110 ай бұрын
I complain about react and am happily married to svelte, zero regrets
@heroe148610 ай бұрын
Please stop with this nonsensical argument, if they don't care ... devs care. And what makes you more happy and productive would obviously affect the code you ship and thus affect users, being because it's less bug prone, you deliver faster or whatever. Unless your users don't care about that but at that point you could just become an HTML developer, hardcode everything and call it a day.
@TheLummen.10 ай бұрын
100k psychos !
@johnbell181010 ай бұрын
After watching a few of your videos, I can't help but think that you are Charlie Day. Can you confirm or deny that statement?
@brokecsstudent7 ай бұрын
I'm so optimistic for HTMX because i failed to apply Front End JavaScript.
@irlshrek10 ай бұрын
It sounds like this would be good if you are working on something with a lot of complexity, like a bloated react site. Sounds like you could side step some frustration there. I'm not sure if it makes sense to introduce this to a new project or a simple one. I might be wrong
@h0ph1p1310 ай бұрын
Define a "new project".. what are you building? 🤔 From my perspective anything that takes less than 1-2 months to develop is just a demo and not a real project...
@MegaMech10 ай бұрын
When can we trash html and switch to something that doesn't suck. JS is html's fault.
@dancarter559510 ай бұрын
There's absolutely nothing compelling to me for the adoption of HTMX
@ThePrimeTimeagen10 ай бұрын
as i try it, the more i like it. i felt pretty hesitant at first. its too... simple. then i realize, perhaps i have been too complex
@1998goodboy10 ай бұрын
have we all collectively forgot about html templating?
@macctosh10 ай бұрын
software engineering is all about the latest trend(s). Just like fashion where certain clothes/styles come into fashion and then are out of fashion and then come back into fashion. Software engineering is exactly like that.
@heroe148610 ай бұрын
@@macctoshfor a matter of fact htmx is mostly just a rebrand of an old similar project from the same author, forgot the name tho
@1998goodboy10 ай бұрын
@@macctoshyeah and its retarded This is not software arts Its software engineering
@MrFram10 ай бұрын
@@heroe1486intercoolerjs
@h0ph1p1310 ай бұрын
You are right, developers are gullible people...
@ZAcharyIndy10 ай бұрын
HTMX is the next big thing Trust me
@marwentrabelsi298310 ай бұрын
what about boilerplates and how we organize code? I see a lot of spaghetti in the horizon, sorry i won't eat this now as im in a strict diet
@davidhinojosa368010 ай бұрын
HTML templates are the secret ingredient here
@h0ph1p1310 ай бұрын
I took the time to try it on some code and it's much cleaner and simplet than Vue.js + api. No spaghetti at all.
@marwentrabelsi298310 ай бұрын
@@h0ph1p13 try a big a project then we can talk again, not just hello worlds....
@adriankal10 ай бұрын
Htmx just moves whole complexity to the backend. Less hurdles on front, 10x more on the back.
@randomseed10 ай бұрын
Nope. It's similar. When you serve HTML you usually use templates (a simple, HTML-based DSL that HTML/CSS designer can understand, a simple string after rendering). You just don't have to create and maintain 2 applications.
@muhwyndham9 ай бұрын
There nothing more complex in the backend. It's basically still the same logic, just need to be presented differently. If the BE person still unable to template UI, then FE people can just helps template it.
@zekodun10 ай бұрын
Hypermedia is great, HATEOS is really great, GraphQL killed it.
@Flexximilian10 ай бұрын
There is no reason why HATEO*A*S and GraphQl can't coexist even in the same application. So neither needs to kill the other.
@kevintanudjaja759710 ай бұрын
wow 2 minutes in and I don't understand the article mentioned, it use so many complex words, basically non-english reader can't comprehend
@krtirtho10 ай бұрын
Sorry bro leaving 'cause our boi Jeff uploaded too
@winterfriday10 ай бұрын
You'd be surprised by the inappropriate uses of json in games. I've been working on modding a game that uses json for virtually everything. Minecraft, I'm pretty sure, also stores loads of info as json. Pretty sure stardew does too. Not to say that's a good thing. From what I can tell it's horribly inefficient. Thankfully none of them transfer that over udp far as I can tell.
@AndrewTSq10 ай бұрын
for me, htmx and react etc are just a way of making js + html more limited
@randomseed10 ай бұрын
Multiple comments here start with something like "haha, try that on a big project". Well, IMHO some developers are like communist regimes in that matter: they are heroically fighting problems they've just created by using overly complex frameworks and architectures to express simple things. So, in such cases maybe it would be worth asking yourselves: would my app still be a "big project" without that turbo-advanced framework I just decided to use?
@jimshtepa542310 ай бұрын
what is your real name?
@fuzzy-027 ай бұрын
Article by a man with common sense in 2023. What a shock
@TheCocoaDaddy10 ай бұрын
This is my very first time hearing "HTMX". For those who know something about it, why is it called "HTMX" (Hyper Text Markup X(?)) instead of "HMML" (Hyper Media Markup Language) or "HML" (Hyper Media Language)?
@elcugo10 ай бұрын
Because htmx sounds more marketable.
@nhathoang958310 ай бұрын
I guess to copy JSX (JavaScript extension) for familarity
@janAkaliKilo10 ай бұрын
Perhaps they want to advertise it as "html eXtended "
@JonLundy010 ай бұрын
Its HyperText1010
@complexity554510 ай бұрын
Use to be called intercooler 2.0 , but that didn't hit the same.....All about marketing easy remembered names.
@JP-hr3xq6 ай бұрын
I'm not saying it's better or whatever, but I'm really hoping that Blazor gets traction. I just want to write C# everywhere. I hope everyone understands.
@nomadshiba10 ай бұрын
its like tailwind of js, and i dont like tailwind. its not easy if you are trying to do modern css, limited. same way htmx is limited, reminds me of a js library i wrote when i was a junior, years and years ago while jquery was new. it sounds like the solution you are looking for but then when you wanna do something different its pretty limited. for example i used to be obsessed with making html + css only sites, without any js. i would generate bunch of css and html server-side to make it work. this also reminds me of inline js as attribute days, changing `outerHTML` and stuff. old days. now i just compile everything into a single index.html file with a vite plugin
@codeline938710 ай бұрын
hotwired turbo looks more powerful and easier
@h0ph1p1310 ай бұрын
Aaaand it is until you run into an edge case.. then htmx is mucj easier to figure out and use 🤣
@codeline938710 ай бұрын
@@h0ph1p13 what edge case? i worked with turbo and built everything i need, but seeing htmx overhead make me doubt that it can help build something similar
@RogerValor10 ай бұрын
Already at 106.
@zackaryhousend671110 ай бұрын
It really aligns with the KISS method. Why unnecessarily over complicate what should be simple.
@indrajitsarkar316910 ай бұрын
js framework, nah html framework, hell yeah
@TheHackysack10 ай бұрын
Hey, congratulations on improving your reading to a 6th grade level. _hug_
@danielmoll10 ай бұрын
🎯 Key Takeaways for quick navigation: 00:00 ⚙️ Hypermedia is efficient for large grain data transfer that's optimized for the web but not optimal for other forms of architectural interaction. 01:24 👨💻 Hypermedia allows your application API to be more aggressively refactored and optimized. It also reduces the need for extensive JavaScript front-end code base. 03:15 💡 For most single-page applications, adopting hypermedia is not an either-or decision. A transitional approach is recommended, using the right tool for the job you are working on. 05:12 💎 Hypermedia works well for CRUD-style web applications and can handle updates in well-defined, nested blocks of the UI. 10:29 🎮 Hypermedia may not be a good fit for applications where UI state is updated extremely frequently, such as online games. 13:45 💼 Sociological factors, such as team familiarity and job market demands, should be considered when choosing to adopt hypermedia. 18:08 🚀 Microservices can be beneficial but their scale and complexity should be managed appropriately. 20:11 🌐 HTMX can be a valuable tool for building simple, internal-use UIs, optimizing time and resource allocation. Made with HARPA AI 👍 Upvote to improve video surfing
@alvarorodriguesschmidt850710 ай бұрын
AMP pages😂
@lynch88886 ай бұрын
Colocating data within screen space is a terrible constraint.
@itacirgabral858610 ай бұрын
jquery+SSR
@mada54233 ай бұрын
i am using htmx as an excuse to learn other language