I did the same for the previous few months. I used to have a Go backend server and a svelte frontend, I use the static svelte generator to generate static files and directly serve them as static files using caddy. Now, I only have a Go backend which spits out HTMX. It takes way less effort than I imagine. However, the performance of my tiny internal tool that only be used by a dozen of people is the same. The maintenance time does go down though.
Love that chat about type security. Anything without static code analysis warning/errors is so much harder to refactor in the future because it takes so long to hopefully find all the dependencies. And you can never be sure you have found them all
The language isn't great but the model is. Inherently stateless so easily parallelized, native ssr, and faster than JS. If the language itself was safer and less trash php as a platform would still dominate.
I built an entire app with golang and HTMX, without even realizing TEMPL existed! I used the built in text/template for Go and I didn't actually hate it.
@@superquantumcomputer it was pretty quick for me and I was working with a decently large data set. however I did have an infinite-scroll feature for the client so it only templated like 25 entries at a time.
I don't want to be THAT guy.... but the hated C# had this for decades :D type-safe, async data fetching from within the template, streaming rendering etc, hot reload in templates (now also in code). Just saying :) btw, now it's even better with with Blazor server rendering
So it's Laravel + Livewire? The modular monolith lives to fight another day son! I like to think that a PHP dev whose comfortable with Laravel could step up their skillset to Go in this type of capacity relatively easily and gain some new skills in typed languages but without a completely jarring learning experience. Go is the PHP developers secret best friend, they just don't know it yet 😅
does livewire return html? to me this feels like an old fashioned way of developing applications, what if you want some of the logic to be used for another project in an api? i used laravel with ajax before, and in there the client browser made the dom elements with the data
@@phoneywheeze if you properly architect your server, then how you expose your data should not be hard at all. Your usecases should not be aware of how data is exposed.
Can't help but realize how we're coming back full circle to the modular monolith and I quite welcome it. I'm leaning towards the Elixir/LiveView side of the fence, but I wonder: what is the breaking point? Is it the over-complication of the JS/TS ecosystem? Is it because the cognitive load for writing and maintaining SPAs is going off the roof? Is it because SPA frameworks and libraries are getting so bloated that it defeats the purpose? Is it because each of those frameworks and libraries lock you in (I'm looking at you, React "library")? Or is it simply because the SPA model was never the right one? My take on it is that the only thing we've ever needed was the ability to hook up a certain HTML element with an isolated state and logic, and the JS+HTML model never provided that out of the box, whereas with traditional AJAX+SSR it's quite easy to implement. The latter traditionally suffered from scoping issues with global JS for interaction, and most importantly global CSS for styling, and it looks like HTMX and the PHP model of rendering within the language bounds fix the former issue, and Tailwind just obliterates the latter.
I think it's like you said with the SPA model; there are cases where the hypermedia/enhanced html way of doing things isn't good for complex interdependent ui state as per the HTMX docs, and so you need the overhead of a js framework, but at the same time the modern js overhead isn't worth it for most cases, so people would take a big perf/complexity hit for the rarer case and because of the developer/career inertia; nowadays I hear people talking about having the complex JS in little "islands", so the future meta might be backend-templating/enhanced-html(whether htmx/liveview or even a future HTML spec) and light js scripting with occasional islands of heavy js
For me it's the frameworks that suck. I work on a fairly large app with mithril.js and I'm still very happy with it. But I think for most trivial cms-like apps go and htmx are a pretty good alternative. For my app (an online worksheet editor) it's not sufficient enought I think.
16:20 his issue was he mixes sveltekit (a full stack framework) with "go", either choose sveltekit or "go" with something else. sveltekit has use:enhance, he didn't need to proxy anything, all he had to do was using (s) with `use:enhance` and combine it with the `form` html attribute, and do everything with form actions, without any proxy, he doesnt have to manage any state, doesnt have to build a proxy, its just boosting. something like this +page.server.ts const count = kv.value(0); export const load = (async (event) => { return { count: await count.get() }; }) satisfies PageServerLoad; type zSetCount = z.infer; const zSetCount = object({ value: string().regex(/^\d+$/).transform(Number).pipe(number().min(0)) }); export const actions = { async setCount(event) { const form = await parseFormData(await event.request.formData(), zSetCount); const response = { setCount: form }; if (!form.valid) fail(response); await count.set(form.data.value); return response; } } satisfies Actions; +page.svelte export let data: PageData; export let form: ActionData; $: count = form?.setCount.data.count ?? data.count ?? 0; const setCountFormId = uniqueId(); + {count} - OR if you like more reuseable actions export let data: PageData; export let form: ActionData; $: count = form?.setCount.data.count ?? data.count ?? 0; const countUp = uniqueId(); const countDown = uniqueId(); + {count} - and all works even when you disable js on the browser.
The title is a bit misleading, they didn't move from sveltekit to hmtx+go, but rather from sveltekit+go which makes total sense considering they wanted to focus on one language
@@ElclarkKuhu right there is the problem...., why are you selecting a tool that you don't even understand. I kept shaking my head when he said that " we decided to use SvelteKit for our front-end and go (Echo ) for our backend" SvelteKit is the whole deal ( front and backend) if you only what the frontend use svelte!
4:47 I 100% agree with what he's saying trying to build a solid piece of software with react and some backend languages could be a nightmare in terms of security, integration and stuff.
@@erickmoya1401It doesn't because htmx people only do miniature apps for views on youtube. Nobody with a rationnal mind would use that to build a real life, big application.
@@erickmoya1401 It doesn't, it's the same factor of security as anything else that outputs HTML-usually whatever templating language you use, whether it being JSX or something else will handle things like sanitisation to prevent XSS. But everything else is still prone to human error, and therefore to security issues.
After 5 years of developement with the traditionnal seperated backend and React on the front-end, i'm tired of the complexity you have to work with for just an illusion of "separation of concerns".
actually, I think Prime would have his mind blown if he tried out modern C#. Especially EF Core - to my knowledge, the only ORM that ACTUALLY let's you use the db as if it was just a list of objects.
@@Qrzychu92orms are for idiots and C# is a great language but Microsoft is shit, they kill their framework’s every three year to introduce something new and terrible.
Personally I don't like C# for its weird code style guidelines: - Preferring newline '{' instead of endline '{' - Pascal case for different things than class names - Prefixing every interface with 'I" And most importantly - strong connection with Microsoft.
Underlined whiteline (after "platform"). Literally unreadable. :P Also, I'm stunned how this thing is called "crazy" and "insane" but in fact is the same thing like JSP/JSF from 17 years ago! They also seemed cool at first glance, but turned out to be really, REALLY bad idea, mixing model with view and controller. That's maybe great to some small projects (in terms of code base and dev count), but would be real pain in larger ones. That's actually crazy how IT sector is crazy over the same things and mistakes over and over again! :D
Yes, but inflencers aren't about fixing real world problem, it's about new framework hype. Htmx has an X in it so its got to be a futuristic paradigm shift.
Forced might be the wrong word. But when you use different languages, you do usually end up writing things twice, like types and validation. If js is on the backend too, chances are you could just reuse the same validations and types. And yes, there are tools to automate type generation across languages/openapi type generation, but it is almost never a perfect reflection.
This is not a problem if you use pure CSR or pure SSR. Once you do both (hydration) you have duplicate logic across client and server. It is a lot simpler to write code once (usually in JS/TS) and framework will use it properly in both runtimes.
@@ivanjermakov how is hydration duplicating logic? I admit I've never used it myself but from what I've seen it's usually a matter of config on the FE framework side
@@Wielorybkek basically SSR workflow: 1. Browser requests the page 2. Server returns a page 3. Browser shows the page to the user (first contentful paint) and requests js bundle 4. Server returns JS 5. Browser loads and parses JS, update DOM client-side (hydration) and provides interactivity (time to interactive) You see how two different places need to know how to render the page (server when sends initial response and client during hydration). This approach takes best from both worlds (fast FCP and interactivity of SPA), while sacrificing application complexity. Theo t3-gg has a good video on this topic called "Do you REALLY need SSR?".
Saying htmx is for lazy backend devs who refuse to learn modern JS development has same energy as saying Next.js is for lazy frontend devs that don't want to leave their JavaScript bubble
Htmx is for JS devs that love having a new framework everyday. The only feature of htmx is to give youtubers content for newbies. It looks like the JQuery I was doing 20 years ago and damn it is ugly.
if you just build a simple website that request api and display the result, yeah it will do the job. but if you build a complex frontend like video editor, photo editor, game, i think pick a full frontend framework would be the better choise, and then it help you to manage that complex code by writing in component based concept
Never should have gone away. It's faster to develop, easier on the browser, and simpler to debug. SPA is necessary for some types of UX, but imposes additional complexity. This is obvious, but the entire industry jumped on a cargo cult for a while.
The old way never got out of style. Reactjs^^Nodejs running as a server are for the dumb dumbs; it was a facebook and google experiment to hire low skilled programmers to try to do advance stuff. The last 10 years proved that JS on the backend is scientifically stupid. Its the exact opposite of a computer Scientists that uses logic. Most good programmers immediately knew this back in 2012. All the pros have been using [go] for product + server side rendering since Go came out.
@@LoneIgadzra Then just use Razor, JSP, PHP, Go, etc... The paradigm never gone away, simply, influencers needs to make money. So there got to be a new thing every week, even if that is reinventing the wheel everytime. Being excited for htmx is like being excited by the innovation of the pink sauce lady. All marketing, no substance. Saying stuff like PHP bad, but htmx is revolution makes me even question the sanity of people saying that. And I don't even like PHP...
HTMX it's been a breath of fresh air. For it to take off and become a trend, it just needs to be adopted by a large company. That would create a cycle of interest around the lib, open up job vacancies and spark more interest from the community.
Was just thinking: What if they wanted to style their “go” components (those functions) like you can already in Svelte, in a modular and colocated fashion? If they wanted to move away from tailwind for whatever reason (which has all the styles already globally set and just referenced as classes, which works well here). Maybe someday there could be a Go framework (maybe integrated into Templ) that can compile and ship CSS classes in a Svelte-like way too. That’d be nifty. Disclaimer: Am not Gopher.
A bit old, but templ actually does that already. You can create css blocks on the .templ files and it will be compiled and scoped to that specific file (there is probably some way of making them global too, but not sure)
@@zenlanfleek6580 Idk I just started using it and it's great. As far as I have experienced frontend is a mess full of one upums frameworks... Just too much
Reminds me of Smarty templating in PHP, but over time it was so overkill for my needs I just rolled my own no-dependencies simpler version that doesn't have fancier stuff like pre-parsed template file caching. I wonder how hard Templ goes.
this reminds me of server-side scripting, seems like tech took a detour. perhaps out of boredom or to solve a problem only to create many more. going back to the late 90's and early 2000s, i created many beautiful web applications without the need for React, Angular and etc... just good old JavaScript and ajax and sprinkles of direct server-side script, I still scratch my head as to how we arrived where we are now.
It sounds like they were just using go as most of the logic anyway and they just needed some output so its web compatible. Seemed like they created more of Go API with a front end GUI. Sveltekit is still great as a whole.
12:22 I could have sworn the html/template already did this. VScode chad, so wouldn't surprise me if it just twerks. Also everything passed into Go's native templates is just parsed into a string anyway.
Finally this JS nonesence is fading away. I hope htmx becomes more widely accepted, so that Teams can finally remove this FEBE barrier. It's a complete game changer. We'll get more of better software.
19:24 That has always triggered me so hard. It's like "Why couldn't we have just all settled on a .config directory or something??". I've tried adding config to package.json where possible, but eventually I just gave up and put a massive files.exclude block in VS Code's settings.json file...
But still it feel like a bunch of complexity. You are using Go, you are using Tmpl, you are using some kind of Echo. I feel like this stuff is new, and people are simply hyped. People didn't have much time to hit a roadblock yet.
Interesting... This feels like the good old vendor locking situation. If your company is quite big, and every department has different needs, then a headless implementation would be a better choice. Am I missing something? Is this the Backend way to do Frontend? What about security? Web components... good but we are not there yet. Something is missing. Otherwise there will be only WC and not a need to use react, vue, svelte, ... (Also, HTML has a default tag for modal called dialog)
idk man, I really don't see a draw... Sveltekit has already got me developing the front and backend at the same time and it's all just normal js/ts and html stuff which is fast and easy. If I needed more performance out on the backend, there are plenty of tricks you can do before throwing away your whole tech stack. I get in his case he already had lots of code in GO, then sure, otherwise if you are starting from scratch, Sveltekit makes way way more sense.
More maintenance. You will need to upgrade to svelte 5 for example because in a couple versions the old syntax will be deprecated. And who knows what else in the future. Htmx is a simple js file that will live forever
Htmx is cool to use, very simple. It seem very similar to JSP in J2ee with async process to get the rendered view. It's very nice to not use javascript and JSON to refresh the data of the view to get the same result
@@RememberingGames I realize , i have nothing against javascript. It's just a fact you don't need to write javascript... where is the problem in my sentence...
@@Macintoshdfr Nothing with the statement per se. I'm just tired of "new" tech that does what I was doing in 2003 and everybody thought it sucked. All of this is all cool for a small newbie tutorial but I can garantee you, as soon as you'll hit a point where you need special logic, the result will be a mess. I've gone through this countless times. Makes me sad to see how little is remembered from the errors of the past and we are bound to repeat them endlessly. So yeah, your statement is 100% factually right. The problems are what happens beyond this statement though.
@@Macintoshdfrthen build a video editor website or photo editor website or game website, you will realize that htmx is only for building frontend when you just want to do simple api request and display the result :))
Prime when are you gonna switch to qwerty layout? I recall a tweet sometime ago saying you were gonna migrate over. Waiting to see your sweet vim shortcuts in qwerty format.
The mention of mobile apps is so hilarious because all we try to do on the web is have the same experience that native apps do, and we do a goddamn good job at it with very little code and tooling that isn't as bad as Xcode and Android Studio. "It was better before" is like saying that all we do on the web is just displaying API results, but it is not. You love handling sessions on the backend? I don't. Complex UI require complex states. We aren't all writing clones of Wordpress. Just trying to avoid using any sort of global state machine to handle cross feature states, mixing in navigation and shortcuts and so on, is enough to make me cry in pain.
Sounds like nightmare fuel serving the front-end from the backend again like this. We will sit this hype out for a while and see how it goes for others.😅 Can't also imagine all our front-enders switching to this, that will be a steep curve.
@@christiansakailearning a complete new language, learning hexagon architecture, learning micro service architecture, learning the whole backend side, yeah that's a steep curve compared to learning Angular and TypeScript...
@@christiansakai i have 3 years of professional Angular experience, you where saying? I am not implying backend is more difficult btw, maybe read what I state and don't be so insecure...
@@christiansakai that's my point, most front end devs now don't know how this worked, they have to learn this and a new language and where it has to fit in with the existing backend code. A steep curve that is. Not to say it's more difficult or something, when all back end engineers have to learn all frontend things the same applies.
4:20 Yeah. Imagine the feeling, you writing your backend with Python, Go or Rust. But you have to use NodeJs for frontend... It sucks. That's why I searching vids about HTMX, to learn about alternatives to Node and NPM stuff.
"Modern js development" sounds a bit like "modern horse riding" This is basically the stack I'm set on. I'm using gorm for now but I'm thinking of ditching it because it just takes too long to debug SQL with it. Thinking of using clover db for prototyping.
Am building with svelte and I understand his point of view, server side rendering requires you to use javascript on the backend which doesn't give you the benefit of go performance
for building a simple website that request api and display the result, yeah it will do the job. but if you build a complex frontend like video editor, photo editor, game, i think pick a frontend framework would be the better choise, and then it help you to manage that complex code by writing in component based concept and if our backend is consumed by mobile too, we need to determine that if the request come from website tyen return html, if the request come from mobile then return json, if the request come from dekstop app? 🤔🤔
Prime is so meaty now he used to he a big scrub but hes like an extra large filet mignon... not much fat but a lot of tender soft meaty value. It's a pleasure to see.
Is HTMX production ready? And are there any major drawbacks of using it? I currently have a Spring Boot backend and a NextJS frontend, where I basically only do the rendering. I was also thinking about switching to MVC with HTMX, as from what I see it would be faster to work with than writing all the API types 2 times.
different way to skin a cat. it's preference based. i would dive into it first before you start picking it, you may find things you don't like. in your scenario, you would have to reimplement a lot of your backend to have HTMX controllers rendering components. that's a lot of work. i would weigh the options before you commit to anything.
if you just build a simple website that request api and display the result, yeah it will do the job. but if you build a complex frontend like video editor, photo editor, game, i think pick a full frontend framework would be the better choise, and then it help you to manage that complex code by writing in component based concept
4:30, I don't think that's the case. I am using Sveltekit with Django as the backend. The kit part of sveltekit serves as a mediator for integrating whatever api I want. I am not fond of JS backends for handling hard logic. Also htmx sucks :D would never use that due to how its made.
so we're back to the idea of generating html in backend (kinda jsp?), which ~15 years was considered a very bad idea and all the spa framework madness have started?
I learned vanilla front end and some php for backend in my uni courses. Are these templates like making a .php file and just include-ing it in other places? And any advice you can give? So far I built a basic project for the course but it ended up as a spaghetti mess of .php files and juggling data with session and figuring what carries over after a page refresh and what not. In the end I felt likr backend and frontend became one elden ring abomination. I concluded that Id rather bash my head to solve logical backend problems then trying to untangle frontend frameworks. Tho im not fat, nor have a fedora or uwu keycaps
6:50 couldn't been said better. I dunno how many ERP webapp have been written that way, just traducing json into html and doing nothing but calling backend api for everything. Let alone js, you could have written that application without AJAX using html and SSR the old way and get something very similar without the js fatigue.
@ThePrimeTime For rust, you should really try and give Poem and Maud a try. Maud is very good, it’s html entirely as macros, and poem is, well, frankly, beautiful. I highly recommend it.
Can't imagine my two favorite tech youtubers on one video together, this is legendary
Several of mine are often
Epic
I did the same for the previous few months. I used to have a Go backend server and a svelte frontend, I use the static svelte generator to generate static files and directly serve them as static files using caddy. Now, I only have a Go backend which spits out HTMX. It takes way less effort than I imagine. However, the performance of my tiny internal tool that only be used by a dozen of people is the same. The maintenance time does go down though.
It’s nice seeing The Rock get into HTMX
Hahaha now thats funny
Thought was Bezos
This is the colab we need. Anthony and prime talking Go let's do it
Anthony could not keep up with Prime 😂😂😂 prime just spits it out which is great
Sorry, but "reacting" is not collabing. Anthony has no chance to respond to Prime.
@@aspzx I might not have been clear. I would like for them to eventually collaborate, and this comment was just me cheering on that idea.
@@dejangegic ah got you. Yeah I agree
Love that chat about type security. Anything without static code analysis warning/errors is so much harder to refactor in the future because it takes so long to hopefully find all the dependencies. And you can never be sure you have found them all
Next up: from Go + HTMX back to PHP.
Would rather eat raw aluminium every day than program in php
Whats the joke?
The language isn't great but the model is. Inherently stateless so easily parallelized, native ssr, and faster than JS. If the language itself was safer and less trash php as a platform would still dominate.
@@robertzxzxI concurr
But why, if with Templ Go make the same thing PHP did?
4:58 yes i am a lazy backend developer, I want the answers to my problems to be easy and simple
"idiots admires complexity"
"How many config files do you have in your frontend app?"
"Yes"
I built an entire app with golang and HTMX, without even realizing TEMPL existed! I used the built in text/template for Go and I didn't actually hate it.
isn't text/template is slow? 🤔🤔 i used jet template engine and used htmx inside it
@@superquantumcomputer it was pretty quick for me and I was working with a decently large data set. however I did have an infinite-scroll feature for the client so it only templated like 25 entries at a time.
why not html/template?
@@SoMadCoffee html/template uses text/template under the hood
It's worth noting that the text/template isn't injection safe, while the html/template is
I don't want to be THAT guy.... but the hated C# had this for decades :D type-safe, async data fetching from within the template, streaming rendering etc, hot reload in templates (now also in code). Just saying :) btw, now it's even better with with Blazor server rendering
Blazor feels so nice to work with. It’s so much better than razor pages imo
So it's Laravel + Livewire? The modular monolith lives to fight another day son! I like to think that a PHP dev whose comfortable with Laravel could step up their skillset to Go in this type of capacity relatively easily and gain some new skills in typed languages but without a completely jarring learning experience. Go is the PHP developers secret best friend, they just don't know it yet 😅
does livewire return html? to me this feels like an old fashioned way of developing applications, what if you want some of the logic to be used for another project in an api?
i used laravel with ajax before, and in there the client browser made the dom elements with the data
@@phoneywheeze if you properly architect your server, then how you expose your data should not be hard at all. Your usecases should not be aware of how data is exposed.
@@phoneywheeze
You separate the logic into packages that can be reused.
The PHP equivalent would be extracting reusable logic into classes.
Prime has been so good for the developer community at large. I hate to think of a world without him.
Don't use hate around Christmas time.
Plot Twist. He is not real. Just AIgen Mr. Moustache running wild.
People still think the AI plot twist thing is funny?@@v2ike6udik
Svelte kit is now the recommended choice even if it’s going to be full SPA .. basically for the built in routing
It's good but the +page.svelte kinda sucks, would love if it was the same directory name for the +[dir].svelte
who is recommending?
@@electrolyteorb "Just trust me bro" is recommending it
@@electrolyteorb Oh, The Svelte team.
@@ryanleemartin7758 😂
Can't help but realize how we're coming back full circle to the modular monolith and I quite welcome it. I'm leaning towards the Elixir/LiveView side of the fence, but I wonder: what is the breaking point? Is it the over-complication of the JS/TS ecosystem? Is it because the cognitive load for writing and maintaining SPAs is going off the roof? Is it because SPA frameworks and libraries are getting so bloated that it defeats the purpose? Is it because each of those frameworks and libraries lock you in (I'm looking at you, React "library")? Or is it simply because the SPA model was never the right one?
My take on it is that the only thing we've ever needed was the ability to hook up a certain HTML element with an isolated state and logic, and the JS+HTML model never provided that out of the box, whereas with traditional AJAX+SSR it's quite easy to implement. The latter traditionally suffered from scoping issues with global JS for interaction, and most importantly global CSS for styling, and it looks like HTMX and the PHP model of rendering within the language bounds fix the former issue, and Tailwind just obliterates the latter.
I think it's like you said with the SPA model; there are cases where the hypermedia/enhanced html way of doing things isn't good for complex interdependent ui state as per the HTMX docs, and so you need the overhead of a js framework, but at the same time the modern js overhead isn't worth it for most cases, so people would take a big perf/complexity hit for the rarer case and because of the developer/career inertia; nowadays I hear people talking about having the complex JS in little "islands", so the future meta might be backend-templating/enhanced-html(whether htmx/liveview or even a future HTML spec) and light js scripting with occasional islands of heavy js
For me it's the frameworks that suck. I work on a fairly large app with mithril.js and I'm still very happy with it. But I think for most trivial cms-like apps go and htmx are a pretty good alternative. For my app (an online worksheet editor) it's not sufficient enought I think.
16:20 his issue was he mixes sveltekit (a full stack framework) with "go", either choose sveltekit or "go" with something else.
sveltekit has use:enhance, he didn't need to proxy anything, all he had to do was using (s) with `use:enhance` and combine it with the `form` html attribute, and do everything with form actions, without any proxy, he doesnt have to manage any state, doesnt have to build a proxy, its just boosting.
something like this
+page.server.ts
const count = kv.value(0);
export const load = (async (event) => {
return {
count: await count.get()
};
}) satisfies PageServerLoad;
type zSetCount = z.infer;
const zSetCount = object({
value: string().regex(/^\d+$/).transform(Number).pipe(number().min(0))
});
export const actions = {
async setCount(event) {
const form = await parseFormData(await event.request.formData(), zSetCount);
const response = { setCount: form };
if (!form.valid) fail(response);
await count.set(form.data.value);
return response;
}
} satisfies Actions;
+page.svelte
export let data: PageData;
export let form: ActionData;
$: count = form?.setCount.data.count ?? data.count ?? 0;
const setCountFormId = uniqueId();
+
{count}
-
OR if you like more reuseable actions
export let data: PageData;
export let form: ActionData;
$: count = form?.setCount.data.count ?? data.count ?? 0;
const countUp = uniqueId();
const countDown = uniqueId();
+
{count}
-
and all works even when you disable js on the browser.
oh you like modals?
+layout.server.ts
import type { LayoutServerLoad } from './$types';
export const load = (async (event) => {
const selectedPostId = event.url.searchParams.get('post');
const selectedPost = selectedPostId
? await someDb.getPost(selectedPostId)
: null;
return {
selectedPost
};
}) satisfies LayoutServerLoad;
+layout.svelte
export let data: PageData;
{#if data.selectedPost}
{/if}
still also works without js.
The title is a bit misleading, they didn't move from sveltekit to hmtx+go, but rather from sveltekit+go which makes total sense considering they wanted to focus on one language
I also think he meant Svelte to HTMX because SvelteKit is kinda like Next.js of Svelte.
@@ElclarkKuhu right there is the problem...., why are you selecting a tool that you don't even understand. I kept shaking my head when he said that " we decided to use SvelteKit for our front-end and go (Echo ) for our backend" SvelteKit is the whole deal ( front and backend) if you only what the frontend use svelte!
@@hardcorecodegood point here. If you dont know why you need it for, then the issue is the lack of knowledge, not the tool.
I guess they used SvelteKit for the routing and its patterns for organizing the frontend files.
4:47 I 100% agree with what he's saying trying to build a solid piece of software with react and some backend languages could be a nightmare in terms of security, integration and stuff.
I have yet to see the video. But I dont see many people in htmx explaining how this makes it secure, handles auth +auth.
@@erickmoya1401It doesn't because htmx people only do miniature apps for views on youtube. Nobody with a rationnal mind would use that to build a real life, big application.
@@erickmoya1401 It doesn't, it's the same factor of security as anything else that outputs HTML-usually whatever templating language you use, whether it being JSX or something else will handle things like sanitisation to prevent XSS. But everything else is still prone to human error, and therefore to security issues.
After 5 years of developement with the traditionnal seperated backend and React on the front-end, i'm tired of the complexity you have to work with for just an illusion of "separation of concerns".
Prime hates C#. Prime loves every single C# feature other languages adopt
Go figure
This!
Fair enough. This is just Blazor pages without C# at this point
actually, I think Prime would have his mind blown if he tried out modern C#. Especially EF Core - to my knowledge, the only ORM that ACTUALLY let's you use the db as if it was just a list of objects.
@@Qrzychu92orms are for idiots and C# is a great language but Microsoft is shit, they kill their framework’s every three year to introduce something new and terrible.
Personally I don't like C# for its weird code style guidelines:
- Preferring newline '{' instead of endline '{'
- Pascal case for different things than class names
- Prefixing every interface with 'I"
And most importantly - strong connection with Microsoft.
It finally happened. Anthony on Prime’s channel🎉
Underlined whiteline (after "platform"). Literally unreadable. :P
Also, I'm stunned how this thing is called "crazy" and "insane" but in fact is the same thing like JSP/JSF from 17 years ago! They also seemed cool at first glance, but turned out to be really, REALLY bad idea, mixing model with view and controller. That's maybe great to some small projects (in terms of code base and dev count), but would be real pain in larger ones.
That's actually crazy how IT sector is crazy over the same things and mistakes over and over again! :D
Go templates with type safety kind of just sounds like razor
its the same thing as razor engine
Yes, but inflencers aren't about fixing real world problem, it's about new framework hype. Htmx has an X in it so its got to be a futuristic paradigm shift.
GSP's retirement is going well
I don't understand how a FE framework would force you to use JS on the BE? between them is either REST or GraphQL, does not matter what you use
Forced might be the wrong word. But when you use different languages, you do usually end up writing things twice, like types and validation. If js is on the backend too, chances are you could just reuse the same validations and types.
And yes, there are tools to automate type generation across languages/openapi type generation, but it is almost never a perfect reflection.
This is not a problem if you use pure CSR or pure SSR. Once you do both (hydration) you have duplicate logic across client and server. It is a lot simpler to write code once (usually in JS/TS) and framework will use it properly in both runtimes.
@@ivanjermakov how is hydration duplicating logic? I admit I've never used it myself but from what I've seen it's usually a matter of config on the FE framework side
@@Wielorybkek basically SSR workflow:
1. Browser requests the page
2. Server returns a page
3. Browser shows the page to the user (first contentful paint) and requests js bundle
4. Server returns JS
5. Browser loads and parses JS, update DOM client-side (hydration) and provides interactivity (time to interactive)
You see how two different places need to know how to render the page (server when sends initial response and client during hydration). This approach takes best from both worlds (fast FCP and interactivity of SPA), while sacrificing application complexity.
Theo t3-gg has a good video on this topic called "Do you REALLY need SSR?".
@@gabrielus123 you could doesn't mean you should. Reusing models will get you in to a world of pain with changing business requirements.
mmm doing the same but with Ruby and Sinatra. It feels like a warm blanket in a land where the word "Javascript" has never been mentioned
Saying htmx is for lazy backend devs who refuse to learn modern JS development has same energy as saying Next.js is for lazy frontend devs that don't want to leave their JavaScript bubble
Htmx is for JS devs that love having a new framework everyday. The only feature of htmx is to give youtubers content for newbies. It looks like the JQuery I was doing 20 years ago and damn it is ugly.
if you just build a simple website that request api and display the result, yeah it will do the job. but if you build a complex frontend like video editor, photo editor, game, i think pick a full frontend framework would be the better choise, and then it help you to manage that complex code by writing in component based concept
Ready to hear about why the old way is the new hotness.
Never should have gone away. It's faster to develop, easier on the browser, and simpler to debug. SPA is necessary for some types of UX, but imposes additional complexity. This is obvious, but the entire industry jumped on a cargo cult for a while.
The old way never got out of style.
Reactjs^^Nodejs running as a server are for the dumb dumbs; it was a facebook and google experiment to hire low skilled programmers to try to do advance stuff. The last 10 years proved that JS on the backend is scientifically stupid. Its the exact opposite of a computer Scientists that uses logic. Most good programmers immediately knew this back in 2012. All the pros have been using [go] for product + server side rendering since Go came out.
@@LoneIgadzra Then just use Razor, JSP, PHP, Go, etc... The paradigm never gone away, simply, influencers needs to make money. So there got to be a new thing every week, even if that is reinventing the wheel everytime.
Being excited for htmx is like being excited by the innovation of the pink sauce lady. All marketing, no substance.
Saying stuff like PHP bad, but htmx is revolution makes me even question the sanity of people saying that. And I don't even like PHP...
HTMX it's been a breath of fresh air.
For it to take off and become a trend, it just needs to be adopted by a large company. That would create a cycle of interest around the lib, open up job vacancies and spark more interest from the community.
Was just thinking: What if they wanted to style their “go” components (those functions) like you can already in Svelte, in a modular and colocated fashion? If they wanted to move away from tailwind for whatever reason (which has all the styles already globally set and just referenced as classes, which works well here). Maybe someday there could be a Go framework (maybe integrated into Templ) that can compile and ship CSS classes in a Svelte-like way too. That’d be nifty.
Disclaimer: Am not Gopher.
Anthony is alreayd building that rn
A bit old, but templ actually does that already.
You can create css blocks on the .templ files and it will be compiled and scoped to that specific file (there is probably some way of making them global too, but not sure)
Never used Go before , but it's time to start a new adventure I guess... was an amazing stream man! WD!
Go is fantastic I prefer the backend. I wait to do frontend, it can be simple people add too much to the front end.
@@jwoods9659we get it bro
@@jwoods9659 Average Go consumer.
@@zenlanfleek6580 Idk I just started using it and it's great. As far as I have experienced frontend is a mess full of one upums frameworks... Just too much
It’s the way to Go.
HTMX is making frontend DRY again! YAY!
So weird that webdev seems to go back to simply PHP
I was thinking the same thing
idea of php itself is not bad, php itself is awful, Go will continue legacy.
Wow I literally just watched Anthony GG's video with this video queued, having no idea that you were reviewing his video
Rust + wasm , lets go
Today's a good day to use HTMX
the only problem is react, angular, svelte has a lot of component libraries which wont be available of we use go+templ+htmx
php lazavel did this with Blade template engine like a decade ago
But that was php 🤢
Reminds me of Smarty templating in PHP, but over time it was so overkill for my needs I just rolled my own no-dependencies simpler version that doesn't have fancier stuff like pre-parsed template file caching. I wonder how hard Templ goes.
Currently I use htmx & rust and I like it a lot. I just use leptos as templ substitute and a axum backend. No SSR or CSR.
this reminds me of server-side scripting, seems like tech took a detour. perhaps out of boredom or to solve a problem only to create many more. going back to the late 90's and early 2000s, i created many beautiful web applications without the need for React, Angular and etc... just good old JavaScript and ajax and sprinkles of direct server-side script, I still scratch my head as to how we arrived where we are now.
Facebook trying to correct itself
templ: using your main language in your templates. Ok, so 25 years later you're still reinventing php?
Kinda, but keep bashing PHP because of MEME
Honestly, yeah, that’s what I thought when they both said that!
“Looks like PHP with extra steps”
And I haven’t been serious about PHP since PHP 5!
the complexities comes with modals, which should be, is insane.
I don’t get the modals issue, should we not use them?
Just use the to make the modaels.
Go + Templ is great but what about type safety in HTMX?
project link?
But does Go run in the browser? Can I deploy a project as GitHub pages? Thought so.
Again thanks prime to let me escape Typescript Hell. Now I can happily live my life in Go and use and contribute my favorite Go FOSS project. Templ !
Feels like it would be possible to write a linter that typechecks template/html templates
How many of you using htmx are mostly working BE?
It sounds like they were just using go as most of the logic anyway and they just needed some output so its web compatible. Seemed like they created more of Go API with a front end GUI. Sveltekit is still great as a whole.
Please no please no please no something went wrong on this timeline
12:22 I could have sworn the html/template already did this. VScode chad, so wouldn't surprise me if it just twerks. Also everything passed into Go's native templates is just parsed into a string anyway.
Sounds like it would have been a better usecase for just Svelte, without the kit.
Finally this JS nonesence is fading away. I hope htmx becomes more widely accepted, so that Teams can finally remove this FEBE barrier. It's a complete game changer. We'll get more of better software.
19:24 That has always triggered me so hard. It's like "Why couldn't we have just all settled on a .config directory or something??". I've tried adding config to package.json where possible, but eventually I just gave up and put a massive files.exclude block in VS Code's settings.json file...
But still it feel like a bunch of complexity. You are using Go, you are using Tmpl, you are using some kind of Echo. I feel like this stuff is new, and people are simply hyped. People didn't have much time to hit a roadblock yet.
Interesting... This feels like the good old vendor locking situation. If your company is quite big, and every department has different needs, then a headless implementation would be a better choice. Am I missing something? Is this the Backend way to do Frontend? What about security?
Web components... good but we are not there yet. Something is missing. Otherwise there will be only WC and not a need to use react, vue, svelte, ...
(Also, HTML has a default tag for modal called dialog)
idk man, I really don't see a draw... Sveltekit has already got me developing the front and backend at the same time and it's all just normal js/ts and html stuff which is fast and easy. If I needed more performance out on the backend, there are plenty of tricks you can do before throwing away your whole tech stack. I get in his case he already had lots of code in GO, then sure, otherwise if you are starting from scratch, Sveltekit makes way way more sense.
More maintenance. You will need to upgrade to svelte 5 for example because in a couple versions the old syntax will be deprecated. And who knows what else in the future.
Htmx is a simple js file that will live forever
21:15 what are you using to take so long?
That's looks like jsp in java.
Am I wrong.
I don't realy like jsp.
The htmx stuff is shoot to the past isn't it or did I misunderstood something?
Htmx is cool to use, very simple. It seem very similar to JSP in J2ee with async process to get the rendered view. It's very nice to not use javascript and JSON to refresh the data of the view to get the same result
You do realize htmx is a javascript lib right?
@@RememberingGames that's an incredibly reductive point but ok
@@RememberingGames I realize , i have nothing against javascript. It's just a fact you don't need to write javascript... where is the problem in my sentence...
@@Macintoshdfr Nothing with the statement per se. I'm just tired of "new" tech that does what I was doing in 2003 and everybody thought it sucked. All of this is all cool for a small newbie tutorial but I can garantee you, as soon as you'll hit a point where you need special logic, the result will be a mess. I've gone through this countless times. Makes me sad to see how little is remembered from the errors of the past and we are bound to repeat them endlessly.
So yeah, your statement is 100% factually right. The problems are what happens beyond this statement though.
@@Macintoshdfrthen build a video editor website or photo editor website or game website, you will realize that htmx is only for building frontend when you just want to do simple api request and display the result :))
When the Top G validates your work 😎
Prime when are you gonna switch to qwerty layout? I recall a tweet sometime ago saying you were gonna migrate over. Waiting to see your sweet vim shortcuts in qwerty format.
no types is the only reason I am still not down with htmx for larger projects
I haven't seen any good reason to switch from svelte
The mention of mobile apps is so hilarious because all we try to do on the web is have the same experience that native apps do, and we do a goddamn good job at it with very little code and tooling that isn't as bad as Xcode and Android Studio. "It was better before" is like saying that all we do on the web is just displaying API results, but it is not. You love handling sessions on the backend? I don't. Complex UI require complex states. We aren't all writing clones of Wordpress.
Just trying to avoid using any sort of global state machine to handle cross feature states, mixing in navigation and shortcuts and so on, is enough to make me cry in pain.
I like to use go+quicktemplate. It is a bit arcane but it is compiled so it is type safe
So its becoming kind of php?
how does hot reloading work? ui without hot reloading is insane.
Sounds like nightmare fuel serving the front-end from the backend again like this. We will sit this hype out for a while and see how it goes for others.😅
Can't also imagine all our front-enders switching to this, that will be a steep curve.
Another ohh this is the best thing this will revolutionize this crap looks wack 🤣
@@christiansakailearning a complete new language, learning hexagon architecture, learning micro service architecture, learning the whole backend side, yeah that's a steep curve compared to learning Angular and TypeScript...
@@christiansakai i have 3 years of professional Angular experience, you where saying? I am not implying backend is more difficult btw, maybe read what I state and don't be so insecure...
@@christiansakai that's my point, most front end devs now don't know how this worked, they have to learn this and a new language and where it has to fit in with the existing backend code. A steep curve that is. Not to say it's more difficult or something, when all back end engineers have to learn all frontend things the same applies.
@@christiansakai you again fail to address any of my points sir, which is quite remarkable in such a lengthy post.🤣
Hey! Love your videos that contains Go 😅. Keep it up! Hopefully we see more of it
4:20
Yeah. Imagine the feeling, you writing your backend with Python, Go or Rust.
But you have to use NodeJs for frontend... It sucks.
That's why I searching vids about HTMX, to learn about alternatives to Node and NPM stuff.
"Modern js development" sounds a bit like "modern horse riding"
This is basically the stack I'm set on. I'm using gorm for now but I'm thinking of ditching it because it just takes too long to debug SQL with it. Thinking of using clover db for prototyping.
Django 5.0 + htmx
Django 5 + Htmx + Hyperscript... Never looked back
Everyday I'm more excited with go lang
Am building with svelte and I understand his point of view, server side rendering requires you to use javascript on the backend which doesn't give you the benefit of go performance
for building a simple website that request api and display the result, yeah it will do the job. but if you build a complex frontend like video editor, photo editor, game, i think pick a frontend framework would be the better choise, and then it help you to manage that complex code by writing in component based concept
and if our backend is consumed by mobile too, we need to determine that if the request come from website tyen return html, if the request come from mobile then return json, if the request come from dekstop app? 🤔🤔
It finally happened
looks like that c# for front ned
19:18 just config hell anxiety things ♾.
Prime is so meaty now he used to he a big scrub but hes like an extra large filet mignon... not much fat but a lot of tender soft meaty value. It's a pleasure to see.
Some people have forgotten that client-side rendering + json was invented to unify backend for web and mobile applications?
Immediately there is a notification over 1000 people said "Yes i want to listen to this guy talk."
Is HTMX production ready? And are there any major drawbacks of using it?
I currently have a Spring Boot backend and a NextJS frontend, where I basically only do the rendering.
I was also thinking about switching to MVC with HTMX, as from what I see it would be faster to work with than writing all the API types 2 times.
different way to skin a cat. it's preference based. i would dive into it first before you start picking it, you may find things you don't like.
in your scenario, you would have to reimplement a lot of your backend to have HTMX controllers rendering components. that's a lot of work. i would weigh the options before you commit to anything.
MVC?
@@erickmoya1401 I ment instead of having NextJS consuming an API, having my Backend returning the view basically.
@@kristun216 Yeah, sounds smart. Thanks :)
if you just build a simple website that request api and display the result, yeah it will do the job. but if you build a complex frontend like video editor, photo editor, game, i think pick a full frontend framework would be the better choise, and then it help you to manage that complex code by writing in component based concept
13:55 is that what react users be like once they discover proper frameworks?
Wait cant you do that in svelte? 🤔
4:30, I don't think that's the case. I am using Sveltekit with Django as the backend. The kit part of sveltekit serves as a mediator for integrating whatever api I want. I am not fond of JS backends for handling hard logic. Also htmx sucks :D would never use that due to how its made.
6:35 is exactly why I hate this usage of JSON
Still not convinced to how this would work with complex front ends. I think I am going to prove myself wrong.
I'm trying to figure out where his accent comes from. His vowels are Scottish, his 't's are Spanish, and his 'j's are German
sounds Dutch to me. edit: it's Belgian.
4:20 not a surprise that it makes sense also to use Laravel
so we're back to the idea of generating html in backend (kinda jsp?), which ~15 years was considered a very bad idea and all the spa framework madness have started?
MVC stands for Modals, Very Cool!
I knew The most Backend Language Programmers that will adopt HTMLx is Golang devs
So Templ is basically a reinvented PHP?
I love HTMX BTW.
I learned vanilla front end and some php for backend in my uni courses.
Are these templates like making a .php file and just include-ing it in other places?
And any advice you can give? So far I built a basic project for the course but it ended up as a spaghetti mess of .php files and juggling data with session and figuring what carries over after a page refresh and what not. In the end I felt likr backend and frontend became one elden ring abomination.
I concluded that Id rather bash my head to solve logical backend problems then trying to untangle frontend frameworks.
Tho im not fat, nor have a fedora or uwu keycaps
is this an ASMR video? Why do I need to max out sound level to barely hear what either of you are saying?
My main issue with Go + HTMX is I haven’t found a clean and easy way to set up auth. It’s super easy with SvelteKit or Next.js (T3). Skill issue tho
Yup, I have found the same problem multiple times but I really have not tried hard enough
6:50 couldn't been said better. I dunno how many ERP webapp have been written that way, just traducing json into html and doing nothing but calling backend api for everything. Let alone js, you could have written that application without AJAX using html and SSR the old way and get something very similar without the js fatigue.
They've got squigglies. Say no more
+1 for Leptos
@ThePrimeTime
For rust, you should really try and give Poem and Maud a try.
Maud is very good, it’s html entirely as macros, and poem is, well, frankly, beautiful.
I highly recommend it.