Yeah, this is an underrated take. Sometimes just let things break and then you fix it. I for instance only code about 1/4 of my time, the rest is spending managing my business. So yeah, devs are ALL over the place.
He seems to be complaining more about using Go and Templ than htmx itself... You don't have to use Go to use htmx... The htmx creator clearly states that htmx isn't meant to replace JavaScript but complement it and reduce the amount of menial code for things that can be handled by the extended HTML tags.
This further solidifies my opinion that Go is the wrong choice for web backend. Not only do you have to deal with nil pointer and race condition, you would also have to deal with its UX. Go is less than C# in safety, job availability, and hireability. Go is inferior to Rust in term of performance, safety, and ergonomic (few languages have such as convenient tool as Rust macros).
@@ivan.jeremic I'm honestly baffled that you actually said that, that you actually insinuated a single core, non distributed, event loop driven runtime with colored functions and traditional exceptions is somehow, the best backend...
@@C4CH3S I could not agree more. nodejs struggles hard with high request counts and if a user of the API does something stupid the whole process will block for a moment good look by the way then figuring out where that happens.
2 WEEKS IS NOT ENOUGH TIME TO LEARN ANYTHING AND JUDGE IT. So, you can write JavaScript with htmx as well, idea of htmx isn't about no javascript but hypermedia as state representation. I think web dev cody's experience isn't a real experience in industry cause most of his experience is making youtube videos not products being used by people and 2 weeks isn't enough time to learn Go let alone htmx. There are people at IBM who are making decent sized projects in HTMX. It would be awesome if you could get them on stream. I think your view is right in saying that this might not be real industry experience but of an indie hacker who makes videos not products.
Yeah... I think Cody made some phenomenal points about not being to build as quickly, but as for finished product ux... Most real world htmx apps I've heard of ship a small amount of javascript to deal with the few things that don't fit the model, but are still core to good UX. HATEOAS (worst acronym) is really useful for keeping things simple and I think it's a shame that it feels like it got a bad shake.
If you follow his complaints on Twitter, someone says, "If you bumped into some issues while using some library, you must find another way to do it and not double down on your problem so that it works the way you want." Cody did the latter (and is happy that Carson acknowledged that it's a bug), but there are still other ways to fix Cody's problem.
I mean, did y’all actually think id permanently switch to go and htmx when I’ve been getting paid to write JavaScript, typescript, react, node full time for 10 years now? The moment my content becomes all Go you know my actual paycheck from work is coming from Go.
Not permanently, no, but getting a bit more bake time would certainly help, especially since you're stepping out so far from your career expertise. In my career experience, two weeks just isn't enough time to switch mindsets - of course you mastered the mechanisms of development in the new stack, but your comments about things like parsing integers and error handling clearly show that you're still (understandably) writing Go while thinking in JavaScript. I write safety critical server software for a living, and I've been learning front end - in the last two years I've written websites with Next.js and Nuxt, and a mobile app in React Native. Even still I can clearly see I'm writing JavaScript but thinking like a back end dev. You do you, though.
so he setup his project structure like he does in nextjs and tries to force golang into that convention. i see this with java programmers all the time that are trying to switch to golang.
web dev cody's content is nice because he shows himself having incorrect assumptions, he doesn't cut the stuff out, he leaves it all in. I like how he explains how he messes up, works on it to understand, and then shares with his community.
Our team has moved on from the JS framework and isn’t looking back. We now use HTMX sparingly, and that’s all we need. We couldn’t be happier with this approach. Personally, I’ve rediscovered my joy in development, which is the most important thing. If you find satisfaction working with Next, React, Vue, or any other framework, go for it. The key is to enjoy what you do. HTMX has been great for us.
Honestly I've been contemplating taking my company in a different direction as well. I've been doing this for 20 years and the last decade has been hell trying to navigate all of these constantly changing frameworks. I'm kind of sick of it.
I think there is way too much of lack of deep understanding about tools and where to use them. We have the thing called "web", hypertext documents to share stuff. But it went to every machine so it became very early as standard way to make user interfaces for *applications*. Application is different thing than example some some company web page. Of course browser was very limited because everything was depended on page loading. In fact Javascript was considered as optional thing most of the 00s. It was around 2009 when it makes sense to write applications that are expected to work everywhere so we can actually make things dependent on Javascript. It started from jQuery, paradigm was server rendered UI with page loads, but jQuery make usable to make some components dynamic and work without pageloads. We soon got Angular that was for single page applications and later we got React. But those actually run UI code completely on JS and that was of course terrible idea if project is company web page or similar content page. Applications are not intended to be accessed with search engines. What happened is that substandard web developers started to overuse Javascript in content pages while in reality they should render them in server and avoid Javascript. Some cases Javascript make sense and those cases were possible to handle with jQuery component long time and past four years web components are way to go. It is just important to make difference is someone making systems that share content or are they making application.
@@LongJourneys UI code in applications has always gone out of date quickly. If not technology did not start to rot, then it went out of fashion. But when application runs in browser, there was and still is going very rapid development and newer technology reduces boilerplate code or it runs faster.
Yep as a newbie focusing 100% on React is a big mistake. Your learning React ecosystem and not coding or development. Go and templ and HTMX is fine for the most point.
I understand why he disliked Go but I don't think he was using it correctly. You cannot program in Go the same way you program in JS. The paradigm in Go is libraries cannot panic for you, and so if you want less verbose code, just create the functions you need that panic in the way you expect them to. If you handle parsing an int the same way every single time, then create a function wrapper and just use that. Go does not have to verbose. It's as verbose as you want it to be.
I feel like so much of it is just down to what you're used to and experienced with. I came from Objective-C, C# and Python before really getting into Javascript. And my first reaction to Javascript was "Ugh, why does it feel like everything is hidden behind syntactical sugar and shortcuts?" I felt like the amount of syntax I had to learn before I could understand what Javascript code was doing was significantly higher than in other languages I was used to. So for me when I first tried Go the same verbosity he sees as a detriment felt like a breath of fresh air to me. It's more characters to type sure, but I feel like I feel like that's made up by me spending less time than I do in Javascript trying to decipher the cleverness involved when trying to minimize verbosity in coding.
A couple things I noticed: - not enough time spent learning Go - bad tooling (e.g. GoLand does go to templ and not compiled file) Don't get me wrong, he does make good points, but some of them are not.
Weak points are that you have to do web 1.0 and enhance that instead of building the app like you would for the SPA. It is also clumsy to update multiple things, because you either have to render higher in the tree to reflect all changes, send weird OOB responses or emit events and make those places refresh themselves. It is probably the least messy if you just use "boosted links" and do full page renders, and optimize it later.
there are some small gotchas too like including the vary header in the response or ur cache will be all messed up (back and refresh will only render the html partials). its pretty nice tho once you figure it out tbh.
@@sarabwt your whole crap next js bubble is the result of people enhancing web 1.0 for more than a decade to the point of a running a server just for it. at any point claiming that running a virtual dom for a web app when today there exactly no need for it is like picking your car to go to work when your job is 200m away from you. you code for convenience. at this point your not even a programmer, your a IDE user. the real programmers are building your crap performant frameworks.
@@ricardodelacrvz1400 Tf you on about? I work as a BE dev/devops, I never used Next EVER, I hate React, I used HTMX for pretty much every hobby project since 2021 (way before you found out about it) and I use neovim for everything. How highly regarded do you have to be, to think, that HTMX is beyond critique??? Which makes me believe, that none of you ever built any even moderately complex app using HTMX.
12:55 I remember when IntelliJ added support for clicking to go to spring bean/component definitions from the place that they were injected. It made working with Spring and Spring Boot SOO MUCH better.
The whole "Full Stack" world is a very deep local minima that people outside of it don't want to get into, and to get people out of it will take a truly convincing paradigm shift.
are you ok theo? I've never seen such bad arguments from you before. - "I'm used to JS and I don't like GO's package system because it's weird". - "I'm frustrated because using something different requires a shift in my mental model" - "There's only one type of web app" - "I'm right, I don't care" I understand you're mad and want to fight the non-sense hype and hate, but take a breath... you know way better than this.
His business is T3 stack so he will sh*t on non js stacks just to keep his cash cow running, js has its place but htmx, rails, django phoenix have there place too in fact most of the time you can avoid JavaScript, react, next.js and this non sense but again he lives in his bubble for obvious reasons.
@@hamm8934 Exactly, I got tired of this "Next Next Next" of Theo, IDK if he is, but seems to be sponsored by Vercel to promote that shit framework. Dont watch his videos anymore, I just come here to coment "Stop using Next, use Solid"
Unrelated, but I've been a long time Rails dev and this weekend I tried NextJS. I'm honestly surprised at how easy it was. There are a lot of simple and powerful ideas in here - not something I expected from a JS framework.
Yeah I really don’t understand why people complain. I’ve been deving since 2001 back with mostly HTML, transitioned to PHP in 2006, React in 2019, and now NextJS. I just happen to use the tools for the trade, yet didn’t expect such a huge cult around each language.
I love Go and consider it vastly superior to JavaScript/TypeScript, and I completely disagree that it's more verbose than TypeScript. However, even though I'd love to create my frontend with Go, I acknowledge that nothing beats the JavaScript/TypeScript ecosystem for that purpose. The development experience for UI/UX with those tools is remarkable. In the end, it's important to recognize that each tool excels in entirely different areas.
I will argue that the speed at which GO compiles is directly proportional to its rigidity in naming. The parser can be a lot simpler, and yes, it cannot compete with the multitude of weird shit you can do in javascript, but thats exactly why javascript is slow. Just like all the conversations about json not supporting a trailing comma, and after examining, you figure out how it complicates the parsing tree and how immense the performance impact would be. Not saying I like the GO way of doing things inherently, but its EXTREMELY important to acknowledge why things are that way. My GO builds compared to NextJS are not even in the same realm.
35:25 is a bad take, to be honest. I don't mean that he has to fully commit to Go or anything like that. I actually appreciate that he tried it out and formed an opinion about its style. However, concluding with "Yeah, so I'm basically a JS/TS dev. You can make fun of me, but whatever," is such a weak conclusion. For me, being a developer means innovating, improving, and constantly learning new things-that's what I love about the web. You also have to explore what other frameworks and languages are doing to really understand the landscape. Maybe you can take something from the Go/Rust/Zig idioms and apply it to your work in JavaScript/TypeScript. I always seek out new stuff and strive to get good at it, and I've been a JS/TS developer for 10+ years now without losing that passion.
Context switching is not exclusively between languages, back when node didn't support modules i had to write commonJS on backend & ES modules with react and that had me always messing up the node files with ES modules syntax...
I'm on both sveltekit and go/templ/Htmx, and the dev experience is the reason why I keep going back to js. Especially the hmr and dev server. Not sure why my air/templ setup panics from time to time, and that requires me to kill the dev server and restart it.
His complaints are valid... but the complaints about the editor linking to wrong files... that what you get for using VSCode. If he used a proper Go IDE like GoLand he wouldn't have had these issues.
The incorrect go-to-file complaint he had is a documented bug on the github repo that they're working on. It's not an easy fix because they basically have to intercept the Go lsp and redirect it to the Templ LSP. If you're already in a Templ file, the go-to-definition works. Templ is like 2 years old and was made by one dude. Things like this will be gone in a year or two. Templ, Go, HTMX, and Alpine will be a powerhouse in 2-3 years.
Convex is an absolute kill, it went so fast to have something usable with no worries about cache invalidations and the dx is so great because there is no obscure errors and such simplicity.
@@WebDevCody Found it thanks to a github repo where I was stealing components setup, so of course I went like "ignore this db saas crapware vendor-locking yada yada". And then 2 month later I tryed it, was impressed.
I've seen HTMX used on 3 large-scale projects. It's not perfect, but it's eliminated all the onsubmit bindings I used to have to write in JavaScript. I like the declarative nature of HTMX. For everything else I can write native JavaScript code to do additional initialization logic, or hook into the HTMX events to deal with things like rich edit controls. At the end of the day it is another tool to make use of. If you find TypeScript and next.js is easier for you then use that.
My main problem with modern frontend frameworks is that I'm so traumatized with Angular and Webpack, which takes and absurd amount of time to build and deploy, and the developer experience isn't great either. I can listen a full 3 minutes song here on YT while the Angular dev server tries starts up on the company-provided potato laptop. That's why I chose HTMX, I didn't wanted to deal with that. And the reason I don't like React is that it brings back Vietnam memories from the JSP days.
I think those tools (Webpack specifically) are best suited for build tools that package bundlers, and not by themselves nowadays (unless you have a very specific environment setup). Webpack _can_ be very fast and its dev experience excellent, but you have to spend upfront time to get there, since it's quite low-level compared to Vite, which just wraps ESBuild and Rollup. For example, Metro on React Native is relatively fast when you consider the number of files and dependencies that often come with a React Native app; without all those dependencies, it builds in a very small amount of time, and you can be pretty sure that there's not going to be inconsistencies between development and production builds. Vite has bit of a problem with this, since it uses different bundlers depending on the environment its built against. I don't know about Angular's specific setup, but that does indeed sound terrible if it takes 3 minutes for a development server. I have fortunately not have such a bad experience with Webpack (not using Angular), but we've since moved to Vite on my team, and deal with the inconsistencies as they come, which with every version gets very minimal at this point.
For enterprise CRUD apps there is no reason to use front end framewoks. htmx and hyperscript are more than enough. Those absolutely don't need so much interactivity
I've been doing full stack with both Go and React for 8 years, and I never mix the two. Use hammer as hammer, and use drill as drill. The moment you start using the wrong tool, or try to bolt your hammer onto a drill, disaster happens. Make yourself comfortable with multiple tools, not doing everything with the same tool.
Theo if you write a unit test in the same package as the unit you're testing, nothing needs to be exported. I'm sorry to say that comments like these make you sound like you really don't know the absolute bare basics of what you're talking about.
He probably meant, he had to ‘const foo’ > ‘export const foo’, making the previously private-to-the-file variable public to everything else in the current package just to test it.
Appreciate him giving it a go and having opinions on it from using it. So many opinions out there are just theory and not people who have actually tried to actually build something.
Astro > Next So much easier to work with and manage. And if you need a fully featured application with different roles, permissions, interactivity, etc, then you still shouldn't be using next. SSG/SSR The portions of the application that don't require a login. And devlop the bulk of the application as a SPA
It's weird that almost all complaints were aesthetics but he left the biggest one: templ templates does not have any kind of highlighting when you use go code, CSS, tailwind, htmx or any other js thing. It's just plain text. Whatever you type it just looks at you as you are writing in a txt file. As someone who was learning to use alpine, htmx and templ at the same time, I had to triple check everything I typed with another monitor to make sure that is the correct way to create a variable for alpine inside a " " but { } if you want to use a go variable but then you gotta make sure to convert everything to string otherwise templ goes crazy so now I have to make a helper function that gets every argument and converts it into string and returns a string so I can add that to my alpine state description... And you just ask yourself what am I fckn doing? HTMX having weird bugs on me cost me a job btw. HTMX does not run certain update triggers unless that form is updated outside once for me. That made the state of client and the server disconnect which is the WHOLE point of HTMX, to have a one-to-one state on the server.
Comparing htmx with NextJs is like comparing a bicycle with a car - they are completely different, they offering different solutions for different type of problems (and goals).
Sepnds 10 years coding javascript: WOW who'd think I'm performant in this language!? Then Spends 4 weeks using Go: wow, I'm not as productive as the language I'm proficient in, because I've used for 10 yers... wow I can't believe it
Theo's diagram makes me realize how powerful Blazor is if you want the best of both worlds. It is like REACT and GO, but in a single solution/framework.
I was a Next.js fan in the past. I liked it and was good at using it. Then I started using different languages than JS (C#, Kotlin, C, Go, Rust, …) and fell in love with Go. Now I can't use Next anymore because it makes no sense to me. Next feels less like a framework and more like a working web server that I can configure using JS code. It's challenging to describe that more precisely. I don't have his problems with dev experience, using Air for dev and Docker for prod. I switched from Neovim to Goland which fixed all my language server issues. I can see the rest of his pain points. The reason I like Go more than JS is that I hate the JS ecosystem enough that I would use anything to stop using JS, and Go is the thing I hate the least.
Almost all the stuff he had to add to make HMR work is related to JavaScript, and that why people complain about. If you just want to start a project and add some good practices to it, you’ll need TypeScript, Eslint, Prettier, at least in the backend side. As of Go you’ll need to basically install the VSCode extension and Air for hot reloading, the tooling in Go is much better.
One of the unspoken evils about string interpolation in JavaScript is the ambiguity of what gets called to do it. I recently learned (the hard way) that implicitly valueOf() is actually called first, and then toString(). So, if you happen to implement both, then you need to contend with the fact that string interpolation prefers valueOf() over toString(). You can explicitly call toString(), but then it's hardly any different than using a string formatter.
the whole point of vscode is not needing to write your own implementation of stuff like that, the templ lsp authors should be responsible for that behaviour
@@xsharawi i use nvim and write my own plugins for a bunch of pointless shit, i'm just saying for a person that chooses to use vscode they're probably not looking to write a plugin
The argument for editor support is a huge one. That's why Laravel for example are working extremely hard to integrate aVSCode extension that actually functions, because most devs will give anything a shot, but the moment it becomes annoying they're going to peace out.
Seems to be complaining more about go, templ and VSCode. Anyway not liking HTMX is fine, using nextjs is fine to each it's own. I'm using blazor and loving it
int to string conversion can throw an error in JS as well, you just don't know until runtime and your code explodes. (it's actually worse than that, it returns NaN, which you should be checking with isNaN)
The open API wrapper thing requires you to trust the type definitions from the backend, and which are often obviously wrong, so I end up using Zod to validate them client side because I don’t have control over the backend codebase and the other team doesn’t care enough
The original video annoyed me no end. He picked a rock solid language and paired it with Templ, a tool which is barely used and is little more than a thought experiment outside of the TH-cam developer context. Not only that, he then complained about IDE experience when using said fringe tool....
I will say one thing about string manipulation in golang, if readability is the primary reason you want that feature, why not just use fmt.Sprint() instead of fmt.Printf(), you can write out the arguments to be much more readable that way like fmt.Sprint("I like ", cheese(), " and the t3 stack")
TBH no packages is not a lie, go wasn't meant to be used as a fullstack/SSR/HTMX framework, use it as a backend framework and you don't need to install any packages to make it work. Everything is built in the formatter, the linter, package manager, testing tool etc. The only thing thats really missing even if you use it as it was meant is a recompile on code change. Never understood the hype for htmx and its "simplicity" people trade a frontendframework made for making websites for backendframeworks/libraries like templ etc. and sure than everything is much more simple yea right.
There is not only developer quality of life, but also a performance of a service itself. NodeJs SSR and especially NextJs ssr is a magnitude slower than Golang. You need more infrastructure to scale the same app.
People will say that these complaints are just whining about enforced good practice, but I think that misses the crux of the issue. Enforced good practice is great in production code, but it can make learning a language a much more painful process. "Skill issue" is go-to the response to that complaint, but a beginner has no skills, and that's precisely *why* it's an issue.
I've seen many people going after programming languages and framework trends but at the end we together in JavaScript. And the good thing about JavaScript you learn once and do everything frontend as well backend 👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽
Just wanted to comment and praise you for the fact that you didn't include a part of Cody's video and told us to go watch it. This supports the original creator in a big way which I love.
02:52 Maybe JS brainrot finally got him :D And he now cannot write in anything except JS :D 11:57 Absolutely right. Click on fun should bring to definition. If not - dump the thing. 30:00 Great stuff about context switching! It is the same as cache in computer L1, L2, L3 - the more you use it, the less cache misesses, a branch of code (your thoughs) would be more predictable, if you do less context switching, and focus on one thing at a time. Which makes you spend the same amount of calories in brain each day, but be more productive with more cache hits (focused work on one thing).
*Laughs in Intelij's Kotlin* It's funny how all those things are non-issues in Java/Kotlin when combined with Intelij. Verbosity is so easy to overcome with autocomplete and everything else is just performent and matured light years ahead of GO/JS
Theo keeps saying 'modern webtools and technologies' strictly to refer to the gospel of react. Arguably HTMX is more modern. It is so modern it is still developing very fast.
Go is good on the backend/cloud, and I love it there. There's hardly anything better (once you get used to it) for writing a lot of kinds of tools/services. It makes a lot of things easy to write that are easier to maintain than most other langs if you are on a decent size team. For frontend-related stuff, hell no. I think templ and htmlx are never going to be as good as your expectations as a good/very experienced frontend dev though.
@@DarthVader11912He "hates" people who use js for the wrong reasons. He "hates" fully serverless nextjs ssr server components with all the blows and whistles, to render a CRUD used by 10 people
Zero technologies are perfect. Everything has a use case. Being able to appreciate the good and bad of different things is what being experienced is. If you start adopting something, especially at large scale and you can't describe what you don't like about it, slow down and make sure you don't have snake oil.
It’s also strange to hear about typescript type safety vs go. Go has runtime type safety, typrescript is transpiled to JS and doesn’t have runtime type safety
Pieters Levels was right some influencers are getting paid to push a narrative toward some frameworks, it doesn´t matter the stack, just get chi***t done, he uses PHP and jquery and is more successful than the majority of these influencers, second next is a framework and go is a programming language of course in go you need to be more explicit
that's the difference between mentality. Pieter thinks like a businessman and knows that tech stack doesn't matter to the customer but devs think more like software engineers to optimise their tech stack for big companies because that's their job. People need to start thinking what's best for themselves and stop blaming others. There's enough room for both sides to win.
20:58 "Lower your UX ambitions and then you'll love it" Wow. Just wow. Lower you DX ambitions and you'll love coding in notepad. Lower your salary ambitions and you'll love your crappy job. Lower your food ambitions and you'll love eating rotten sh*t from trash cans. Why not, really?
Can you get the ctrl+click thing if you're just making a nextjs api without trpc? Do I need trpc for e2e type safety and all those benefits? Don't really like the trpc syntax.
The Templ click through thing is 100% real. Templ is just too annoying for me. The gains you get for it aren't great either, so I've just been using go's built-in templates.
3:40 Yeah I would never voluntarily pick a language without string interpolation as my main application language. Details like that are a big deal for developer happiness and readability. But yes - perhaps I'd say the same about something else (like error handling) if I was used to a different language.
I liked this video a lot. Actually, I liked very few of Theo's videos. Still, I respect his work and use it to check my understanding of the less-known areas. Here is my take on golang. The usage of golang for frontend development is not a good choice. If you abuse golang with frontend duties where HTML+CSS+JS has to be treated with care and respect. For tasks, where precise UI and UX behavior is demanded, XHTML or any templating package/technology/tool will fail to produce acceptable results. Golang is best used for the backend and CLI. Where it shines. I love and use golang as my primary language, but please do not use it for the frontend. That is just silly. If you want a smooth experience and a transition path from frontend to backend, you have to land on one language. That one language obviously is JS or TS, because there is only one language in the browser (wasm left out for the time being). To bridge the frontend with the backend you have the freedom to choose anything built on JS/TS. There is no other choice, at least for now. That is more related to IDE support of multiple languages and the ability to connect those into one smooth experience.
"Lower your UX expectations and then you'll love it" "Lower your DX expectations and then you'll love it" "Lower your expectations..." Brother at this point I'll clap if the damn thing prints "Hello, World!"
IDK about you but I find JS Dev Hi5'ing themselves for DX absolutely hilarious, The UX thing yes HTMX is not a replacement for React etc etc you have to use something like alpine js for the react-ish things HTMX is not a magic bullet. Coming to the DX part just chill down it's only been like 1 or 2 years since all these blew up templ is only 3 years old htmx while older than templ only came to prominence in the last 2 years and it's a growing community everyday u see new people coming in and in 2 years it's 70% of the DX u get from using next js which has been around for 10 years and u only got niceties like end to end typesafety a robust hot-module reload (which break in larger project regardless) etc like 2-3 years back. IDK why you are comparing something so new to an already establish project and expecting it to be 1:1 DX give it time to grow.
@@KodeAkuma JS devs Hi5ing is hilarious since most of Theo's comments parrot the same opinion regarding shitting on JS, it's not a minority opinion at all. Agreed other ecosystems might take time to develop but people who don't like JS offer those ecosystems as a silver bullet to cure all JS pains but as you said it isn't huh? Funny that...
I am not ok with those issues, I hard all kind of issues with anything basically I haves used since 2011 and this is what I did, I just solved them and got help solving them. I stoped using Go because I hated writing quite a lot of code for thing like data validation. Somehow the same thing just take less efforts in rust when you know what to do. I now use Rust and I really wanted Go at first. I comme from Java land. I love AOP and functional programming good error management. Strict contracts for things like form validation. Maybe I got more skill issues in Go but I could not achieve a level of control that was satisfying enough in Go. So I rewrote the little code I had already written in go in rust and man I felt the power infuse in my blood.
Some people here say 2 weeks are not enough to learn HTMX. Well sure you won't learn every nook and cranny but god damn, if a seasoned JS dev is still not reasonable productive after 2 weeks, dislikes the tech and sees big maintenance issues (random ID references, not type safety in the inline JS code etc), that's on the tech, not him. Like when I started with Solid for instance, I started creating stuff immediately and even though my code was far from perfect, I was productive and didn't feel like on a roller coaster. If you say HTMX is better suite for smaller apps, fine, but if you say the solution is to mix it with JS where HTMX is out of breath, then I don't see a reason to use it.
so far it mostly sounds like "i've been programming JavaScript for to long so i prefer javascript" it takes awhile when swapping langs to get close to the efficiency of others. like he could easily be useing snippets or ai and then the whole fmt.print thing wouldn't matter (both supported by vscode ( i kinda find it odd he seems to think vscode is a limitation cause generally i've found vscode has better plugin support then nvim just because its used by so many more people )) though ive also been forced to simultaneously multilang for years(lol the joys of my job) so im alot more used to adapting to syntax like that (generally im writing python, nodejs, go, rust, bash, devops bullshit ( ansible, terraform, etc) all in the same day
GO WATCH CODY'S VIDEO th-cam.com/video/mt1ZCai1G-I/w-d-xo.html
A Theo reaction, right after a Primegen reaction. I might as well retire at this point.
Thank you for reacting to my video!
Time to try again in Cursor world!
You have almost the same number of subscribers, come on, don't be shy)
Waiting for new hot takes btw
Cody's a genius. He made a video appealing to Prime, waited the react, than made another one appealing to Theo (clap clap)
Hahaha, :D View gathering :D You reap what you saw ;)
I didnt finish my project in next yet and youtube did a full rotation through all frameworks already
and nothing actually changed in the real world for years now
'handling the errors is not something i care about' XD
Thats the Web Dev mentallity we know and love.
Literally me in Elixir with pet projects. Just "let it crash"
Yeah, this is an underrated take. Sometimes just let things break and then you fix it. I for instance only code about 1/4 of my time, the rest is spending managing my business. So yeah, devs are ALL over the place.
Theo is genuinely the epitome of a poser wanna be programmer who probably has narcistic tendencies
finally someone singing the forbidden tune.
He seems to be complaining more about using Go and Templ than htmx itself...
You don't have to use Go to use htmx...
The htmx creator clearly states that htmx isn't meant to replace JavaScript but complement it and reduce the amount of menial code for things that can be handled by the extended HTML tags.
This further solidifies my opinion that Go is the wrong choice for web backend. Not only do you have to deal with nil pointer and race condition, you would also have to deal with its UX.
Go is less than C# in safety, job availability, and hireability.
Go is inferior to Rust in term of performance, safety, and ergonomic (few languages have such as convenient tool as Rust macros).
@@khai96xthe type of comment someone who doesn't actually write go writes.
Node is the best backend for apps.
@@ivan.jeremic I'm honestly baffled that you actually said that, that you actually insinuated a single core, non distributed, event loop driven runtime with colored functions and traditional exceptions is somehow, the best backend...
@@C4CH3S I could not agree more. nodejs struggles hard with high request counts and if a user of the API does something stupid the whole process will block for a moment good look by the way then figuring out where that happens.
2 WEEKS IS NOT ENOUGH TIME TO LEARN ANYTHING AND JUDGE IT.
So, you can write JavaScript with htmx as well, idea of htmx isn't about no javascript but hypermedia as state representation.
I think web dev cody's experience isn't a real experience in industry cause most of his experience is making youtube videos not products being used by people and 2 weeks isn't enough time to learn Go let alone htmx.
There are people at IBM who are making decent sized projects in HTMX. It would be awesome if you could get them on stream.
I think your view is right in saying that this might not be real industry experience but of an indie hacker who makes videos not products.
Yeah... I think Cody made some phenomenal points about not being to build as quickly, but as for finished product ux... Most real world htmx apps I've heard of ship a small amount of javascript to deal with the few things that don't fit the model, but are still core to good UX. HATEOAS (worst acronym) is really useful for keeping things simple and I think it's a shame that it feels like it got a bad shake.
If you follow his complaints on Twitter, someone says, "If you bumped into some issues while using some library, you must find another way to do it and not double down on your problem so that it works the way you want."
Cody did the latter (and is happy that Carson acknowledged that it's a bug), but there are still other ways to fix Cody's problem.
I mean, did y’all actually think id permanently switch to go and htmx when I’ve been getting paid to write JavaScript, typescript, react, node full time for 10 years now?
The moment my content becomes all Go you know my actual paycheck from work is coming from Go.
Not permanently, no, but getting a bit more bake time would certainly help, especially since you're stepping out so far from your career expertise. In my career experience, two weeks just isn't enough time to switch mindsets - of course you mastered the mechanisms of development in the new stack, but your comments about things like parsing integers and error handling clearly show that you're still (understandably) writing Go while thinking in JavaScript. I write safety critical server software for a living, and I've been learning front end - in the last two years I've written websites with Next.js and Nuxt, and a mobile app in React Native. Even still I can clearly see I'm writing JavaScript but thinking like a back end dev. You do you, though.
@@SteveKuznetsov eh like I said, I think go is good, I just need to get used to how it’s written. HTmX I can’t see the silver lining.
so he setup his project structure like he does in nextjs and tries to force golang into that convention. i see this with java programmers all the time that are trying to switch to golang.
How to do this right sir?
web dev cody's content is nice because he shows himself having incorrect assumptions, he doesn't cut the stuff out, he leaves it all in. I like how he explains how he messes up, works on it to understand, and then shares with his community.
Our team has moved on from the JS framework and isn’t looking back. We now use HTMX sparingly, and that’s all we need. We couldn’t be happier with this approach. Personally, I’ve rediscovered my joy in development, which is the most important thing. If you find satisfaction working with Next, React, Vue, or any other framework, go for it. The key is to enjoy what you do. HTMX has been great for us.
I'd be interested to hear some examples/specifics.
Honestly I've been contemplating taking my company in a different direction as well. I've been doing this for 20 years and the last decade has been hell trying to navigate all of these constantly changing frameworks. I'm kind of sick of it.
I think there is way too much of lack of deep understanding about tools and where to use them.
We have the thing called "web", hypertext documents to share stuff. But it went to every machine so it became very early as standard way to make user interfaces for *applications*. Application is different thing than example some some company web page.
Of course browser was very limited because everything was depended on page loading. In fact Javascript was considered as optional thing most of the 00s. It was around 2009 when it makes sense to write applications that are expected to work everywhere so we can actually make things dependent on Javascript. It started from jQuery, paradigm was server rendered UI with page loads, but jQuery make usable to make some components dynamic and work without pageloads.
We soon got Angular that was for single page applications and later we got React. But those actually run UI code completely on JS and that was of course terrible idea if project is company web page or similar content page. Applications are not intended to be accessed with search engines.
What happened is that substandard web developers started to overuse Javascript in content pages while in reality they should render them in server and avoid Javascript. Some cases Javascript make sense and those cases were possible to handle with jQuery component long time and past four years web components are way to go.
It is just important to make difference is someone making systems that share content or are they making application.
@@LongJourneys
UI code in applications has always gone out of date quickly. If not technology did not start to rot, then it went out of fashion. But when application runs in browser, there was and still is going very rapid development and newer technology reduces boilerplate code or it runs faster.
Yep as a newbie focusing 100% on React is a big mistake. Your learning React ecosystem and not coding or development. Go and templ and HTMX is fine for the most point.
I understand why he disliked Go but I don't think he was using it correctly. You cannot program in Go the same way you program in JS. The paradigm in Go is libraries cannot panic for you, and so if you want less verbose code, just create the functions you need that panic in the way you expect them to. If you handle parsing an int the same way every single time, then create a function wrapper and just use that.
Go does not have to verbose. It's as verbose as you want it to be.
I watched more of the video and I noticed other gripes which mostly come from Javascript habits
I feel like so much of it is just down to what you're used to and experienced with. I came from Objective-C, C# and Python before really getting into Javascript. And my first reaction to Javascript was "Ugh, why does it feel like everything is hidden behind syntactical sugar and shortcuts?" I felt like the amount of syntax I had to learn before I could understand what Javascript code was doing was significantly higher than in other languages I was used to. So for me when I first tried Go the same verbosity he sees as a detriment felt like a breath of fresh air to me. It's more characters to type sure, but I feel like I feel like that's made up by me spending less time than I do in Javascript trying to decipher the cleverness involved when trying to minimize verbosity in coding.
A couple things I noticed:
- not enough time spent learning Go
- bad tooling (e.g. GoLand does go to templ and not compiled file)
Don't get me wrong, he does make good points, but some of them are not.
Interested in HTMX, but have been waiting for a "flip-side" view of its weak points.
Weak points are that you have to do web 1.0 and enhance that instead of building the app like you would for the SPA. It is also clumsy to update multiple things, because you either have to render higher in the tree to reflect all changes, send weird OOB responses or emit events and make those places refresh themselves. It is probably the least messy if you just use "boosted links" and do full page renders, and optimize it later.
@@sarabwtyeah, if you need the high interactivity of a SPA, you are better off writing a SPA. Htmx has other use cases
there are some small gotchas too like including the vary header in the response or ur cache will be all messed up (back and refresh will only render the html partials). its pretty nice tho once you figure it out tbh.
@@sarabwt your whole crap next js bubble is the result of people enhancing web 1.0 for more than a decade to the point of a running a server just for it. at any point claiming that running a virtual dom for a web app when today there exactly no need for it is like picking your car to go to work when your job is 200m away from you. you code for convenience. at this point your not even a programmer, your a IDE user. the real programmers are building your crap performant frameworks.
@@ricardodelacrvz1400 Tf you on about? I work as a BE dev/devops, I never used Next EVER, I hate React, I used HTMX for pretty much every hobby project since 2021 (way before you found out about it) and I use neovim for everything. How highly regarded do you have to be, to think, that HTMX is beyond critique??? Which makes me believe, that none of you ever built any even moderately complex app using HTMX.
12:55 I remember when IntelliJ added support for clicking to go to spring bean/component definitions from the place that they were injected. It made working with Spring and Spring Boot SOO MUCH better.
you should have added a trigger warning before writing "spring bean"
@@dzigizord6567 Well, at least I didn't write JavaBea-... Oops 😅
The whole "Full Stack" world is a very deep local minima that people outside of it don't want to get into, and to get people out of it will take a truly convincing paradigm shift.
are you ok theo? I've never seen such bad arguments from you before.
- "I'm used to JS and I don't like GO's package system because it's weird".
- "I'm frustrated because using something different requires a shift in my mental model"
- "There's only one type of web app"
- "I'm right, I don't care"
I understand you're mad and want to fight the non-sense hype and hate, but take a breath... you know way better than this.
he's always been like this. I'm glad you're finally starting to see it.
His business is T3 stack so he will sh*t on non js stacks just to keep his cash cow running, js has its place but htmx, rails, django phoenix have there place too in fact most of the time you can avoid JavaScript, react, next.js and this non sense but again he lives in his bubble for obvious reasons.
@@hamm8934 Exactly, I got tired of this "Next Next Next" of Theo, IDK if he is, but seems to be sponsored by Vercel to promote that shit framework. Dont watch his videos anymore, I just come here to coment "Stop using Next, use Solid"
@@onça_pintuda999 hes sponsored by vercel
he basically complains about good practices go forces XD
Unrelated, but I've been a long time Rails dev and this weekend I tried NextJS. I'm honestly surprised at how easy it was. There are a lot of simple and powerful ideas in here - not something I expected from a JS framework.
Yeah I really don’t understand why people complain. I’ve been deving since 2001 back with mostly HTML, transitioned to PHP in 2006, React in 2019, and now NextJS. I just happen to use the tools for the trade, yet didn’t expect such a huge cult around each language.
@@kingnick6260 It's javascript of course every framework is a cult
Try Svelte :D
I just really miss migrations, also setting suipabase for local development felt like breaking away from the Hades and I just gave up.
I love Go and consider it vastly superior to JavaScript/TypeScript, and I completely disagree that it's more verbose than TypeScript. However, even though I'd love to create my frontend with Go, I acknowledge that nothing beats the JavaScript/TypeScript ecosystem for that purpose. The development experience for UI/UX with those tools is remarkable. In the end, it's important to recognize that each tool excels in entirely different areas.
I will argue that the speed at which GO compiles is directly proportional to its rigidity in naming. The parser can be a lot simpler, and yes, it cannot compete with the multitude of weird shit you can do in javascript, but thats exactly why javascript is slow. Just like all the conversations about json not supporting a trailing comma, and after examining, you figure out how it complicates the parsing tree and how immense the performance impact would be. Not saying I like the GO way of doing things inherently, but its EXTREMELY important to acknowledge why things are that way. My GO builds compared to NextJS are not even in the same realm.
panic in a POST handler? lul
omegalul
My DX with Go increased immensely by switching to the Goland IDE. No time to mess around with gdb or VS code extensions.
Yeah, this is a large part of the issue. He's using a text editor instead of an IDE.
@@thisaintmyrealname1 I wish I tried it out, I didn’t know about it
I love the new look and feel of Idea on mac, it's so nice.
2:00 so far I only heard, "because of some skills issues, I need to go back to JavaScript".
10:20 again, skill issue.
35:25 is a bad take, to be honest. I don't mean that he has to fully commit to Go or anything like that. I actually appreciate that he tried it out and formed an opinion about its style. However, concluding with "Yeah, so I'm basically a JS/TS dev. You can make fun of me, but whatever," is such a weak conclusion.
For me, being a developer means innovating, improving, and constantly learning new things-that's what I love about the web. You also have to explore what other frameworks and languages are doing to really understand the landscape. Maybe you can take something from the Go/Rust/Zig idioms and apply it to your work in JavaScript/TypeScript. I always seek out new stuff and strive to get good at it, and I've been a JS/TS developer for 10+ years now without losing that passion.
Context switching is not exclusively between languages, back when node didn't support modules i had to write commonJS on backend & ES modules with react and that had me always messing up the node files with ES modules syntax...
The fact that commonjs and es modules is still not resolved and likely won't be for a very long time makes me want to not use node.
Regarding the redirect and login button: We simply do an out-of-band swap of the login form. 🤷
I'm on both sveltekit and go/templ/Htmx, and the dev experience is the reason why I keep going back to js. Especially the hmr and dev server. Not sure why my air/templ setup panics from time to time, and that requires me to kill the dev server and restart it.
I'd love to be a developer whose experience is defined solely by the UI building process.
JavaScript is forever the best 🔥🔥🔥
You should report these panics to air/tmpl
His complaints are valid... but the complaints about the editor linking to wrong files... that what you get for using VSCode. If he used a proper Go IDE like GoLand he wouldn't have had these issues.
The incorrect go-to-file complaint he had is a documented bug on the github repo that they're working on. It's not an easy fix because they basically have to intercept the Go lsp and redirect it to the Templ LSP. If you're already in a Templ file, the go-to-definition works.
Templ is like 2 years old and was made by one dude. Things like this will be gone in a year or two. Templ, Go, HTMX, and Alpine will be a powerhouse in 2-3 years.
My man would fall in love with Elixir based on what he said
I guess we’ll never know
@@WebDevCody😢😢😢
Convex is an absolute kill, it went so fast to have something usable with no worries about cache invalidations and the dx is so great because there is no obscure errors and such simplicity.
You’re a smart man
@@WebDevCody Found it thanks to a github repo where I was stealing components setup, so of course I went like "ignore this db saas crapware vendor-locking yada yada".
And then 2 month later I tryed it, was impressed.
I've seen HTMX used on 3 large-scale projects. It's not perfect, but it's eliminated all the onsubmit bindings I used to have to write in JavaScript. I like the declarative nature of HTMX. For everything else I can write native JavaScript code to do additional initialization logic, or hook into the HTMX events to deal with things like rich edit controls.
At the end of the day it is another tool to make use of. If you find TypeScript and next.js is easier for you then use that.
My main problem with modern frontend frameworks is that I'm so traumatized with Angular and Webpack, which takes and absurd amount of time to build and deploy, and the developer experience isn't great either. I can listen a full 3 minutes song here on YT while the Angular dev server tries starts up on the company-provided potato laptop. That's why I chose HTMX, I didn't wanted to deal with that. And the reason I don't like React is that it brings back Vietnam memories from the JSP days.
I think those tools (Webpack specifically) are best suited for build tools that package bundlers, and not by themselves nowadays (unless you have a very specific environment setup).
Webpack _can_ be very fast and its dev experience excellent, but you have to spend upfront time to get there, since it's quite low-level compared to Vite, which just wraps ESBuild and Rollup.
For example, Metro on React Native is relatively fast when you consider the number of files and dependencies that often come with a React Native app; without all those dependencies, it builds in a very small amount of time, and you can be pretty sure that there's not going to be inconsistencies between development and production builds. Vite has bit of a problem with this, since it uses different bundlers depending on the environment its built against.
I don't know about Angular's specific setup, but that does indeed sound terrible if it takes 3 minutes for a development server. I have fortunately not have such a bad experience with Webpack (not using Angular), but we've since moved to Vite on my team, and deal with the inconsistencies as they come, which with every version gets very minimal at this point.
skill issue.
For enterprise CRUD apps there is no reason to use front end framewoks. htmx and hyperscript are more than enough. Those absolutely don't need so much interactivity
I've been doing full stack with both Go and React for 8 years, and I never mix the two. Use hammer as hammer, and use drill as drill. The moment you start using the wrong tool, or try to bolt your hammer onto a drill, disaster happens.
Make yourself comfortable with multiple tools, not doing everything with the same tool.
Theo if you write a unit test in the same package as the unit you're testing, nothing needs to be exported. I'm sorry to say that comments like these make you sound like you really don't know the absolute bare basics of what you're talking about.
its bc he does not know....
I was really wondering WHY THE FUCK he needed to export something from a package in order to test it...
He probably meant, he had to ‘const foo’ > ‘export const foo’, making the previously private-to-the-file variable public to everything else in the current package just to test it.
@@Soarex he was talking about this as a downside of Golang, which doesn't have that kind of concept.
Appreciate him giving it a go and having opinions on it from using it. So many opinions out there are just theory and not people who have actually tried to actually build something.
Astro > Next
So much easier to work with and manage. And if you need a fully featured application with different roles, permissions, interactivity, etc, then you still shouldn't be using next.
SSG/SSR The portions of the application that don't require a login. And devlop the bulk of the application as a SPA
It's weird that almost all complaints were aesthetics but he left the biggest one: templ templates does not have any kind of highlighting when you use go code, CSS, tailwind, htmx or any other js thing. It's just plain text. Whatever you type it just looks at you as you are writing in a txt file. As someone who was learning to use alpine, htmx and templ at the same time, I had to triple check everything I typed with another monitor to make sure that is the correct way to create a variable for alpine inside a " " but { } if you want to use a go variable but then you gotta make sure to convert everything to string otherwise templ goes crazy so now I have to make a helper function that gets every argument and converts it into string and returns a string so I can add that to my alpine state description... And you just ask yourself what am I fckn doing?
HTMX having weird bugs on me cost me a job btw. HTMX does not run certain update triggers unless that form is updated outside once for me. That made the state of client and the server disconnect which is the WHOLE point of HTMX, to have a one-to-one state on the server.
Comparing htmx with NextJs is like comparing a bicycle with a car - they are completely different, they offering different solutions for different type of problems (and goals).
Agree, Next is a 1998 Fiat Multipla but it's still a car...
One place where JavaScript sucks is with the 64-bit integers. This is a hardcore struggle with BigInt.
Agree
Sepnds 10 years coding javascript: WOW who'd think I'm performant in this language!?
Then Spends 4 weeks using Go: wow, I'm not as productive as the language I'm proficient in, because I've used for 10 yers... wow I can't believe it
Didn't know htmx will have a villain arc
Theo's diagram makes me realize how powerful Blazor is if you want the best of both worlds. It is like REACT and GO, but in a single solution/framework.
I was a Next.js fan in the past. I liked it and was good at using it. Then I started using different languages than JS (C#, Kotlin, C, Go, Rust, …) and fell in love with Go. Now I can't use Next anymore because it makes no sense to me. Next feels less like a framework and more like a working web server that I can configure using JS code. It's challenging to describe that more precisely.
I don't have his problems with dev experience, using Air for dev and Docker for prod. I switched from Neovim to Goland which fixed all my language server issues.
I can see the rest of his pain points. The reason I like Go more than JS is that I hate the JS ecosystem enough that I would use anything to stop using JS, and Go is the thing I hate the least.
Almost all the stuff he had to add to make HMR work is related to JavaScript, and that why people complain about. If you just want to start a project and add some good practices to it, you’ll need TypeScript, Eslint, Prettier, at least in the backend side. As of Go you’ll need to basically install the VSCode extension and Air for hot reloading, the tooling in Go is much better.
One of the unspoken evils about string interpolation in JavaScript is the ambiguity of what gets called to do it. I recently learned (the hard way) that implicitly valueOf() is actually called first, and then toString(). So, if you happen to implement both, then you need to contend with the fact that string interpolation prefers valueOf() over toString(). You can explicitly call toString(), but then it's hardly any different than using a string formatter.
Couldn’t you theoretically write the VScode extension yourself to open the non-compiled file when you command click
the whole point of vscode is not needing to write your own implementation of stuff like that, the templ lsp authors should be responsible for that behaviour
A v*code user solving their own problem? Impossible.
How about using an Actual IDE? Goland for example?
@@xsharawi i use nvim and write my own plugins for a bunch of pointless shit, i'm just saying for a person that chooses to use vscode they're probably not looking to write a plugin
That would assume I’m smart and want to waste a bunch of time doing that
The argument for editor support is a huge one. That's why Laravel for example are working extremely hard to integrate aVSCode extension that actually functions, because most devs will give anything a shot, but the moment it becomes annoying they're going to peace out.
Seems to be complaining more about go, templ and VSCode. Anyway not liking HTMX is fine, using nextjs is fine to each it's own. I'm using blazor and loving it
int to string conversion can throw an error in JS as well, you just don't know until runtime and your code explodes. (it's actually worse than that, it returns NaN, which you should be checking with isNaN)
The open API wrapper thing requires you to trust the type definitions from the backend, and which are often obviously wrong, so I end up using Zod to validate them client side because I don’t have control over the backend codebase and the other team doesn’t care enough
The original video annoyed me no end. He picked a rock solid language and paired it with Templ, a tool which is barely used and is little more than a thought experiment outside of the TH-cam developer context. Not only that, he then complained about IDE experience when using said fringe tool....
Nothing he said about go is a legit issue. He is so deep into js he cant think beyond js ecosystem. I understand that cause i was there too.
I will say one thing about string manipulation in golang, if readability is the primary reason you want that feature, why not just use fmt.Sprint() instead of fmt.Printf(), you can write out the arguments to be much more readable that way like fmt.Sprint("I like ", cheese(), " and the t3 stack")
TBH no packages is not a lie, go wasn't meant to be used as a fullstack/SSR/HTMX framework, use it as a backend framework and you don't need to install any packages to make it work.
Everything is built in the formatter, the linter, package manager, testing tool etc.
The only thing thats really missing even if you use it as it was meant is a recompile on code change.
Never understood the hype for htmx and its "simplicity" people trade a frontendframework made for making websites for backendframeworks/libraries like templ etc. and sure than everything is much more simple yea right.
There is not only developer quality of life, but also a performance of a service itself. NodeJs SSR and especially NextJs ssr is a magnitude slower than Golang. You need more infrastructure to scale the same app.
People will say that these complaints are just whining about enforced good practice, but I think that misses the crux of the issue.
Enforced good practice is great in production code, but it can make learning a language a much more painful process.
"Skill issue" is go-to the response to that complaint, but a beginner has no skills, and that's precisely *why* it's an issue.
I've seen many people going after programming languages and framework trends but at the end we together in JavaScript. And the good thing about JavaScript you learn once and do everything frontend as well backend 👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽
40:11 just replace go with any backend server lang that you want to use. It still make sense.
Just wanted to comment and praise you for the fact that you didn't include a part of Cody's video and told us to go watch it. This supports the original creator in a big way which I love.
the package name does not need to match the directory name that the go files exist in.
where does my fav Django fit in? I'm contemplating Django HTMX for builds (after a hiatus of web dev for a few years)
The funny thing is that I very often disagree with something Theo says, but in this video I agree 100%
respect for actually pushing people to the original video
I know Theo is a chad for that
02:52 Maybe JS brainrot finally got him :D And he now cannot write in anything except JS :D
11:57 Absolutely right. Click on fun should bring to definition. If not - dump the thing.
30:00 Great stuff about context switching! It is the same as cache in computer L1, L2, L3 - the more you use it, the less cache misesses, a branch of code (your thoughs) would be more predictable, if you do less context switching, and focus on one thing at a time. Which makes you spend the same amount of calories in brain each day, but be more productive with more cache hits (focused work on one thing).
Sounds like he didn’t like go. Perhaps Kotlin should’ve been the language chosen for someone with a JS brain.
*Laughs in Intelij's Kotlin*
It's funny how all those things are non-issues in Java/Kotlin when combined with Intelij. Verbosity is so easy to overcome with autocomplete and everything else is just performent and matured light years ahead of GO/JS
Theo keeps saying 'modern webtools and technologies' strictly to refer to the gospel of react. Arguably HTMX is more modern. It is so modern it is still developing very fast.
WDC is a genius. Would not have thought you could milk the anti-js AND the pro-js crowd back to back in a matter of weeks but the lad did it
13:23 what font editor is this? Looks non-standard, looks really nice
Would you ever do a deep dive into Nuxt to see what the Vue grass is like on the other side of the fence?
Go is good on the backend/cloud, and I love it there. There's hardly anything better (once you get used to it) for writing a lot of kinds of tools/services. It makes a lot of things easy to write that are easier to maintain than most other langs if you are on a decent size team. For frontend-related stuff, hell no. I think templ and htmlx are never going to be as good as your expectations as a good/very experienced frontend dev though.
If you go back to Next.js, should you rename it to Prev.js?
Typescript (solidjs) and C# (aspnet core with openapi 3) are similar enough the context switch isn’t a problem at all
Prime in shambles
shambles how?
@@stan______he hates JavaScript snd people who use it.
@@DarthVader11912 people who use it??? where the heck did you get that from
@@itsmeagain1415 come on it's straight up obvious.
@@DarthVader11912He "hates" people who use js for the wrong reasons. He "hates" fully serverless nextjs ssr server components with all the blows and whistles, to render a CRUD used by 10 people
Looking at Peter Levels, who builds startup after startup using just PHP, HTML, and CSS-each with just one file-really makes you think...
Code organization is important for when you work with multiple people. If you are solo thats not neccessary.
Zero technologies are perfect. Everything has a use case. Being able to appreciate the good and bad of different things is what being experienced is. If you start adopting something, especially at large scale and you can't describe what you don't like about it, slow down and make sure you don't have snake oil.
It’s also strange to hear about typescript type safety vs go. Go has runtime type safety, typrescript is transpiled to JS and doesn’t have runtime type safety
Pieters Levels was right some influencers are getting paid to push a narrative toward some frameworks, it doesn´t matter the stack, just get chi***t done, he uses PHP and jquery and is more successful than the majority of these influencers, second next is a framework and go is a programming language of course in go you need to be more explicit
that's the difference between mentality. Pieter thinks like a businessman and knows that tech stack doesn't matter to the customer but devs think more like software engineers to optimise their tech stack for big companies because that's their job. People need to start thinking what's best for themselves and stop blaming others. There's enough room for both sides to win.
34:30 superly duperly based please keep doing this
just dont use nextjs and be happy
PHP and Python Devs for last 10 years never complained about context switching from BE and FE :D
20:58 "Lower your UX ambitions and then you'll love it"
Wow. Just wow.
Lower you DX ambitions and you'll love coding in notepad.
Lower your salary ambitions and you'll love your crappy job.
Lower your food ambitions and you'll love eating rotten sh*t from trash cans.
Why not, really?
Can you get the ctrl+click thing if you're just making a nextjs api without trpc? Do I need trpc for e2e type safety and all those benefits? Don't really like the trpc syntax.
The Templ click through thing is 100% real. Templ is just too annoying for me. The gains you get for it aren't great either, so I've just been using go's built-in templates.
using go with templ my ctrl+click takes me to the template definition, not the compiled code, something's weird
3:40 Yeah I would never voluntarily pick a language without string interpolation as my main application language. Details like that are a big deal for developer happiness and readability.
But yes - perhaps I'd say the same about something else (like error handling) if I was used to a different language.
I liked this video a lot. Actually, I liked very few of Theo's videos. Still, I respect his work and use it to check my understanding of the less-known areas.
Here is my take on golang. The usage of golang for frontend development is not a good choice. If you abuse golang with frontend duties where HTML+CSS+JS has to be treated with care and respect. For tasks, where precise UI and UX behavior is demanded, XHTML or any templating package/technology/tool will fail to produce acceptable results.
Golang is best used for the backend and CLI. Where it shines. I love and use golang as my primary language, but please do not use it for the frontend. That is just silly.
If you want a smooth experience and a transition path from frontend to backend, you have to land on one language. That one language obviously is JS or TS, because there is only one language in the browser (wasm left out for the time being). To bridge the frontend with the backend you have the freedom to choose anything built on JS/TS. There is no other choice, at least for now. That is more related to IDE support of multiple languages and the ability to connect those into one smooth experience.
Hey it is almost as if streamers and content creators are just mentioning the tech that gets them the most views, isn't that odd 🙃
"Lower your UX expectations and then you'll love it"
"Lower your DX expectations and then you'll love it"
"Lower your expectations..."
Brother at this point I'll clap if the damn thing prints "Hello, World!"
IDK about you but I find JS Dev Hi5'ing themselves for DX absolutely hilarious, The UX thing yes HTMX is not a replacement for React etc etc you have to use something like alpine js for the react-ish things HTMX is not a magic bullet. Coming to the DX part just chill down it's only been like 1 or 2 years since all these blew up templ is only 3 years old htmx while older than templ only came to prominence in the last 2 years and it's a growing community everyday u see new people coming in and in 2 years it's 70% of the DX u get from using next js which has been around for 10 years and u only got niceties like end to end typesafety a robust hot-module reload (which break in larger project regardless) etc like 2-3 years back. IDK why you are comparing something so new to an already establish project and expecting it to be 1:1 DX give it time to grow.
@@KodeAkuma JS devs Hi5ing is hilarious since most of Theo's comments parrot the same opinion regarding shitting on JS, it's not a minority opinion at all.
Agreed other ecosystems might take time to develop but people who don't like JS offer those ecosystems as a silver bullet to cure all JS pains but as you said it isn't huh? Funny that...
I am not ok with those issues, I hard all kind of issues with anything basically I haves used since 2011 and this is what I did, I just solved them and got help solving them. I stoped using Go because I hated writing quite a lot of code for thing like data validation. Somehow the same thing just take less efforts in rust when you know what to do. I now use Rust and I really wanted Go at first. I comme from Java land. I love AOP and functional programming good error management. Strict contracts for things like form validation. Maybe I got more skill issues in Go but I could not achieve a level of control that was satisfying enough in Go. So I rewrote the little code I had already written in go in rust and man I felt the power infuse in my blood.
Developer velocity is as important a consideration as raw performance.
The assumption that go is the only performant language on the server is kind of weird.
Java, C# and others are a big no-no in hype driven communities.
This editor flow is why I can't write ruby without rubymine. Trying to write ruby in vscode is a nightmare.
Some people here say 2 weeks are not enough to learn HTMX. Well sure you won't learn every nook and cranny but god damn, if a seasoned JS dev is still not reasonable productive after 2 weeks, dislikes the tech and sees big maintenance issues (random ID references, not type safety in the inline JS code etc), that's on the tech, not him. Like when I started with Solid for instance, I started creating stuff immediately and even though my code was far from perfect, I was productive and didn't feel like on a roller coaster. If you say HTMX is better suite for smaller apps, fine, but if you say the solution is to mix it with JS where HTMX is out of breath, then I don't see a reason to use it.
Error handling in Go is still the GOAT!
so far it mostly sounds like "i've been programming JavaScript for to long so i prefer javascript" it takes awhile when swapping langs to get close to the efficiency of others. like he could easily be useing snippets or ai and then the whole fmt.print thing wouldn't matter (both supported by vscode ( i kinda find it odd he seems to think vscode is a limitation cause generally i've found vscode has better plugin support then nvim just because its used by so many more people )) though ive also been forced to simultaneously multilang for years(lol the joys of my job) so im alot more used to adapting to syntax like that (generally im writing python, nodejs, go, rust, bash, devops bullshit ( ansible, terraform, etc) all in the same day
I like go and rust a lot, but you should consider other languages if you need flexibility, succinctness, and fast developing/refactoring
trpc is the shit. T3 is the shit. t3 turbo is the elephant shit. Fucking love it.
TBH, not everything with web must go with nextjs / react... and somehow those UX are not necessary when using SSR