Is this HTMX in 1000 seconds ?

@larryd9577

11 ай бұрын

yes

FireShip just dropped 100 seconds of HTMX and now this. Are we all finally done with JS?

@dungeonmir

11 ай бұрын

we NEED to add HTMX to official V8 engine to finally forget about js frameworks

@MobiusCoin

11 ай бұрын

​@@dungeonmirlfg!

@universaltoons

11 ай бұрын

when JS gets overthrown, our pleas shall be known

@zekodun

11 ай бұрын

@@dungeonmir yeah well after that, six months later there's hypermedia frameworks

@rawallon

11 ай бұрын

HTMX Alpine HYPEE

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!

@heroe1486

11 ай бұрын

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.

@JoseTrigueros

11 ай бұрын

​@@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!

@sadboisibit

11 ай бұрын

HTMX + Tailwind UI is amazing. I use it for internal applications whenever I can.

@laughingvampire7555

11 ай бұрын

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"))

@arnaudpoutieu1331

10 ай бұрын

@@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?

I sense this is a coordinated release with fireship!

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

@rileypaulsen

11 ай бұрын

Specifically from 13:30-16:15

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.

@ciano5475

11 ай бұрын

Yeah it's DHTML again :)

@rileypaulsen

11 ай бұрын

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!

@TheNewton

11 ай бұрын

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.

HTMX FE with Bootstrap for the UI and a Go BE is gonna be my go to stack for simple stuff for a while 😂

@tofuman9526

11 ай бұрын

Exactly my thought

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

React: Ship more js! Next: Ship less js! HTMX: Ship no js! Whats next? Yew in production?

@Jabberwockybird

2 ай бұрын

What's next? Your web footprint is just a single download link to a traditional application. I kid though, I like the hypermedia concept

Just want to mention Unpoly to me feels like a more mature version of HTMX. Definitely worth checking out!

@talideon

11 ай бұрын

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.

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.

@fennecbesixdouze1794

11 ай бұрын

Combining htmx with alpine makes less than zero sense. There's nothing htmx does that isn't duplicated by alpine.

@nightshade427

11 ай бұрын

​​​@@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.

@darkness1130

11 ай бұрын

do you mind sharing those advanced patterns ? =)

@nebulousnomad

11 ай бұрын

​@@darkness1130+1. Came here to ask for an example

@nattysweg343

11 ай бұрын

+2 would like to also see an example

I liked this approach!!! We see a lot of "simple" pages with heavy JS libs, htmx is a great option.

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.

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.

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.

[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.

00:56 actually old scenexe did use json, there was sometimes more than 10 seconds input delay (ping)

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.

Laughed out loud at "The name is 103ThousandAgen

Transitioning from front to backend is also known as a "reach around" - George Hotz

@windows99

11 ай бұрын

But is it good or bad?

@gabrielpauna62

11 ай бұрын

​@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 ?

@mikerollin4073

11 ай бұрын

@@windows99 Depends on what ur into

@windows99

11 ай бұрын

@@mikerollin4073 Women

@gabrielpauna62

11 ай бұрын

@windows99 🤣 then go with the simple stuff you'll have more time for what your into

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?

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?

I like this nuanced approach to plusses and minuses on why to use a thing...

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.

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

So this guy is like Doctor Disrespect but for coding?

@ThePrimeTimeagen

11 ай бұрын

i would like to say that dr is prime for gaming...

@Draggeta

11 ай бұрын

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

2 ай бұрын

Maybe like the Donut Operator of programming

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.

Our UI is cruddy, does that count as a good fit for HTMX?

The reach-into-the-backendagen

oh, Contexte reference from other video. I loved that french dudes presentation

In the few times I had to look at React code, I almost gave up my career in technology and became a farmer

@P8860

11 ай бұрын

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.

@ncubica

11 ай бұрын

@@P8860 we have had clean jquery code already, i dont see why we cant do the same with react.

@buc991

9 ай бұрын

@@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.

What immediately comes to my mind right now is: could this be used as a dom based backend in slint?

3 months later, closing in on 200k subs!!

Seems like a potentially good solution if you make "web sites" but a bad fit for "web applications"

@ThePrimeTimeagen

11 ай бұрын

depends... its about what classification of web applications can you not do? twitter, i could see it being htmx... its just view + forms

@heroe1486

11 ай бұрын

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

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 🤔

So it's like Phoenix LiveView and Laravel Livewire but you still have to write apis?? What's the point? I am confused.

No mention of being Blazingly Fast?

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

@avid459

11 ай бұрын

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.

@buc991

9 ай бұрын

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.

I can't believe I just watched the two time himself, Dr Disrespect, give me a run down on htmx.

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.

i can only see this as an option if i don't want to use any js framework/library for the project.

It would be a mistake to use React (BLOAT!) for 99% of websites instead of something like HTMX

html sounds so much like doing JSP or equivalent again :D

@h0ph1p13

11 ай бұрын

I never did JSP. How is that similar in your eyes?

As a nood i still try to figure out if i can use htmx instead of html in my go templates

"ok, just finished the time machine.. when are we now" "browser request HTML and get innerHTML" "so 2013"

because it's helpful and on topic

Go with HTML templates and HTMX are such a joy to work with.

@lancemarchetti8673

11 ай бұрын

How do I get started with your setup? I have Win7 x86.

@davidhinojosa3680

11 ай бұрын

@@lancemarchetti8673 1. Install Linux 2. Install Go 3. Learn how to use HTML templates and HTMX 4. ??? 5. Profit

It would be great to see you build a twitter clone using this

You posted this video at the exact same time as Fireship's htmx in 100 seconds🤔

how tf do you implement a zero-allocation architecture

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_Yacketori

10 ай бұрын

"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?

Finally!

Prime how could you forget about vim dap? I'll make sure TJ sees it.

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.

So basically, the promises of XML (anyone remember XHTML), HATEOAS or the data-* attribute? What's old is new again.

@Jabberwockybird

2 ай бұрын

Yes, it's HATEOAS. The htmx articles point out that it is the old idea that everyone missed out on.

Link to article please

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

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.

@rileypaulsen

11 ай бұрын

Yeah but a language/framework that constrains [visual] design decisions is encroaching on other disciplines.

@thewhitefalcon8539

11 ай бұрын

@@rileypaulsen Then, don't use HTML.

133 thousandagen now babyyy 😎😎

hahaha Rust Foundation (TM) keeps on creeping into the agenda!

lol, go to the bottom of their essays page with all the memes.

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.

Just for fun,french names are hard to pronounce, in this case the t is mute, Guillot should sound like gooey, yo !

@protecta22

6 ай бұрын

Actually it's more giyo, gi as in gigachad

Till devs don't understand that tech used to market and sell to you some stuff. All these KZreadrs will be not considered "influencers" like in other niches

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.

@h0ph1p13

11 ай бұрын

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....

13:56 : how to get hired

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

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?

When can we trash html and switch to something that doesn't suck. JS is html's fault.

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

100k psychos !

There's absolutely nothing compelling to me for the adoption of HTMX

@ThePrimeTimeagen

11 ай бұрын

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

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.

@eduantech

11 ай бұрын

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-SG

11 ай бұрын

@@eduantech What about 2 front ends using the same backend api? To me it feels like going backwards.

@eduantech

11 ай бұрын

@@bacon-SG why make the bad problem even worse lol

@Kalasklister1337

11 ай бұрын

@@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-SG

11 ай бұрын

@@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.

Article by a man with common sense in 2023. What a shock

Hypermedia is great, HATEOS is really great, GraphQL killed it.

@Flexximilian

11 ай бұрын

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.

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?

Sorry bro leaving 'cause our boi Jeff uploaded too

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.

@SimplyDoomSlayer

11 ай бұрын

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.

@ncubica

11 ай бұрын

@@SimplyDoomSlayer indeed is also true. picke the technology that works for your use case, users don't care.

@neonraytracer8846

11 ай бұрын

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.

@marcs9451

11 ай бұрын

I complain about react and am happily married to svelte, zero regrets

@heroe1486

11 ай бұрын

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.

HTMX is the next big thing Trust me

have we all collectively forgot about html templating?

@macctosh

11 ай бұрын

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.

@heroe1486

11 ай бұрын

​@@macctoshfor a matter of fact htmx is mostly just a rebrand of an old similar project from the same author, forgot the name tho

@1998goodboy

11 ай бұрын

@@macctoshyeah and its retarded This is not software arts Its software engineering

@MrFram

11 ай бұрын

@@heroe1486intercoolerjs

@h0ph1p13

11 ай бұрын

You are right, developers are gullible people...

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.

what is your real name?

I'm so optimistic for HTMX because i failed to apply Front End JavaScript.

Idk. If this can't handle 100% of the cases you will just end up with more dependecies and more shit to learn in addition to whatever framework you usually work with

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

@h0ph1p13

11 ай бұрын

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...

Htmx just moves whole complexity to the backend. Less hurdles on front, 10x more on the back.

@randomseed

11 ай бұрын

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.

@muhwyndham

10 ай бұрын

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.

🎯 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

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

@davidhinojosa3680

11 ай бұрын

HTML templates are the secret ingredient here

@h0ph1p13

11 ай бұрын

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.

@marwentrabelsi2983

11 ай бұрын

@@h0ph1p13 try a big a project then we can talk again, not just hello worlds....

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)?

@elcugo

11 ай бұрын

Because htmx sounds more marketable.

@nhathoang9583

11 ай бұрын

I guess to copy JSX (JavaScript extension) for familarity

@janAkaliKilo

11 ай бұрын

Perhaps they want to advertise it as "html eXtended "

@JonLundy0

11 ай бұрын

Its HyperText1010

@complexity5545

11 ай бұрын

Use to be called intercooler 2.0 , but that didn't hit the same.....All about marketing easy remembered names.

Already at 106.

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.

Hey, congratulations on improving your reading to a 6th grade level. _hug_

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

AMP pages😂

for me, htmx and react etc are just a way of making js + html more limited

js framework, nah html framework, hell yeah

hotwired turbo looks more powerful and easier

@h0ph1p13

11 ай бұрын

Aaaand it is until you run into an edge case.. then htmx is mucj easier to figure out and use 🤣

@codeline9387

11 ай бұрын

@@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

i am using htmx as an excuse to learn other language

This is why I hate web dev with the passion. Every freaking week to month there is some so called new approach which is just an old approach but rebranded. Just use html5, css, vanilla javascript, and sometimes a js framework like vue, react or angular for the frontend. For the backend your simply outputing json from django, node, php, hell even perl. Just out output json. As someone who has played with web game development the only thing the backend is doing is reading and storing and outputing json. The frontend is the main problem you need to solve. Because game logic existests there.

jquery+SSR