CORRECTIONS: 8:04: Tailwind via script tag is "designed for development purposes only, and is not the best choice for production" I HAVE UPDATED THE GITHUB REPO WITH A PROPER TAILWIND IMPLEMENTATION- basically uses the tailwind cli to generate a output css file and serves it for the main page to have a link tag to, also added a dev script for automatic rebuilding on changes OTHER STYLING OPTIONS: Obviously there are lots of styling libraries out there. Feel free to pick whatever one works the best for you. I have added examples using twind and uno (both do not require a cli step) as branches in the repo if your curious what that might look like.
Starts with "tired of all the chaos in frontend dev" Proceeds to suggest using 4 super bleeding edge tools 😅 And here I thought I was an early adopter hipster programmer! ---- Jokes aside, some interesting things in here. Not really for me (I'm a SvelteKit groupie) but some cool approaches nonetheless.
First, this is super cool and a very creative stack using these technologies, but we've basically come full circle back to full server-side rendering but with serverless. I don't see this being any simpler or more complicated than other options, it just makes it look like the data to html translation is getting cut out when it's really just being abstracted away. And yeah, wow, the speed of bun and these frameworks, I can definitely see the appeal of rendering on the backend for consistent page load speeds, especially with caching strategies (memcache) using a functional programming paradigm. This will give us a lot to think about. I'm interested in seeing the pros/cons pan out on this one. At a minimum, I think this will lead to other innovations and trends for web development.
He overcomplicated the backend, but you can have very simple and productive setup with HTMX. Besides the simplicity, you get very good performance, compatibility, SEO and cacheability. Using templates in the backend allow you to use variables in the CSS, HTML and JS freely :)
In my opinion if you are already using a Bun stack then go ahead and use a client side framework like React or Solid if you want more performance. It will make your life easier if you need to maintain local state in a component. Going to the server to collapse/uncollapse an accordion or display a modal, to me feels like an overkill and without a framework is way harder to maintain in the browser. You can implement Server components to only load javascript to the components that you need and do all server operations with React as well if you want to have the backend state philosophy as a priority.
@@AhoyThereinteresting. What about mobile app devs who use Swift or Kotlin? They’re expecting JSON and now they’re getting HTML/XML. Or IoT devices like smart TVs or smart fridges?
We're going back to the old PHP days. I was there. It was hell. Frameworks like Next, Remix, Astro etc. are popular for a reason and throwing out hydration and a JS UI library in a modern web app looks nice on paper but it's a very bad move that will cost you a lot down the road. Also, start thinking about extreme edge cases, large refactors, auth etc. It can get very painful very fast. It looks nice but it's not fitting for all use cases. Don't trust the hype, the real tech stack you need is always different and will always depend on the specific requirements of the project. Performance is cool, less JS is cool but in the end we should be focused on building things not overthinking them into existence. BTW this is a nice video and it was extremely informative and easy to watch.
It was an interesting look into the bleeding edge, and I want to like it, but in the end this is as complicated as installing most frameworks with most ORM:s and most databases. I'm sure it will be fast, though speed issues, when disregarding bad coding, is a luxury problem that most sites won't have. It's also amusing (in general, not just to this stack) that type safety seems so important on one hand, but on the other hand, inline string-based DSL:s are happily being used, with Tailwind and htmx/hyperscript, at best semi-statically type checked by VS Code extensions. The most straightforward way I've found to develop web apps today is SvelteKit, which replaces most of the libraries in the first 12 minutes of the video with a single npm command. (It has an experimental bun adapter as well.)
Yeah.. definitely seems a little half-baked. I was thinking that you may as well skip drizzle and just use raw sql strings with bun:sqlite, since you're missing type safety in so many other places
Your videos are above and beyond! Exceptionally pedagogical, and always adressing the cutting edge! I hadn’t even thought about this unique stack before! Instant sub!
That was incredibly cool! I'm going to build your demo this weekend. I keep wanting a off the React treadmill, and this felt really clean and full of potential.
i started with web dev 22 years, went into a the backend role for now and stopped frontend when react started going big. and as i can see nothing has changed lol. ive implemented my own htmx 20 years ago, always wanted purly functional clients with my own html elements. my syntax looked like m stood for my. you could also just define etc. i really believe every js programmer reinvents the wheel over and over again. back then it was considered bad practice to have your own html elements.
That's smell the noob. Django is a Web framework for Python. All the languages you said are backend. And I don't get the point of your comment with his video.
Chill guys I am not talking about the framework.. I don't care what framework you use. The end goal should be useful product which solves the business problems not chasing shinny objects for business problems.I was specifically talking about the model view controller based technology where you have simple html,css and Js in one framework itself.. as you get experience you understand that business care about money not you framework... make it work make it cheap and give a good experience that's it...
I was out of the web dev world for most of the JS garbage meme era. I got back to inherit a React project 18 months ago, and it was... deeply unpleasant. Not only because it was a junior dev's first React project that had never been rewritten or well maintained, but also because it was React. 😂 I have an upcoming greenfield project, and htmx swoops in from nowhere like some sort of guardian angel. If I were a religious man, I'd be praising somebody right now.
I finally got over my personal hurdle of not wanting to use Django. It's good. Flask is good too, but I'm not sure why I'd ever choose it instead when I can use Django Rest Framework. Type annotation and IDE integration is the future of typing btw. I started programming 15 years ago, typing used to be a thing necessary for the compiler to function, knowing how much memory to reserve, etc.
Definitely an interesting approach for small scale apps and personal projects Can't see how this simplifies anything Also having a hard time seeing this approach working out for large scale rich user experiences
Honestly. Most people in the bleeding edge web space keep peddling the latest framework. But, in a lot of cases, huge codebases are written and continue to be maintained in freaking JQuery (whiplash yet?) and the best case scenario would be to spend hundreds of dev hours and resources porting it to a more stable and clean solution.
@@avid459can you not see the tight coupling between backend and frontend and how that would be harder to scale to multiple different clients. What do you do when you have to add mobile and tv clients, you know something applications with large user bases usually do.
It’s component-based, allowing you to structure the directory like Angular, Next.js, Nuxt.js, or any enterprise app architecture, including clean code/clean architecture. Everything becomes a functional component, and I can simplify it without a service layer or include one for more DDD/TDD approach projects. Essentially, it streamlines full-stack development with the latest technologies and tooling. It’s ideal for small to medium teams of full-stack developers with a UI/UX designer using Figma. Since the components are standard HTML/CSS/JS, you can also set up Storybook to document them using data from a development/stagging database. This enables UI/UX and business processes to be integrated into manageable scenarios, allowing stakeholders to test and document everything on a single platform. It can also be easily extended to incorporate frontend/backend microservices, thanks to the existing tooling, which leverages edge computing as demonstrated in the video. Because the backend and frontend are unified, you can structure the repository as a monorepo with a straightforward layout, making it suitable for full-stack teams of developers.
Awesome intro to the... erm, BETH stack 😮 😄 Great use of bun.js and some of the other tools. Going to give these a try. Looking forward to your other videos.
Been on the sidelines on tech news, this was a great overview of some of the new tech. Great to see how tailwind slots into htmx and the recent bun announcement - great content 💯
htmx is a great tool to go with when your goal is to show tons of data, like thousands of rows or cards and to avoid using react virtualisation. But, on the other side, doing some complex forms with dynamically added fields would be worse DX than react-hook-form. Anyway, thanks for sharing your stack.
@@CamaradaArdi ye... no, switching files is not a workflow problem and you don't need vim to be a better developer. It's more of a separation of concerns issue. Grouping by "what it does" rather than "what it is" is usually much preferred. That's why we have JSX, that's why people enjoy using CSS-in-JS or tailwind, that's why frontend frameworks use single file for component that includes script, styles and template, and so on. And about the original comment, in the end, all templates are tightly coupled with the code, so the argument of switching them out without changing code doesn't make much sense to me.
@@BrotWurst because I can go to the file that I want in a fraction of a second pressing 2 keys. That's much much much faster than navigating the same file.
This idea with Hono instead of Eylsia is awesome. Hono has built in support for jsx and way fewer bugs. Love this idea though. Rebuilding some production apps with it already.
thanks for the comment. Hono looks really cool, good examples and as you mentioned built-in JSX support. Did you use Bun for the runtime or what would you recommend for production?
Awesome video, i love the way you explain all the components in the stacks, especially the htmx part. As a React Typescript enjoyer, I'm very excited to see where the future of webdev is heading. Keep it up bro ^^
This is interesting but I think DX suffers a lot the moment you start having multiple pages. Also doing CSR means it's going to be slow on first pageload. I honestly don't see any advantages over something like Sveltekit, which gives you the familiar html-like templating while still having everything you would need in a modern web development.
@@RudraSingh-pb5ls Couple reasons. Because their apps were made 10+ years ago. It's the only framework their devs know. They don't want to introduce something new into the stack, better have everything be Angular, Java since that's what they commited to a long time ago.
Great video. Interesting take on the separation of code and templates. As a MVC user I can't stand the idea of putting my logic in templates 😂. Having a separate controller (logic) and view/template (html) for each HTMX endpoint/fragment is an amazing workflow. In the end, just do whatever works for you.
I've been doing web dev for over 20 years, and it took a while to get to a point where 'separation of concerns' became something desired, instead of doing stuff quickly. I see JSX and it makes me cry.
You can make the FE server be a client that calls another BE server which houses the logic. Just like what a React app does, but it's server side & no(or less) javascript sent to the user's browser
he made everything in a single file. but it doesnt mean this is how it should be. he could have created a controllers folder, routes file, components folder...
This video is so useful and full of information, thanks a lot man. I had no idea I can activate Tailwindcss extension just by adding the config file and still using it from cdn.
I would choose Hono over Elysia: - out-of-the-box JSX support. - many runtimes supported (CFW, Deno, Bun, AWS Lambda, etc). (edit - no downsides I could think of for a stack like this one. Type safety is really good with Hono too) Then it would just be called the H stack :)
@@Christopher-lx4udjust use less or scss then: my-component-name { .class or anything css rule { } } No need to do black magic like shadow dom or compiled component css style.
2:52 Interesting point since I personally think you should keep your templates and "business logic" separated especially since I had to work with both front-end and back-end. Keeps things very nice and tidy.
For sure, that thought is 100% personal preference. If you like the separation then for sure stick with temptations libraries that allow you that experience.
"If you are tired of framework chaos today" - i present you another 10 frameworks lol. Thx but no, i'll stick with react, nowadays it's one thing that is stable and proven in a frontend world, we need to preserve it to not fall again in hell of 100 obscure frameworks appearing everyday.
@@Pismice Oh I should be more clear. I said it is PHP with extra steps because You have a lot of bloat over your server side templates. Back in the day in PHP You had first class support for just echoing or embedding HTML. Like PHP doesn't give a fk. Just open a PHP Tag in the middle of your html, echo your server side variable, and you are good. Nowadays this is just templating but waaay more complicated and installing a bunch of stuff and then bundle the thing and it's just worthlessly complicated. Can we just go back to PHP for semi-dynamic websites please. it's templating we know templating we've been doing it for decades now.
@@Pismice As much as I dislike PHP's syntax the two strongest points for PHP are: EXTREMELY clear documentation and exceptional HTML templating. Why would you try to reinvent a worse versión of that.
I love the idea!!! The way you've combined the tools to make a stack is pure class. But doesn't htmx feel very imperative? Handling DOM operations by manually selecting DOM nodes can be bit of a hassle.
Htmx is a great option for certain kinds of apps where working with the dom imperatively is manageable, but for more complex, or highly interactive apps even the htmx authors recommend sticking with a js framework See: htmx.org/essays/when-to-use-hypermedia/
great video, there's a lot of people talking vaguely about htmx so appreciate the proper work and detail behind this. i dont know why im so drawn to htmx. what do you think of using astro with htmx? astro routes already let you return html, using astro components & SSR, and its also really pwoerful and lightweight. a lot of people here talking about DX, and to me astro + htmx with some work put into it and squinting could turn out a little like remix. PLUS it would allow the flexibility to sprinkle in some svelte + preact components where relevant
It looks very performent, however I can't understand if does this allow for more complex JS logic for components? Currently I use react and have a ton of useEffects, where many states are dependant on each other. Would it be possible also here? If so, how?
I think you can easily copy style from angular, nuxt, or nextjs easily without using black magic like those framework. Just plain old import with sensible folder structure, either using feature style or module style and shared component folder.
What I don't like about the HTMX approach is the return value from the BE is HTML, HTML markup is FE concern not BE. The BE should return data models , not markup, otherwise it's a violation of the Single Responsibility Principle.
This complete techstack is a violation of principles and design patterns. - no loose coupling - no separation of concerns - no modularity - .... It does have high cohesion, which is nice.
I love the idea of HTMX but I feel like it just can't be used outside of toy projects. Really interesting stack though and would love to see more ideas around improving devex! I think the main pain point HTMX is trying to solve is the DB->JSON->JS->HTML pipeline is too long. PHP does solve this, but then of course you're writing PHP. What I've been doing is using react + redux toolkit and redux's codegen to automatically generate an API client from my backend, which is running on django ninja + swagger. That cuts out a lot of the glue code writing, and gets me closer to that DB->HTML experience.
There are two things that really sold me on htmx one was the idea that there is a problem with maintaining two distinct states in modern apps. One on the server and one on the client. Htmx pushes everything to the server and really simplifies that. The other was a talk from djangocon 2022 where a guy talked about his multi man team switching a large product to htmx and demonstrates how they solved things that seem like they would break htmx.
I liked it, although it seems nuts to already be using typescript/jsx but decide to reach for htmx/hyperscript, forgoing all type-safety/static-anaylsis you could've just had via react.
@@spectr__ if you like your codebase to look like a favela sure, it's better than react. This thing is serving raw components with inline styles, it's virtually unscalable and would require immense documentation to pass on the project to another team
Curious to see how that elysium route setup scales… obviously putting all your routes and logic in one file is not a good dx, but I don’t see how you can separate that out. Export the elysium instance and decorate it with new handlers and re-export? I has the confusion
You should use whatever makes the most sense for you. There’s no need to constantly be rewriting your app to the newest trendiest stack unless you have a real reason for doing so.
@@ethanniser yeah you right recently I switched from NextJs to svelte because NextJs issues cache performance etc... / Reactjs ( long code to do simple things.. you know) From pure Js To PHP To Laravel To angular To vuejs To reactjs To NextJs To svelte kit Now I think will just try it after completing the svelte kit will see 😃 But it looks the new stack is hot 🔥
SHIT, this stack combines a bunch of different things I've been wanting to use. Bun, Elysia, Turso and HTMX. Damn. Literally have no choice but use this stack in my next app.
Love this vid. But it's aalso nice to mention tat bun is still very experimental. I tried working on a project with it like 2 days ago vut couldn't get it working (cos of some bun specific error). There's also the fact that most popular libraries don't interop with bun 😢. But besides that, your stack looks really interesting and i think ill try it out 😃
interesting stack but still prefer sveltkit, the script template style method does a better job than putting everything on the server, better view and dx especially when debugging and working in a team
Interesting video, but as far as I'm concerned, getting JSON from the API is a feature, not a bug. This approach tightly couples the API to the FE, which reduces testability and the ability to compose APIs or use different API endpoints into a single app. The stack components look v. interesting though. Thank you for making this video and I'll definitely check out Bun, Elysia, Turso and hyperscript.
The backend can offer json or htmx depending on the request mimetype if you wanted to support both. Just extra work for the backend at the router layer and presentation layer.
@ethanniser Do you believe this is the perfect frontend stack for 2024? I mean, if I am starting with frontend development, should I go for the BETH stack straight away?
even without rust, is too blazingly fast. I will consider the BETH stack in future projects and all know Bun when reach v1.0 it will break node and deno. Greetings from mexico, new to your channel
I'm not a fan of the HTMX paradigm and am still too attached to express to even consider Elysia, hopefully some time soon. This video, however, was amazing and you just gained a new subscriber
I feel like my first response to watching this new all different stacks is just rejecting, but then I think "If i'm rejecting i'm biased and I should give it a try to understand", but then If I still don't like it I keep thinking "am I still just rejecting cause it's new?"
CORRECTIONS:
8:04: Tailwind via script tag is "designed for development purposes only, and is not the best choice for production"
I HAVE UPDATED THE GITHUB REPO WITH A PROPER TAILWIND IMPLEMENTATION- basically uses the tailwind cli to generate a output css file and serves it for the main page to have a link tag to, also added a dev script for automatic rebuilding on changes
OTHER STYLING OPTIONS: Obviously there are lots of styling libraries out there. Feel free to pick whatever one works the best for you.
I have added examples using twind and uno (both do not require a cli step) as branches in the repo if your curious what that might look like.
Ill give a recommendation here. Swap Tailwind with UNO. Its designed to also work from CDN with insane speeds 10x faster than tailwind.
unocss is better
Thanks for the suggestion, I have updated the comment + added a unocss branch to the repo
One small thing, you said Bun was only available on Linux, but it runs on Mac as well. Maybe you meant Unix-like systems?
Great video btw
Nop, i didnt like it. json must have for green planet :) If i had 1000 rows, this htmx just increase package size about 100x idk maybe more
M: Moddable SDK
E: Elysia
T: Turso
H: Htmx
Starts with "tired of all the chaos in frontend dev"
Proceeds to suggest using 4 super bleeding edge tools 😅
And here I thought I was an early adopter hipster programmer!
----
Jokes aside, some interesting things in here. Not really for me (I'm a SvelteKit groupie) but some cool approaches nonetheless.
First, this is super cool and a very creative stack using these technologies, but we've basically come full circle back to full server-side rendering but with serverless. I don't see this being any simpler or more complicated than other options, it just makes it look like the data to html translation is getting cut out when it's really just being abstracted away. And yeah, wow, the speed of bun and these frameworks, I can definitely see the appeal of rendering on the backend for consistent page load speeds, especially with caching strategies (memcache) using a functional programming paradigm.
This will give us a lot to think about. I'm interested in seeing the pros/cons pan out on this one. At a minimum, I think this will lead to other innovations and trends for web development.
He overcomplicated the backend, but you can have very simple and productive setup with HTMX.
Besides the simplicity, you get very good performance, compatibility, SEO and cacheability.
Using templates in the backend allow you to use variables in the CSS, HTML and JS freely :)
In my opinion if you are already using a Bun stack then go ahead and use a client side framework like React or Solid if you want more performance. It will make your life easier if you need to maintain local state in a component. Going to the server to collapse/uncollapse an accordion or display a modal, to me feels like an overkill and without a framework is way harder to maintain in the browser.
You can implement Server components to only load javascript to the components that you need and do all server operations with React as well if you want to have the backend state philosophy as a priority.
memcache? If it's servless as you say you should take advantage of standard http cache headers and strategies
Good to see No Boilerplate inspired youtubers propping up
Wait no I’m the person who made a UA-cam channel then a tech stack and got prime’s attention
:)
Still this is lighter than t3
I would think social engineering if it wasn't for the vscode
Shut up Theo, mans got retweet from the owner of Bun.
Honestly you have to spend more time to the ww comunity and @ethanniser created good content no prime no fireship no T3 this is new yummy 😋
I love how his almost writing React Server Componentes without writing React Server Components 😂
And not 5 second hot reload times 😂
What makes it better
I like this approach, it looks very clean and easy to understand. In your opinion what would be another way to write this?
@@AhoyThereinteresting. What about mobile app devs who use Swift or Kotlin? They’re expecting JSON and now they’re getting HTML/XML. Or IoT devices like smart TVs or smart fridges?
@@mango4199 I think that wasm can be good to use in mobile apps but can be hard
Maaaan! This is really awesome! I don't remember the last time I felt so exited about development like I'm now, this approach have much potential!
We're going back to the old PHP days. I was there. It was hell.
Frameworks like Next, Remix, Astro etc. are popular for a reason and throwing out hydration and a JS UI library in a modern web app looks nice on paper but it's a very bad move that will cost you a lot down the road. Also, start thinking about extreme edge cases, large refactors, auth etc. It can get very painful very fast. It looks nice but it's not fitting for all use cases.
Don't trust the hype, the real tech stack you need is always different and will always depend on the specific requirements of the project.
Performance is cool, less JS is cool but in the end we should be focused on building things not overthinking them into existence.
BTW this is a nice video and it was extremely informative and easy to watch.
It was an interesting look into the bleeding edge, and I want to like it, but in the end this is as complicated as installing most frameworks with most ORM:s and most databases.
I'm sure it will be fast, though speed issues, when disregarding bad coding, is a luxury problem that most sites won't have.
It's also amusing (in general, not just to this stack) that type safety seems so important on one hand, but on the other hand, inline string-based DSL:s are happily being used, with Tailwind and htmx/hyperscript, at best semi-statically type checked by VS Code extensions.
The most straightforward way I've found to develop web apps today is SvelteKit, which replaces most of the libraries in the first 12 minutes of the video with a single npm command. (It has an experimental bun adapter as well.)
Yeah.. definitely seems a little half-baked. I was thinking that you may as well skip drizzle and just use raw sql strings with bun:sqlite, since you're missing type safety in so many other places
Your videos are above and beyond! Exceptionally pedagogical, and always adressing the cutting edge! I hadn’t even thought about this unique stack before! Instant sub!
That was incredibly cool! I'm going to build your demo this weekend. I keep wanting a off the React treadmill, and this felt really clean and full of potential.
i started with web dev 22 years, went into a the backend role for now and stopped frontend when react started going big. and as i can see nothing has changed lol. ive implemented my own htmx 20 years ago, always wanted purly functional clients with my own html elements.
my syntax looked like m stood for my.
you could also just define etc. i really believe every js programmer reinvents the wheel over and over again. back then it was considered bad practice to have your own html elements.
I've done the same thing 3 ago with jQuery, replaced parts of HTML with responses from backend
Fffffff... Crazy good....! Keep produce content with BETH stack. I want to know more. Thank you
After this i can say that we will be using django, java and php again as a full stack project.😊
All 3 of those are backend languahes/frameworks...
@@khuntasaurus88so what about a js framework that is a backend framework but is a frontend framework??
That's smell the noob.
Django is a Web framework for Python.
All the languages you said are backend.
And I don't get the point of your comment with his video.
Chill guys I am not talking about the framework.. I don't care what framework you use. The end goal should be useful product which solves the business problems not chasing shinny objects for business problems.I was specifically talking about the model view controller based technology where you have simple html,css and Js in one framework itself.. as you get experience you understand that business care about money not you framework... make it work make it cheap and give a good experience that's it...
You can do similar with Livewire or Blazor, but livewire is more like this.
Really love where the js ecosystem is headed. Its like waking up from a hangover from all the unneeded complexity and crap performance.
As a backend dev, the js landscape is scary
@@Mkrabs 😂
@@MkrabsAs a backend Dev one should just stay away from JS, we're stuck with it on the frontend but not on the backend
I was out of the web dev world for most of the JS garbage meme era. I got back to inherit a React project 18 months ago, and it was... deeply unpleasant. Not only because it was a junior dev's first React project that had never been rewritten or well maintained, but also because it was React. 😂 I have an upcoming greenfield project, and htmx swoops in from nowhere like some sort of guardian angel. If I were a religious man, I'd be praising somebody right now.
I finally got over my personal hurdle of not wanting to use Django. It's good. Flask is good too, but I'm not sure why I'd ever choose it instead when I can use Django Rest Framework.
Type annotation and IDE integration is the future of typing btw. I started programming 15 years ago, typing used to be a thing necessary for the compiler to function, knowing how much memory to reserve, etc.
Amazing video! I’ve been wanting to test htmx, I’ll give it a try with the tools you mentionned!
Definitely an interesting approach for small scale apps and personal projects
Can't see how this simplifies anything
Also having a hard time seeing this approach working out for large scale rich user experiences
I had the same thought about this, a more complex app may turn into a nightmare to maintain
Look ma, It only works for simple apps comment by react devs 🤦♂️
Honestly. Most people in the bleeding edge web space keep peddling the latest framework. But, in a lot of cases, huge codebases are written and continue to be maintained in freaking JQuery (whiplash yet?) and the best case scenario would be to spend hundreds of dev hours and resources porting it to a more stable and clean solution.
@@avid459can you not see the tight coupling between backend and frontend and how that would be harder to scale to multiple different clients. What do you do when you have to add mobile and tv clients, you know something applications with large user bases usually do.
It’s component-based, allowing you to structure the directory like Angular, Next.js, Nuxt.js, or any enterprise app architecture, including clean code/clean architecture.
Everything becomes a functional component, and I can simplify it without a service layer or include one for more DDD/TDD approach projects. Essentially, it streamlines full-stack development with the latest technologies and tooling. It’s ideal for small to medium teams of full-stack developers with a UI/UX designer using Figma.
Since the components are standard HTML/CSS/JS, you can also set up Storybook to document them using data from a development/stagging database. This enables UI/UX and business processes to be integrated into manageable scenarios, allowing stakeholders to test and document everything on a single platform.
It can also be easily extended to incorporate frontend/backend microservices, thanks to the existing tooling, which leverages edge computing as demonstrated in the video. Because the backend and frontend are unified, you can structure the repository as a monorepo with a straightforward layout, making it suitable for full-stack teams of developers.
Syntax looks terrifying, the PHP nightmare is returning with a new power
thank you so much for the effort in making this video. I had a blast watching it.
Awesome intro to the... erm, BETH stack 😮 😄
Great use of bun.js and some of the other tools. Going to give these a try. Looking forward to your other videos.
Been on the sidelines on tech news, this was a great overview of some of the new tech. Great to see how tailwind slots into htmx and the recent bun announcement - great content 💯
htmx is a great tool to go with when your goal is to show tons of data, like thousands of rows or cards and to avoid using react virtualisation. But, on the other side, doing some complex forms with dynamically added fields would be worse DX than react-hook-form. Anyway, thanks for sharing your stack.
what no
What, yes
As a frontend webapp developer, the thought of trying to do anything semi-complex in htmx makes me shudder.
@pebcak you don't get it old man, these junior devs and their blazing fast todo apps are the future
Wow I am really thrilled to see so many cool tutorials being put out! Great content Ethan :)
This is cutting edge stack as it gets
Cutting edge like early Y2K. I didn't hate hypermedia the first time around so I have no complaints this time either.
The templates being in completely separate file is exactly what makes them great, you can switch out templates without having to change any code
There’s for sure pros and cons. If you prefer separate file templates you can still use them with htmx.
@@ethanniserif having to switch files is bad for you then you need a better workflow (learn vim)
@@CamaradaArdi how does your IDE effects the separation of you project files? even if you can switch ultra fast, it still has pros and cons.
@@CamaradaArdi ye... no, switching files is not a workflow problem and you don't need vim to be a better developer. It's more of a separation of concerns issue. Grouping by "what it does" rather than "what it is" is usually much preferred. That's why we have JSX, that's why people enjoy using CSS-in-JS or tailwind, that's why frontend frameworks use single file for component that includes script, styles and template, and so on. And about the original comment, in the end, all templates are tightly coupled with the code, so the argument of switching them out without changing code doesn't make much sense to me.
@@BrotWurst because I can go to the file that I want in a fraction of a second pressing 2 keys. That's much much much faster than navigating the same file.
make sure to check off your todo for "learn vim" next
still working on that one lol
omg it's tj the friend of rusteagen!
This idea with Hono instead of Eylsia is awesome. Hono has built in support for jsx and way fewer bugs. Love this idea though. Rebuilding some production apps with it already.
thanks for the comment. Hono looks really cool, good examples and as you mentioned built-in JSX support. Did you use Bun for the runtime or what would you recommend for production?
Blazingly bleeding edge stack. Definitely trying this😂
This effectively fulfils my dream of power of an entire website in one file.
Awesome video, i love the way you explain all the components in the stacks, especially the htmx part. As a React Typescript enjoyer, I'm very excited to see where the future of webdev is heading. Keep it up bro ^^
This is interesting but I think DX suffers a lot the moment you start having multiple pages. Also doing CSR means it's going to be slow on first pageload.
I honestly don't see any advantages over something like Sveltekit, which gives you the familiar html-like templating while still having everything you would need in a modern web development.
Can it be used at enterprise level ? Why do they still use Angular at big corporations ?
@@RudraSingh-pb5lswhy do they still use Java at banks?
@@KManAbout man i m asking the same thing
@@RudraSingh-pb5ls Couple reasons. Because their apps were made 10+ years ago. It's the only framework their devs know. They don't want to introduce something new into the stack, better have everything be Angular, Java since that's what they commited to a long time ago.
@@gileee I worked for the UK government and could only dream of Angular and Java - I was stuck with VBA 😢
pretty exciting, great video!
you can already tell he's on his way to hundreds of thousands of subs.
Beth stack: "Aww... How sweet ❤"
PHP: "Hello human resources!! 🤢"
Why can I not set completed to true for the "learn vim" item? I've tried for over a decade now.
This is amazing, I noticed that the REPO has Lucia auth now, is there a continuation of the tut?
Great video. Interesting take on the separation of code and templates. As a MVC user I can't stand the idea of putting my logic in templates 😂. Having a separate controller (logic) and view/template (html) for each HTMX endpoint/fragment is an amazing workflow. In the end, just do whatever works for you.
I've been doing web dev for over 20 years, and it took a while to get to a point where 'separation of concerns' became something desired, instead of doing stuff quickly. I see JSX and it makes me cry.
In some ways it's cool, in others I absolutely hate having mixed backend and frontend. I can't see how multiple people would do a project this way.
No different from having multiple frontend devs working on a frontend or multiple backend devs working on a backend
You can make the FE server be a client that calls another BE server which houses the logic. Just like what a React app does, but it's server side & no(or less) javascript sent to the user's browser
he made everything in a single file. but it doesnt mean this is how it should be. he could have created a controllers folder, routes file, components folder...
Monorepo
This video is so useful and full of information, thanks a lot man.
I had no idea I can activate Tailwindcss extension just by adding the config file and still using it from cdn.
Please check the pinned comment, this way is not meant for production.
I would choose Hono over Elysia:
- out-of-the-box JSX support.
- many runtimes supported (CFW, Deno, Bun, AWS Lambda, etc).
(edit - no downsides I could think of for a stack like this one. Type safety is really good with Hono too)
Then it would just be called the H stack :)
But then it doesn't make a catchy title!!11!!1! HTBH
@jacoblockwood4034 Thank you for understanding lol
How would one add component styling using css-in-js concepts? Like styled-compnents?
@@Christopher-lx4ud One wouldn't.
@@Christopher-lx4udjust use less or scss then:
my-component-name {
.class or anything css rule {
}
}
No need to do black magic like shadow dom or compiled component css style.
Beautiful, thank you Ethan
2:52 Interesting point since I personally think you should keep your templates and "business logic" separated especially since I had to work with both front-end and back-end.
Keeps things very nice and tidy.
For sure, that thought is 100% personal preference. If you like the separation then for sure stick with temptations libraries that allow you that experience.
This is crazy powerful, omggggg.
"If you are tired of framework chaos today" - i present you another 10 frameworks lol. Thx but no, i'll stick with react, nowadays it's one thing that is stable and proven in a frontend world, we need to preserve it to not fall again in hell of 100 obscure frameworks appearing everyday.
I mean I hate react as much as the next guy, but this looks so painful, it's PHP with extra steps.
What does it have to do with php ?
@@Pismice Oh I should be more clear. I said it is PHP with extra steps because You have a lot of bloat over your server side templates. Back in the day in PHP You had first class support for just echoing or embedding HTML. Like PHP doesn't give a fk. Just open a PHP Tag in the middle of your html, echo your server side variable, and you are good. Nowadays this is just templating but waaay more complicated and installing a bunch of stuff and then bundle the thing and it's just worthlessly complicated. Can we just go back to PHP for semi-dynamic websites please. it's templating we know templating we've been doing it for decades now.
@@Pismice As much as I dislike PHP's syntax the two strongest points for PHP are: EXTREMELY clear documentation and exceptional HTML templating. Why would you try to reinvent a worse versión of that.
I was literally testing out Elysia yesterday
I love the idea!!! The way you've combined the tools to make a stack is pure class. But doesn't htmx feel very imperative? Handling DOM operations by manually selecting DOM nodes can be bit of a hassle.
Htmx is a great option for certain kinds of apps where working with the dom imperatively is manageable, but for more complex, or highly interactive apps even the htmx authors recommend sticking with a js framework
See: htmx.org/essays/when-to-use-hypermedia/
@@ethanniser Great! thanks for sharing the article! Looking forward to more videos!
great video, there's a lot of people talking vaguely about htmx so appreciate the proper work and detail behind this.
i dont know why im so drawn to htmx.
what do you think of using astro with htmx? astro routes already let you return html, using astro components & SSR, and its also really pwoerful and lightweight.
a lot of people here talking about DX, and to me astro + htmx with some work put into it and squinting could turn out a little like remix.
PLUS it would allow the flexibility to sprinkle in some svelte + preact components where relevant
0:10 had heard write time complexity, but never the DX Developer Experience before.
Me ha sorprendido que he podido seguir la explicación perfectamente. Si sabes Express y React (y Tailwind) es perfecto.
I love this a lot....especially the Acronym
Alternative names:
Segfault stack
Unemployed stack
this type of content should ideally be in a blog format for easier reading
It looks very performent, however I can't understand if does this allow for more complex JS logic for components? Currently I use react and have a ton of useEffects, where many states are dependant on each other. Would it be possible also here? If so, how?
I expected memes about htmx and milk, but what I got was pretty cool stack
milk?
@@ethanniserhtmx memed about milk on Twitter for some reason, so now I just associate the two lol
Can you do a video on websockets using the htmx and Elysia?
Your content quality is 😍🤩 love to see more videos from you
Ssr app in highly performant bun runtime with htmx to handle dom updates from the server. Very nice
cool stuff, but could you also tell us about proper folder structure / design pattern with this stack for mid size project?
I think you can easily copy style from angular, nuxt, or nextjs easily without using black magic like those framework. Just plain old import with sensible folder structure, either using feature style or module style and shared component folder.
🔥This video is a HOMERUN. You've got a new subscriber. Thanks! 🔥
@6:19 no coloring or LSP highlighting for HTML?
It's just a base html to populate and load scripts into, you don't write your components that way. JSX has all the highlighting.
Great video! Some interesting takes.
HARMfull stack‼️ Htmx Axum Rust Minijinja
Great vid ever!!
Tks for sharing 🎉🎉🎉
I'm stuck here 6:38. this is the text in the html
html is not a function. (In 'html(baseHTML)', 'html' is undefined
Very cool, and really well presented 👏
Awesome content, man! I like it. But I didn’t quite get how that error that you throw “Content cannot be empty” from the /todos route is handled ?
This is cool but how well does this scale?
What I don't like about the HTMX approach is the return value from the BE is HTML, HTML markup is FE concern not BE. The BE should return data models , not markup, otherwise it's a violation of the Single Responsibility Principle.
This complete techstack is a violation of principles and design patterns.
- no loose coupling
- no separation of concerns
- no modularity
- ....
It does have high cohesion, which is nice.
@@mltsv it's weird, I mean it's nice to work with but from a design standpoint is bad
Nicely presented, and I got some TIL's. +1 sub!
I love the idea of HTMX but I feel like it just can't be used outside of toy projects. Really interesting stack though and would love to see more ideas around improving devex!
I think the main pain point HTMX is trying to solve is the DB->JSON->JS->HTML pipeline is too long. PHP does solve this, but then of course you're writing PHP.
What I've been doing is using react + redux toolkit and redux's codegen to automatically generate an API client from my backend, which is running on django ninja + swagger. That cuts out a lot of the glue code writing, and gets me closer to that DB->HTML experience.
There are two things that really sold me on htmx one was the idea that there is a problem with maintaining two distinct states in modern apps. One on the server and one on the client. Htmx pushes everything to the server and really simplifies that. The other was a talk from djangocon 2022 where a guy talked about his multi man team switching a large product to htmx and demonstrates how they solved things that seem like they would break htmx.
so now we’re back to the server doing the heavy lifting…. interesting
Great video 🔥🔥... Keep it up
I liked it, although it seems nuts to already be using typescript/jsx but decide to reach for htmx/hyperscript, forgoing all type-safety/static-anaylsis you could've just had via react.
Looks fun to use this stack in a side project. But I can't imagine using it in real world projects. It will be horrible for sure.
Not disagreeing, but htmx believes otherwise, check out htmx.org/essays/a-real-world-react-to-htmx-port/
Why?
Why would it be horrible? It's leagues better than anything React.
This intrigued me, could you elaborate on why? (genuinely asking)
@@spectr__ if you like your codebase to look like a favela sure, it's better than react.
This thing is serving raw components with inline styles, it's virtually unscalable and would require immense documentation to pass on the project to another team
Everytime I see htmx I feel like its just reiventing the wheel all over
Curious to see how that elysium route setup scales… obviously putting all your routes and logic in one file is not a good dx, but I don’t see how you can separate that out. Export the elysium instance and decorate it with new handlers and re-export? I has the confusion
Sounds like a good stack, I was looking into using bun
"This is the BETH stack. It begins with H."
Ethan i have a question i currently use svelte kit do think i have to use this new stack ? For prod ? Thank you master ❤
You should use whatever makes the most sense for you. There’s no need to constantly be rewriting your app to the newest trendiest stack unless you have a real reason for doing so.
@@ethanniser yeah you right recently I switched from NextJs to svelte because NextJs issues cache performance etc...
/ Reactjs ( long code to do simple things.. you know)
From pure Js
To PHP
To Laravel
To angular
To vuejs
To reactjs
To NextJs
To svelte kit
Now I think will just try it after completing the svelte kit will see 😃
But it looks the new stack is hot 🔥
Using template engine + HTMX is pure joy
What about solid-js? Its more popular and lightweight than htmx
SHIT, this stack combines a bunch of different things I've been wanting to use. Bun, Elysia, Turso and HTMX. Damn. Literally have no choice but use this stack in my next app.
Love this vid. But it's aalso nice to mention tat bun is still very experimental. I tried working on a project with it like 2 days ago vut couldn't get it working (cos of some bun specific error). There's also the fact that most popular libraries don't interop with bun 😢. But besides that, your stack looks really interesting and i think ill try it out 😃
interesting stack but still prefer sveltkit, the script template style method does a better job than putting everything on the server, better view and dx especially when debugging and working in a team
Interesting video, but as far as I'm concerned, getting JSON from the API is a feature, not a bug. This approach tightly couples the API to the FE, which reduces testability and the ability to compose APIs or use different API endpoints into a single app. The stack components look v. interesting though. Thank you for making this video and I'll definitely check out Bun, Elysia, Turso and hyperscript.
Well, this is just how the HTMX model works. If you don't like it, don't use HTMX.
The backend can offer json or htmx depending on the request mimetype if you wanted to support both. Just extra work for the backend at the router layer and presentation layer.
@@davidmcdonnel4831 "extra work" no thanks
instead of tailwind, i would wanna make inline with @scope
when browser support is there
until then i can just generete random class names i guess
could but a large codebase might get confusing really fast with xhtml
Any headless UI libraries for htmx?
But if we want to display at the top of the screen, the number of completed and not completed todos?
what is ssr
server-side rendering
the absolute madman
@ethanniser Do you believe this is the perfect frontend stack for 2024? I mean, if I am starting with frontend development, should I go for the BETH stack straight away?
even without rust, is too blazingly fast. I will consider the BETH stack in future projects and all know Bun when reach v1.0 it will break node and deno. Greetings from mexico, new to your channel
@CesarLP96 ?
What extensions do you use? I was curious about the typescript error messages
Error Lens I think is what you're talking about but I’m pretty sure I had it disabled? Lmk if that’s right or not
@@ethanniser that`s right, thanks
@@ethanniser It was on at 9:02 but I'm glad, I never knew this existed either!
I'm not a fan of the HTMX paradigm and am still too attached to express to even consider Elysia, hopefully some time soon. This video, however, was amazing and you just gained a new subscriber
அருமையான முன்னுரை நன்றி
I feel like my first response to watching this new all different stacks is just rejecting, but then I think "If i'm rejecting i'm biased and I should give it a try to understand", but then If I still don't like it I keep thinking "am I still just rejecting cause it's new?"