To me it’s all just layers of abstraction. Long gone (save for the htmx reneceance) are the days of directly doing html and css, we now have tools on top of those which we now work with and use. Pretty soon we will get some ai framework which creates react blocks and takes us up ANOTHER layer

@@bmdavis419 Agreed. But with each layer of abstraction, we know less and less about what actually runs. I personally hate it. Back in the days, when I finished a product, I really felt that I built it all by myself and could feel proud. Today, I feel nothing. All the abstraction is removing the feeling of accomplishment, pride and joy. I guess if you have been doing it this way your whole life/career, you will not understand what I mean. Regardless, I want to take this opportunity to say that I really enjoy your videos. Great quality and insights. Especially considering your young age. Thanks! The fact that you have time to test out all these frameworks and tools, build several projects, make youtube videos AND study at the same time is truly impressive.

I think you missed the point if you think that HTMX is ridiculous. HTMX in the frontend is just using some attributes for great interactivity, lazy loading and other stuff instead of writing tons of code in pure JS or jQuery or React to do the same thing. Heard about HTMZ today which is even smaller and faster.

Yea my actual business organization structure is completely fucked right now lol, I have like 3 LLCs and a bunch of different projects with different people, it is not well put together. Will organize it pretty soon here, rn the only thing I care about is getting stuff shipped and money made

Oh yea that’s a good idea (web is 100x easier and nicer lol)

oops

i was about to say the same! The best way to start a conversation online is to say something wrong :)

@@mattythebatty1 It happened, get over it

I have heard good this about SST (never used), terrible things about amplify

Any of the full stack JS, either Sveltekit, Remix, or Next

@@bmdavis419 Thanks for the reply. So I’d guess you would advise against a custom backend if it’s not needed. Next / sveltekit have everything needed ?

IF YOU DONT KNOW JS AT ALL: - Stick to your backend and use it as an API Rest. Flutter fits with SaaS model (Web or Mobile). - Learning to build the UI and frontend logic would be better and faster for you than pursuing a frontend degree (HTLM, CSS, JS to TS, DIY libraries, node_modules, competing ecosystem, reinvent-the-wheel communities) in Svelte. - Dart takes inspiration from Java and C#. While SEO is not friendly there are some workarounds, see FlutterFlow and Rive success.

lol this is exactly what my thoughts were for a while, I honestly kinda gave up on a lot of those and just simplified to full stack js on vercel, at least for now for me less is more

hmmmmm... I have genuinely loved using it in the e-commerce project so I'll have to take a look

@@bmdavis419 as usual hmu if you have any questions

yea I worked full time for ~9 months last year, now I'm a student again

I really really hope so, when that happens I will be there

Nowhere! Still using it for BLOK, I just prefer a basic DB for web. Supabase is my goto for mobile stuff at this point

@@bmdavis419 Alright, keep on doing these great videos ! Thanks for sharing.

Take into account that marshalling and unmarshalling JSON is not a trivial task that must be done both in the client and server. Browsers can directly render HTML

These are legitimate concerns, and I think it's cool you are thinking about these things. Thought I'd play devil's advocate on some of these to start some discussion! 1) There are actually many cases where the HTML response would be shorter than the corresponding JSON responses! Think about long field names and lots of nesting in JSON. And if you are rendering on the server, think about all the client side javascript rendering code you completely remove! React is a huge dependency, and even component rendering logic can add up. Generally, sending the rendered HTML directly from the server often saves the client from a lot of resources. In practice, I imagine JSON + client side rendering logic is almost always heavier than just the rendered html. When you also account for the fact the client needs to parse all that JSON and JS, it's hard to imagine cases where JSON and client side rendering is a better choice. 2) True, there is some rewriting necessary. But you should be able to mostly reuse a lot of code! All the request -> database -> data logic can be carried over. But instead of going data -> JSON, you just change that to be data -> HTML. JSON and HTML are just string representations of data at the end of the day. They aren't too different! 3) Sending requests to the server every keystroke would get problematic fast, good thinking! Thankfully, there's a simple solution to this problem: throttle the request so it only sends once the user stopped typing for 500ms! HTMX makes it easy to do this, see this example: htmx.org/examples/active-search/. You don't need to write your own JS! This all being said, I'm not a huge fan of HTMX. I think lots of apps are too interactive for HTMX to be viable. Though, I think a lot of modern web frameworks bake in this idea that returning rendered content from the server is almost always better whenever possible, and I love that they do that! React server components, SSRing in all frameworks, SSG, etc. are all examples of techniques to limit JSON and client side rendering. I ended up typing way more than I thought I would... sorry if this was overkill! Hopefully you or someone else finds this interesting haha. I'm curious to hear any additional thoughts you or other readers have though!

the fact that responses like this get lost in YT comments is such an L, this is a very good reply, good points!