Why Templates Sucks and Are Better than JSX

Recorded live on twitch, GET IN
/ theprimeagen
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...

[@andyk2181]

The difference between a library and a framework is that with a library you call it, but with a framework it says it'll call you and you don't get the job.

[@akinoreh]

Nice. In other words, from the perspective of the tech, it's "I've got this" vs "You've got this". Personally, I prefer that the tech provide the tools and say "you've got this."

[@josefaguilar2955]

I built my own UI and reactivity recently and found that the reactivity part (updating the UI when something changes) is where I was able to get the most performance gains. Dont let others tell you when to update, you tell them when you're ready to update.

[@reynhardprivate397]

I have never even looked into it but can imagine not just performance gains but also much smaller bundle size since you not shipping a framework with you app.

[@monad_tcp]

The reactivity part really isn't that difficult. You have some sort of observer model or events. You change the model, events happen, you render a new HTML. Then its a matter of a simple tree diff, heck, Jquery has a library for that. You are totally right, you tell it to update, how hard is that ? I was using Fable because I program in F# for the Web and I use Elmish which is the same concept as Elm language or ReasonML. You have pure functions that you call with your model, they return a new HTML to be rendered and a new changed model. No need for Redux stupidity, no need for hooks, no need for all that react crap with contexts. No need for any library imported from the npm. Its just a simple function, F# has everything that you need, you just need to know how to program using functions. I was using React as a tree diff, but then I changed to Preact, and then I made my own tree diff engine. It really isn't that hard, if you're a programmer. A diff engine is basically a tree walk. If you looked at a node id and didn't found it, you use document.append or something. If you found an child element in the dom that doesn't exist in the Vdom, just delete it, if both keys exist, you recurse. As I said, JQuery has a method for that. That's it. this is what React was supposed to do, any good programmer can code that in one day. What about hooks ? screw hooks, everything is a pure function, the only way is to change the model by returning a new model. You don't need hooks, you push a message to the message loop of the Elmish application. If there's a DOM event, you also push a message. The Elmish application basically does model, event => html, model Simple, fire the render function for that DOM node on the root, yes ! on the root, bubble down the entire VDOM. No, its not slow (it is on React because it is stupid). F# is immutable by default, it is not JS, the render functions are all memoized by default. It will bubble down and do nothing until it gets to the child element that needs to change. I get my application to update in 10ms As long as your tree height isn't that deep, performance wouldn't suffer, and that's a given as you use VDOM and pure functions instead of DOM for calling functions, and you aren't really creating any objects on the heap, the VDOM is really the stack of functions calls, and as most of them are memoized, you get your entire new HTML for minimal effort of the machine. No need to really diff state or vdom if your functions are really pure. React is stupid in that they have Hooks, hooks make all functions you use hooks have side effects, thus no React function is EVER pure, ever. Its impossible to have pure state using React, and that's why it is complex.

[@sidhenidonz]

im ready to update

[@jrmc732]

@@monad_tcpthere is also a trick instead of diffing the whole tree just diff the "holes" values.

[@D2Dev]

I work in a Django shop and we finally moved from django templating to React and it has made front-end work *so much easier*. It's not perfect, but I wouldn't want to go back.

[@PwrXenon]

You’re working backwards. Went from react to django templates and code is now much cleaner and no node

[@skyhappy]

​@@PwrXenonhow

[@sirrhynus4280]

I was just thinking about what makes PHP feel so different from other backend frameworks. Most backend frameworks need a templating engine, PHP is the templating engine.

[@morphles]

PHP is damn nice!

[@tsubasateacher]

PHP is built for the web

[@evergreen-]

All projects I worked on in PHP use templating engines (such as twig or blade) on top of PHP. So the ugliness of PHP being a templating language but you are never allowed to use its templating features but have to learn another atrocity to do that

[@monad_tcp]

which is why PHP is bad (TM)

[@CottidaeSEA]

​@@evergreen-I honestly prefer using Twig. You get loads of things like XSS protection (mostly) for free since the templating engine does that job for you. It is absolutely possible to make something do that for you after passing variables, but then you're really just building your own templating engine.

[@pokefreak2112]

jsx is just syntax sugar for a function call. It's pretty nice if you don't use any frameworks and just define your own (sane) jsxfactory.

[@reynhardprivate397]

I like this I am a backend developer by heart but sometimes I just need to build a little frontend to show case the work visually. My mentality when looking at frameworks have been they are supposed to make my life easier by providing some abstraction and sugar, so I don't have to worry, but somehow feels like I add more complexity.

[@monad_tcp]

They make life hard, I don't have the mentality of a frontend developer to program by trial and error copying and pasting code from the internet and just installing crap on node_modules. Web development is hard because programmer go great length not to program. All I ask is a simple question. Why can't programmers program ? web developers work really hard not to work as programmers... almost like the opposite of NIHS (not invented here), they have IHS (invented here syndrome), invented here, they can't use code they created, they have to import code from the wild web.

[@valerioversace9604]

Men will have families, hobbies, kids, gym, thinking about the roman empire, a million things that demand their time and attention. But they won't resist spending a massive amount of waking hours thinking about what the least aggravating way to do HTML templating is and possibly make videos about it.

[@benmeuker4921]

Are these issues with react or with JSX? JSX does not have context nor data-fetching nor top down rendering, it is per definition a syntax that mimics html in js/ts. Anything else has nothing to do with it, so I don't really understand these complaints.

[@deiminator2]

Because JS and react bad

[@negenalamjiyn6637]

​​@@deiminator2 I hear a normie here

[@koalaproductions8946]

I worked in Django templating for a long time, before eventually dropping it for React. Templating is great until you need to support something for a long time and then you realize there is a ton of logic in the template AND the javascript and those need to interact in a way that gets incredibly confusing. There are also levels of complexity that a project can reach that can feel incredibly difficult in templating that have drop in packages in React. And if you wrote it in React, you always have that in your back pocket if at the cost of some up front complexity You just can't get away with "oh the backend is responsible rendering here, but then it turns out we need some extra javascript here to help" forever. React replaced templating for a good reason. People didn't just wake up one day and decide to make their lives miserable. But maybe your project gets lucky and you never have to deal with this

[@aster_jyk]

"JSX - which stands for 'JavaScript Sucks'" I'm on the floor right now

[@Manana7016]

This got me too.

[@andyk2181]

It's funny because it's true

[@aster_jyk]

"No matter what you choose, it sucks" - amen. React is DEFINITELY a framework. It informs every single future decision you're going to make in your UI Ultimately, I think JSX is more useful than templates, IF you're using a lot of JS and have a lot of client side interactivity. Yes, you have more freedom and that freedom is dangerous as hell. But it's so nice and convenient that your components can just be functions and you can use JS in them to transform it however you want to see fit. I'm really liking Solid. React uses JSX in an insane way and recomputes it at every which opportunity, but since Solid actually only renders components once, so you treat it more like a template language that does a little bit of logic to create that initial view. It also has dedicated control flow components for Show, Switch, and For loops.

[@DragonRaider5]

Totally agree, except that React gives you the opportunity not to recompute all the time... It's just hard (and that's obviously a bad thing).

[@aster_jyk]

@@DragonRaider5 Yeah the worst part about React is that you need to trade readability (the ability to use inline arrow functions as props for example) to achieve real performance. The best solution when you get to that point is to use an external state management library and try to use that for almost all your state. Otherwise, you will just run into issue after issue of forgetting to memo something, forgetting to usecallback something, then you fall into dependency array hell, and it just sucks. Or... you can just use Svelte or Solid which are faster than the MOST optimized React code BY DEFAULT ¯\_(ツ)_/¯

[@sam.0021]

Solid gang represent 🙏

[@monad_tcp]

The problem with JSX is that it is JS "almost" but not quite.

[@CottidaeSEA]

React is a mutation management framework, that's how I'd describe it at least.

[@Krzysiekoy]

2:05 - maybe I am just a confused script kiddie, but what does JSX have to do with context / redux? - you can use redux on its own (without react) - you can use jsx on its own (without react) It sounds like you are saying that JSX somehow has a functionality of creating and managing some context? But that can't be right... What am I missing here.

[@greendsnow]

The answer is Sveltekit.

[@pigeonnnn]

Lol no the obvious answer is laravel + react + jquery

[@neociber24]

​​@@pigeonnnnSprinkle that with a little of Livewire

[@greendsnow]

@@pigeonnnn laravel is tempting, tbh

[@JonathanDunlap]

Svelte, Astro, and Deno Fresh are all great modern options. I don't understand why vanilla no-magic JSX templating on the backend is bad in any way.

[@blackpurple9163]

😂😂

[@jrood]

People do many crazy things in React. You can use templates without any of that. JSX and Templ are actually very similar in that they both transpile into code that uses a library. (And I like them both)

[@TheAwesomeDudeGuy]

Preach

[@boreddad420]

react is a framework

[@leo221198]

is a lib

[@DaviAreias]

React is indeed one of the frameworks of all time

[@neociber24]

How dare you

[@tokiomutex4148]

​@@leo221198When your webapp runs is your spaghetti calling React or the other way around?

[@hamm8934]

@@leo221198then add it to a non react project and use it. Library: can be used in nearly any repo Framework: you have to design your repo around it

[@dragenn]

The funny thing is talking about his will cost you a job. I dare someone to talk about this in an interview.

[@wanking9040]

What makes JSX so extremel powerful and superior to others is the fact that with Typescript, you get Type safety inside your HTML. This was a complete a game changer for me. This is what HTML should have been like from the beginning.

[@efkastner]

Same as it ever was! yaml -> helm charts -> pulumi -> back to directly editing yaml the rails word went from erb to haml to mustache etc etc there's always one more thing people want in the templates so it either gets added or forked, over enough iterations, someone finally says "screw it, let's just use a real programming language", and then the inevitable reaction is to move to (or create) a super simple, stripped down templating language. I see it even in the comments here - one person moved from Django templates to react, and someone replied saying they did it backwards and THEIR project went from react to Django templates. Also Prime has talked about projects everyone should do once - making a template system is a great one of those. You learn about parsing, tokenizing, contexts, string handling, and more.

[@neociber24]

You are assuming JSX === React, which is not true. We can do the same with JQuery

[@ea_naseer]

you need jsx to do anything non trivial in react. oh yes if you are a 10x Dev sure you can do without it but most of us aren't 10x. I'm not at least.

[@JeyPeyy]

@@ea_naseer Yes, but you can also use jsx with Vue, in which some of Prime's points are moot.

[@jouebien]

what you described with go sounds like raw dogging php with extra steps.

[@havocthehobbit]

all these perceptual abstractions we create are really just layers complexity weve built and held onto out of comfort and being sold by people who intentionally want to create micro economies to maintain and live off of . The upfront simplicity of JSX and many other libraries and frameworks that live online alongside other things that can be sold with them , just keep going because of that hidden factory that unofficial saleman(senior,principal devs ,engineers and architects ) in every company pitch to have consistent income from building on complexity that inevitably will stretch their projects to a tip of increased hours to make living off of .

[@apollolux]

For many of my smaller projects, I use piecemeal HTML files with Mustache-like {{ }} notation for inline logic and replacement and rolled my own "Smarty-lite" PHP template parser to process the text. Admittedly, it's not as robust or field-tested as Smarty proper or other templating systems in other languages, but for 95-98% of the web dev I've had to do it got the job done _and_ works on PHP 5, 7, and 8. Yes, I've had clients with websites on servers that never upgraded past PHP 5.6 and don't give us the ability to choose the version ourselves. Yes, it's PHP. Yes, I still work in PHP. No, I'll only stop using PHP in professional web dev when servers stop supporting PHP as a CGI option.

[@zacanger]

I love JSX. Hated it when React first came out, but now I'm totally sold on the idea. The thing is (and this is how I've been trying to sell it to my Angular-loving architect), it's not HTML, and you can't think about it that way. It's JS/TS plus some syntax sugar for returning UI, HTML isn't a part of the equation at all.

[@kasper_573]

Data fetching, context and top down rendering are component and framework concerns. JSX literally does none of those. Critique on my guy, but critique the right thing. Critique React. JSX is just tree syntax.

[@SPeeSimon]

One of the things i dislike about jsx, is that it mixes logic and markup. You have html in your js code. I prefer them separate, so that i know i can find ui in a .html file and logic in a .js or .ts file. And not have to search for that one thing to change somewhere in the file. And since jsx and react are closely related...

[@alerighi]

@@SPeeSimon you have it if you decide to design your react application like that. If you want isolation, you can achieve that: define all React pure component (with no state) that only render what it's passed in the props. Then define the real component (pages) that manage the state of the application and only return the component that you defined before with the context (same as you provide to a templating engine) as prop. In a well designed React project the fact that a component both fetches data and renders the UI is wrong. In the new versions of React/Next, with server components, you are obliged to separate the two things, since to have client interactivity you have to use client components and you want to do your data fetching in a server components so you don't transfer a ton of JS to the client and as soon as the page loads it's ready.

[@ThePrimeTimeagen]

this is the problem, jsx enables these things that is what makes it so difficult.

[@necrophage12]

I tried and tried to get into and like React because it is the big boy in the FE frameworks, but I cannot stand its state management and I hate JSX. My personal favorite to use is Vue with its state management options and templating with directives and things is quite nice. Luckily I have a job which uses Vue, but React for whatever reason makes me want to pull my hair out.

[@janisozols2055]

Yea, write realtime app with go templates. There are so many areas where React can shine, but you cant do it with templating.

[@thekwoka4707]

I dont think jsx is bad, its just people doing tons of crap in it. Using django a lot, and its a real hassle to like have to make one off variables in the context in the view to put in one place in a nested template... You end up with data that doesnt have clear dependencies.

[@john.dough.]

What was the name of the templating language he referenced here? Searching "Go Templ" seems to result in a different a different templating system?

[@FraserChapman]

aHR0cHM6Ly90ZW1wbC5ndWlkZS8= base64 - bloody youtube :) - or just google "a-h/templ"

[@ThePrimeTimeagen]

html/template is go's default one, very nice templ.guide for templ.. pretty clever templater.

[@pkop4]

Prime's Law of programming: "No matter what you choose, it sucks."

[@ThePrimeTimeagen]

facts

[@k98killer]

React isn't a framework: a framework tells you how to do things; React tells you that you can do things however you want as long as it is the Right Way™.

[@hamm8934]

If react is a library, import it into an angular project and use just as you would a library like date-fns or lodash. Oh wait. You cant because its a framework :)

[@k98killer]

@@hamm8934 I was being facetious. React is ridiculous. Redux and React Native are hellspawn.

[@dealloc]

You're conflating to completely separate things, and it's very confusing what you're trying to argue. JSX is a syntax to represent function calls, strings, objects, or whatever semantics you want in a declarative way. Nowhere in the spec or documentation does it mention itself as a templating language. First line of the JSX spec: "JSX is an XML-like syntax extension to ECMAScript without any defined semantics." It is not tied to the DOM in any way, shape or form. It does not determine how its output rendered at the end. That is up to the tool you use to transform those tokens (be it TypeScript, or other transpiler). I'm sure you already knew this, so it's confusing why you brought up this point at all.

[@Salantor]

"React is a lib" was true years ago, when first Angular was still around. Time passed, things changed, React mutated into a framework. It is actually funny how so many people convinced themselves that a bunch of code that can't be easily imported into a project using, let's say, Vue, is a library, but another bunch of code that can't be easily importet into a said project, like Angular, is a framework. And now we are dealing with Next and metaframework bullshit. It's like all of that talk was just a marketing bullshit and nothing else.

[@cherubin7th]

Idk the only thing that annoys me right now with React are the JavaScript quirks, that I cannot get the value from ifs (like let x = if(condition){a}else{b};), and most of all that I have state and setState that instead of just state = x and when state is an object to change one value in that objects sucks.

[@FraserChapman]

I was thinking more about the templ example given (I love templ btw!) and just thought the reasoning "I don't want to create a bunch of structs" to pass to templates was a bit odd. My reasoning being that really in go a function signature is just a blueprint for a struct that exists only within the scope of that function. When you pass parameters to a function, you're essentially creating a "temporary struct" with specific named properties. These properties (parameters) hold data just like the fields in a struct. The function defines the structure, usage, and behavior of this "temporary struct" in the same way that a regular struct does. So, whether you use a struct or function parameters, you're essentially dealing with named properties that store data. The key difference being that you can reuse a struct but you can't reuse the function signature. Really if you have common objects (Person, Woman, Man, Camera, TV, etc) then being able to compose and reuse them makes way more sense than binding them into the signature of a function. That is - it is always going to be better to have a Person struct with name, age, etc properties - and a templ function that accepts a Person versus a templ function that accepts the same value parameters name, age, etc.

[@daniellewis984]

Your argument @2:00 is that JSX should not be the file extension of most of your stuff. JSX/TSX is only meant for dynamically generated HTML, and your normal actual code should not be in JSX/TSX because that is separation of concerns. The fact it's all in JS and you have linguistic unity doesn't mean you can just dump your code all over the place like a shark eating a pig.

[@bencelaszlo666]

JSX sucks and is better than any templating language. The story always goes like this: we made a shiny new backend and now, we have to show its capabilities or just expose a really simple interface for users (TM). Then, a guy called David who also "knows" a Great Templating Language Not Like The Others creates a prototype-like page in Mustache/Pug/Swig/Handlerbar/Twig/Slim/Dust (feel free to replace these with the 99 thousand different template pseudo-languages suitable your language/runtime/environment). Shortly after that the monster starts to grow, there are 10 template files in the repository, then 100 files, then 1000 files, then multiple complete web applications. Nobody (in the best case, maybe David) knows that fucking templating language, and everybody has to suffer the consequences of his terrible decision he made. 29 other developers try to implement new features in a pidgin-style language they don't know, it is now impossible to replace. More and more often, developers find use cases template language developers clearly not thought about. You find yourself writing really strange syntax-mixes, workarounds around workarounds and flying even more desperate tickets to ticketing systems nobody else uses. Debugging is the greatest joy imaginable, the Great Templating Language Not Like The Others simply swallows the error with the hoped output, so you don't need to worry about them. Years later, the Great Templating Language Not Like The Others dies or gets replaced by other. Then first, panic. Present a cold-headed plan to replace templates written in the Great Tempalting Language Not Like The Others with REKTemplate Library. You and your highly motivated team rewrites 30% of the code. Other developers rewrite another 10% just by pure diligence. New features can only be written in REKTemplate Library. 3 years later, nearly half of the templates are still written in the Great Templating Language Not Like The Others. Then REKTemplate Library's only maintainer gets arrested and a guy called David tells about a new template language he just read about on Medium.

[@chepossofare]

I tried an experiment recently where i made simple .html files hydrated with 10 rows of Javascript fetching data from a Go server. Yeah, straight back from 2000. I forgot how simple it was and it is. JSX was a mistake.

[@monad_tcp]

JSX is a mistake. React is a mistake. JS is a mistake. The entire Web development since 2010 was a mistake. Kill everything with fire !

[@monad_tcp]

JS should not even have existed if Browsers in 1995 had CSS3 menus, you wouldn't need JS to open and close menus, think about it . We would be living in the future !

[@jaideepshekhar4621]

@@monad_tcp Wait, how do you open and close menus with css?

[@adventuresinbytes]

This is why go templ library is awesome.

[@ayehavgunne]

I love JSX probably because I just keep it to HTML, ifs and loops. That is it. Anything more and I hoist it out to the plain ol' JS.

[@sirtobey1337]

I disagree. JSX still can be messy, but it‘s just better than templating. Everytime I have to go back to something like Angular it makes me want to cry. If you build simple things, sure, use something like HTMX. But I‘m pretty sure this is going get ugly real quickly with more complicated stuff…

[@user-fr6gw8xr4b]

If I my backend is JavaScript (Node, Bun), I use htmx and my views are simple jsx functional components (no data fetching, state or things like this). For just templating JSX is pretty good

[@theJamieBenShaw]

What library is prime using in his golang template example?

[@theodorealenas3171]

After the XML vs YAML video, I want to try declaring all my UI stuff in some personal XML, to then parse it, so that I don't add bits of code around my HTML but rather compose my HTML (or anything else) using bits of code. Something about inserting code in text bothers me, I want code to return text.

[@sudonim116]

Ooh what if they had something like components using XML for the view layer

[@rand0mtv660]

To be honest I like JSX because compared to string based templating (basically any templating language), IDEs are actually integrated with it and I get a better developer experience. Of course templating in frameworks such as Vue or Svelte has come a long way and bridged the gap since editor integration can offer you autocomplete, safety etc. Only thing I miss in JSX from these templating languages are directives like v-if/v-show and such to easily render or hide an element. Doing conditional rendering in JSX can sometimes be a bit nasty. Even though it's easy, it's not as clean most of the time. Mixing data fetching with JSX is not a JSX feature really and it's React at that point. If you want that as an argument, Svelte is worse offender there because you can literally await promises in HTML markup. Not hating on Svelte by any means since I actually like it so far from my limited time trying it, but just pointing that out.

[@HappyCheeryChap]

Yeah I think the fact that JSX is simply a different syntax to call 1 special JS function ...React.createElement()... must make it so much easier for editor/plugin vendors to handle it. So that means lots of time savings for them... but also means many fewer opportunities for ongoing bugs/quirks they need to deal with in the long term. Most of the parsing bugs were likely already solved long ago in the past for plain JS/TS code. And goes for most future issues too. So this means that for the most part... once the initial work to translate JSX->JS code was written... the JSX support is pretty close to 100% "perfect" as it is for regular JS/TS. With any other templating language... it's much more work to keep up with the template language itself.

[@HappyCheeryChap]

...for me, this was one of the big reasons I switched from Vue -> React... TSX/TypeScript support was basically very close 100% perfect. Whereas the section in .vue files didn't really work with TypeScript code at all. I heard it's improved in Vue since then (although not sure how good in the sections)... but even if Vue was perfect now, I personally like JSX/TSX more.

[@HappyCheeryChap]

When I was coding in Vue, I "felt" like I was writing a hodgepodge of 4 different languages... JS/TS + HTML + CSS + Vue templates. In JSX/TSX... I "feel" like I'm simply writing in one language. This is obviously a very subjective statement about how my own brain works... but for me, less mental context switching has been very valuable in keeping my focus, especially with ADHD.

[@HappyCheeryChap]

And being consciously aware, and reminding myself that "JSX is simply a call to React.createElement()" also greatly helps me with this mental clarity.

[@Hsystem]

Wait until he discover Razor. 😅

[@TheAwesomeDudeGuy]

Your problem seems to be with React, not with JSX.

[@henrybenedict6357]

Elixir and Phoenix are the true saviour

[@lostsauce0]

Debugging performance in React, trying to find that one hook causing your whole tree to re-render fucking SUCKS.

[@aaronevans6442]

You need two different things: 1. An application 2. Components You shouldn't be building an application in your components. React isn't PHP, it's Visual Basic.

[@hrgdavor]

I do not use same stack for web pages and SPA, in SPA JSX is perfect fit for me, it is light years better than any other templating for SPA. I just use JSX without react or angular shit, and with signals, things fit so nicely, no vtree shit.

[@bronzekoala9141]

Gota say I really dig how Angular templates work - especially with the control flow new style in 17.

[@gungun974]

TEMPL is sooooo great.

[@nyashachiroro2531]

Right 😁 I learned about it recently and wondered why I didn't know about it

[@rapzid3536]

JSX is not a template engine. JSX is a "syntax extension to JavaScript". So, of course you can do "anything" with it.

[@goamaral]

To achieve this last bit, where you need a sprinkle of js, I usually fallback to StimulusJS. You basically create a js class with the behavior you need, and it is bound to the html with an attribute.

[@cooltune]

Geezus christ, my eyes. I keep saying this. Use vue with pug syntax templates. No html closing tags. Write html like sass, with just #id's and .classes. No brackets, just python-like indentation. Your templates will be 50% more compact and 100% more structured. Instead of writing : {{thing}} you write this : #MainList.things .thing(v-for="entry in list") {{thing}}

[@hanes2]

vue and svelte, let's go.

[@ea_naseer]

svelte has async keyword and if-else that looks like blade in laravel. Vue is a little more sensible

[@ea_naseer]

svelte has async keyword and if-else that looks like blade in laravel. Vue is a little more sensible

[@hanes2]

@@ea_naseer and nuxt expands on async capabilities which is nice.

[@nomadshiba]

i don't like tsx because it's associated with react and not a js standard. so i don't use it in my projects. but I love how it's just a syntax sugar for a function and you can fully type it just by using typescript. but if you use something like html`` it will not have advanced type safety or you have to create an extension just for your library. that's why tsx is great because you can just type it. wish i was able to use jsx template with .ts files. or wish it was a js standard.

[@siduck_og]

svelte templating looks cool

[@tezismith8795]

Server side rendering removes these problems with JSX if you're thinking in terms of a Model View Controller paradigm

[@Manana7016]

I new to web development and have seen template engines taught. Is it possible to not use them?

[@FraserChapman]

Sure, I mean you can just serve static files if you wish. However once you start reusing components, including common elements, etc. Then they become almost indispensable. Even something as basic as including a common header and footer on multiple pages...

[@Manana7016]

@@FraserChapman I see. So am I understanding correctly that they are required in order to have partials and send data from a database to the page?

[@FraserChapman]

@@Manana7016 Yes that is pretty much it. They are not "required" - it is just they make those processes much easier to do and easier to manage. For example most template systems will allow you to bind data to a template, allow for templates to include other templates, allow for repeating elements, etc.

[@freesoftwareextremist8119]

The Lisppill is a hard and big one to swallow.

[@bs_blackscout]

Templating be like: "Here's a massive Dom unless you overcomplicate everything"

[@keenoogodlike]

Even simple Web Blog can have 20mbs+ at index page because people use Tons of Javascript libraries for static website.

[@camilo5821]

solid 4 the win???

[@tokiomutex4148]

Templating always adds more complexity to your code even when it doesn't seem to

[@F3GR-cx9bh]

I think it's more about setting a strong boundaries on what you should do in jsx, and not. IMHO JSX is *a far better* and more intuitive way of writing html and *a lot* easier to read, but if you should limit yourself to writing basic forEach's, map's, i.e. rendering logic, and attaching events with onEventCallbacks, and *nothing* else.

[@tokiomutex4148]

​@@F3GR-cx9bhIt's not about boundaries, it's about abstraction, choosing the right abstraction is hard and setting boundaries is choosing the wrong abstraction in certain contexts

[@F3GR-cx9bh]

​@@tokiomutex4148 A template is an abstraction as well, and I see no advantages of template over jsx conceptually if you don't abuse jsx capabilities...

[@cesarloyo1747]

how did tmpl word declared and all that?

[@aftalavera]

Got it Prime! As you got older you’ll say fuck Rust , love you Go! Its not pleasure, its business!

[@O_Eduardo]

Thank you... those points you raised are the reason that I hate JSX since always... A good way for me is a simple template system that can do loops and give you a little more power by letting you to use simple js expressions in it. No filters, no functions... That´s the path I´m going with jails-js. Just simple template system with a little dom diffing.

[@michaelhashimoto1650]

I hate the virtual dom. This is why React is a framework & not a library. I guess if it's a library, it's a library that is not interoperable, which.. is inconvenient.

[@attevirtanen271]

You don’t have to maintain the separation of concerns but instead the limitations of the template language keeps you on track. React code is really a mess often, but the ecosystem is huge. JSX is similar to what php files were back in the day.

[@amogus3023]

I thought you liked static type checks. I don't think there's currently a much better option for templating than TSX if you care about them.

[@0dsteel]

developers pre 2000: Let's invent universally used declarative languages to abstract the complexity of UI desing. developers today: We use a new framework that solves a problem the previous framework had. Custom configured build pipeline, we are so modern. What do you mean the problem our previous framework was actually trying to solve does not exist anymore?

[@dave6012]

Front end reactivity would be pretty pointless without some kind of data fetching. Akin to opening devtools and editing the html to display a bad word on the wikipedia homepage.

[@sammymishal5629]

Even though i don't like php, we can't deny that phtml was a good templating option since it's the same language you're already using

[@coolemur976]

React is not a framework, because without additional libraries it is actually a shit.

[@asdqwe4427]

OK so we’re back to thinking that go is the best language ever? Cool. Someone ping me when he’s shifted again.

[@ThePrimeTimeagen]

for practical purposes for most people go is a great middle ground win

[@liningpan7601]

Having typescript type definitions generated from GraphQL queries, and using that to write TSX is not that bad.

[@ShreksSpliff]

Good take 🎉

[@n8o_]

Based and Solid-pilled

[@andybrice2711]

JSX is the #1 thing which made me choose Vue over React. HTML templates may kind-of suck, but functions returning HTML look utterly gross to me.

[@JoeTaber]

5:00 Yo prime, this might change your life, but you can do `{{range $index, $val := $list}}` so it doesn't clobber the dot context `{{.}}`.

[@a-yon_n]

JSX function components without states and hooks are templates. I like Bun prints JSX in HTML style which makes it much more convenient.

[@erickmoya1401]

Svelte is the answer. Svelte is not binding you to their tech, you can easily switch to htmx. While JSX makes it impossible.

[@StingSting844]

The complaints about jsx don't sound accurate. What context? Data fetching? You are talking about react stuff but jsx is just for creating markup

[@florentd.5817]

Adonisjs use jsx templates on the server side.

[@huyoken7953]

I’ve had issues with scope in react and have learned that the more complicated I try to make things and the shorter I try to make my code, the more problems I run in to… it shouldn’t be that way, shorter should be better. but jsx likes to kick you in the balls

[@gabrieljose7041]

Why not use template strings in js? I use it to work with HTMX, works fine and it can have syntax highlight with some extensions. I would like more languages have this feature by the way

[@PacoFerre]

PLEASE, make a video on this topic, why creating a web components library, from scratch, that can work in both Angular and React apps... is a terrible idea. Managers think that MUI, or Angular Material, or similar libraries are easy to develop, with a team of two frontends and some months of work 😂

[@ShaffafAhmed]

jsx combined with pug would be sweet

[@danieldelriodevora9373]

What about Elm

[@joegaffney8006]

Jsx is allot better and easier to read as it uses javascript syntax not some bespoke template flavour syntax. It can get complicated, but so can any code if you don't maintain it.

[@chadbekmezian4806]

What is this package you’re using? I can’t find go templ anywhere. Just the standard library template

[@DanteMishima]

Give this man Vue

[@s4ndeep1203]

he refuses to see it lol

[@dagorgonzoladotco]

Answer: mustache

[@madman777656]

Does anyone know what software he’s using in the beginning of the video to make these flow charts?

[@nomelastname3771]

Dude, I disagree with your "Anything" statement. Actually, for me this is just the opposite. That's what I like about React. The people who created JSX don't need to establish forced standards in the way you should develop. And from there, good practices can emerge and give freedom to make things work that were previously very difficult.

[@JanVerny]

Prime usually has very reasonable takes, but I also can't see the logic here. Half the complaints are that it has many the same properties HTML has (like being top down, but templates really aren't going to be any better at that) and the other half is complaining that it isn't just HTML. My understanding is that he just doesn't want any mixing of UI and logic, but then I don't get why he shills HTMX so much, cause that's complete merging of UI and logic.

[@rapzid3536]

@@JanVerny His take on JSX always ignores the fact that it's not a template engine. Template engines output strings(generally). JSX is a syntax extension to JavaScript. It translate to method calls and results in whatever those methods return. And with React that's NOT strings; it's elements.

[@nofalldamage]

what drawing tool is he using for those diagrams?

[@victornascimento4246]

I like that go comes with a built-in template engine thats really good, but i believe comparing jsx in react and templates is the same of comparing oranges and lemons Would be fair to compare go templates with something like handlebars or ejs Almost all logic used in examples would be the same with a backend but I see it feels simpler because after all go is simpler than a frontend framework xD Angular for example can be very annoying too and doesnt use jsx

[@ple7y]

Blade for PHP works perfectly for me...

[@madsxcva]

does anyone know what package is he using to achieve this?