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.
@@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?
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.
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.
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.
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.
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.
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
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.
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!
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.
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...
"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.
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?
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 💯
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.
@@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.
@@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.
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.
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 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.
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...
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
As a frontend dev, I don't want to know anything about the backend. I don't want to know which database is used, which backend framework is used, etc. I only want to know what the JSON response will look like. As far as I'm concerned, the backend is just a black box that serves data. As a backend dev, I don't care about the frontend even in the slightest bit. It can be an SPA web app, an SSR website, a mobile app, a CLI tool, etc. I don't care, I'm just serving JSON and doing it in the best way I can. I am definitely not serving HTML, because I must not assume that the client is a web browser. Stacks/frameworks like this, which focus on serving HTML and using build-time magic just to avoid serving JS like it's a plague, just don't feel right to me. If I really wanted to serve HTML and use form actions for data manipulation because I'm allergic to JS, I would just use PHP, with no "bleeding edge web stacks" involved.
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
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.
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 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.
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
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.
@@ethanniser I tried to run through your tutorial but it seems some things have depreciated with the launch of 1.0 this week. Ill get some of it together open an issue in the repo. I dont think it is a massive deal since you mentioned you are doing a fresh beth stack video soon. Is that going to be using the 1.0 release and current versions of the rest of the stack?
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 😃
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?
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.
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/
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
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.
Really excited for HTMX. I can't stand the js ecosystem so I'll be building my backends with something like Go, Python, or Rust. Javascript fatigue is real, and I encourage other devs to invest into a better language.
For sure, I like typescript + JSX, but I’ll be the first to admit it’s not for everyone. Htmx is awesome in that it’s backend agnostic. Whatever language/framework you like you can use it with
you go for htmx which is amazing to simplify things and then you again overcomplicate everything. what about a very simple and easy stack like PHS [php(backend api), htmx(frontend), sqlite3(db)]. same thing but very easy and a lot faster to develop. extremally portable and easy to recreate. i run it in xamp and it works, drop it on server and it works, send to a friend in an archive to drop on his server and it works. no installing over installing over installing and setting things up.
This stack definitely seems like an interesting idea which is desparately in-search of a reason to exist, and with a lot of ignored problems. HTMX is a good idea... but there's not really a good reason to use it. It's the part of the stack that I think is absolutely the least sensible. If it was how browsers already worked, then that'd be great. But it's still using JavaScript, so you're not really getting anything out of it. The way the app works is fundamentally the same. In fact, it just lowers what you're capable of doing on the client because you have to program by limiting what you can do to to what HTMX can do rather than having actually dynamic components on the clients. It also makes all interactions feel a little crappier because you have to wait for a service request for any interaction. On local, it seems fine. In production, it's crap. Just use Astro. It uses JSX but has zero-JavaScript by default unless you add a component that relies on a framework (it can be used with React, Vue, Svelte, and Solid components). That solves all of what `typed-html` is doing for you and gets you dynamic behavior in the framework of your choice when you need it rather than limiting what you can do client-side to what HTMX offers you. This also allows you to have pages with zero-JavaScript which you don't get in this stack because you're always sending the HTMX bundle even if you don't have dynamic behavior on a particular page.
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.
If we assume that htmx is just syntactic sugar over jquery, you can see that this is exactly how we wrote applications 8-10 years ago. It was horror without comprehension for any minimally complex application, and the video brought me back to this horror for a second ☠
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?"
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.
Supercool to see how living on the bleeding edge might be like but at this point compiling jsx on the server side just sounds like next.js to me. Maybe consider something like Astro?
I do really like Elysia and Bun, but this just feels like recreating react, only running client-side. In the end you might as well use Next with SSR. I think it's not a mystery if Django users adopted HTMX the fastest, since it really integrates well with Django templates, which are already very close to html.
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
Bun should show it’s serious about libre software by getting their community off of Discord & into a FOSS-based option like IRC, XMPP MUC, or Matrix Space. Right now it’s cutting folks off that don’t believe in proprietary platforms that read your data, don’t have SEO, and often require a phone number to enter.
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.
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
Wait no I’m the person who made a TH-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 😋
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
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.
Good to see No Boilerplate inspired youtubers propping up
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!
Syntax looks terrifying, the PHP nightmare is returning with a new power
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
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.
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.
Fffffff... Crazy good....! Keep produce content with BETH stack. I want to know more. Thank you
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
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
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
Beth stack: "Aww... How sweet ❤"
PHP: "Hello human resources!! 🤢"
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!
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.
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.
"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.
This effectively fulfils my dream of power of an entire website in one 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?
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!
thank you so much for the effort in making this video. I had a blast watching it.
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 💯
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.
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.
Alternative names:
Segfault stack
Unemployed stack
you can already tell he's on his way to hundreds of thousands of subs.
Blazingly bleeding edge stack. Definitely trying this😂
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.
Wow I am really thrilled to see so many cool tutorials being put out! Great content Ethan :)
this type of content should ideally be in a blog format for easier reading
Amazing video! I’ve been wanting to test htmx, I’ll give it a try with the tools you mentionned!
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.
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.
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
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.
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
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
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
This is amazing, I noticed that the REPO has Lucia auth now, is there a continuation of the tut?
so now we’re back to the server doing the heavy lifting…. interesting
As a frontend dev, I don't want to know anything about the backend. I don't want to know which database is used, which backend framework is used, etc. I only want to know what the JSON response will look like. As far as I'm concerned, the backend is just a black box that serves data.
As a backend dev, I don't care about the frontend even in the slightest bit. It can be an SPA web app, an SSR website, a mobile app, a CLI tool, etc. I don't care, I'm just serving JSON and doing it in the best way I can. I am definitely not serving HTML, because I must not assume that the client is a web browser.
Stacks/frameworks like this, which focus on serving HTML and using build-time magic just to avoid serving JS like it's a plague, just don't feel right to me.
If I really wanted to serve HTML and use form actions for data manipulation because I'm allergic to JS, I would just use PHP, with no "bleeding edge web stacks" involved.
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
"This is the BETH stack. It begins with H."
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
Ssr app in highly performant bun runtime with htmx to handle dom updates from the server. Very nice
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.
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 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.
pretty exciting, great video!
Everytime I see htmx I feel like its just reiventing the wheel all over
🔥This video is a HOMERUN. You've got a new subscriber. Thanks! 🔥
Why can I not set completed to true for the "learn vim" item? I've tried for over a decade now.
Me ha sorprendido que he podido seguir la explicación perfectamente. Si sabes Express y React (y Tailwind) es perfecto.
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 ?
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.
I'm glad for knowing about awesome tools, but stuck in the real db connection. it's maybe drizzle-orm problem.
If you want to open a issue on the GitHub repo with more info I can try to help you out
@@ethanniser I tried to run through your tutorial but it seems some things have depreciated with the launch of 1.0 this week. Ill get some of it together open an issue in the repo. I dont think it is a massive deal since you mentioned you are doing a fresh beth stack video soon. Is that going to be using the 1.0 release and current versions of the rest of the stack?
@mrmoss7467 yes it will be updated and improved
@@ethanniser I'm very excited for that video to drop! Honestly haven't been this excited for a new stack since Vue.
Your content quality is 😍🤩 love to see more videos from you
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 😃
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?
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.
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!
Using template engine + HTMX is pure joy
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
HARMfull stack‼️ Htmx Axum Rust Minijinja
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
Nicely presented, and I got some TIL's. +1 sub!
0:10 had heard write time complexity, but never the DX Developer Experience before.
Can you do a video on websockets using the htmx and Elysia?
Really excited for HTMX. I can't stand the js ecosystem so I'll be building my backends with something like Go, Python, or Rust. Javascript fatigue is real, and I encourage other devs to invest into a better language.
For sure, I like typescript + JSX, but I’ll be the first to admit it’s not for everyone. Htmx is awesome in that it’s backend agnostic. Whatever language/framework you like you can use it with
I prefer LASH stack (leptos + actix + sqlx + htmx)
That’s a awesome stack as well
you go for htmx which is amazing to simplify things and then you again overcomplicate everything. what about a very simple and easy stack like PHS [php(backend api), htmx(frontend), sqlite3(db)]. same thing but very easy and a lot faster to develop. extremally portable and easy to recreate. i run it in xamp and it works, drop it on server and it works, send to a friend in an archive to drop on his server and it works. no installing over installing over installing and setting things up.
I was literally testing out Elysia yesterday
This is crazy powerful, omggggg.
This stack definitely seems like an interesting idea which is desparately in-search of a reason to exist, and with a lot of ignored problems.
HTMX is a good idea... but there's not really a good reason to use it. It's the part of the stack that I think is absolutely the least sensible. If it was how browsers already worked, then that'd be great. But it's still using JavaScript, so you're not really getting anything out of it. The way the app works is fundamentally the same. In fact, it just lowers what you're capable of doing on the client because you have to program by limiting what you can do to to what HTMX can do rather than having actually dynamic components on the clients. It also makes all interactions feel a little crappier because you have to wait for a service request for any interaction. On local, it seems fine. In production, it's crap.
Just use Astro. It uses JSX but has zero-JavaScript by default unless you add a component that relies on a framework (it can be used with React, Vue, Svelte, and Solid components). That solves all of what `typed-html` is doing for you and gets you dynamic behavior in the framework of your choice when you need it rather than limiting what you can do client-side to what HTMX offers you. This also allows you to have pages with zero-JavaScript which you don't get in this stack because you're always sending the HTMX bundle even if you don't have dynamic behavior on a particular page.
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 ?
I love this a lot....especially the Acronym
Great video! Some interesting takes.
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 😢
If we assume that htmx is just syntactic sugar over jquery, you can see that this is exactly how we wrote applications 8-10 years ago. It was horror without comprehension for any minimally complex application, and the video brought me back to this horror for a second ☠
What horror?
Great video 🔥🔥... Keep it up
Very cool, and really well presented 👏
I'm stuck here 6:38. this is the text in the html
html is not a function. (In 'html(baseHTML)', 'html' is undefined
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?"
Great vid ever!!
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.
Supercool to see how living on the bleeding edge might be like but at this point compiling jsx on the server side just sounds like next.js to me. Maybe consider something like Astro?
I do really like Elysia and Bun, but this just feels like recreating react, only running client-side. In the end you might as well use Next with SSR. I think it's not a mystery if Django users adopted HTMX the fastest, since it really integrates well with Django templates, which are already very close to html.
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
This video made me appreciate that I don't have to do frontend work
What's your color scheme (theme)? It looks absolutely amazing. The content is great as well, thanks!
I’m gonna make a little site with all my settings and stuff tonight
@@ethanniser Thanks that would be awesome.
ok added to the description of every video, hopefully you find that helpful
thanks for watching
it's like setting up valina emacs or emacs with rust/js implementation instead of using distributions, Spacemacs or Doom Emacs.
doing flask sqlite htmx rn but will defo try this stack in my next project
Bun should show it’s serious about libre software by getting their community off of Discord & into a FOSS-based option like IRC, XMPP MUC, or Matrix Space. Right now it’s cutting folks off that don’t believe in proprietary platforms that read your data, don’t have SEO, and often require a phone number to enter.
World Record killing your project speedrun (any%).
Imagine downgrading from discord to fucking IRC LMAO.
Sounds like a good stack, I was looking into using bun
Idk, it doesn't look or feel better than any modren framework.
It feels so manual and might result to spaghetti code