The Web is Broken. Let’s Fix It!

What is the best way to build a web app today?
💬 Topics:
- What is the best JS framework?
- Frontend best practices;
- React vs HTMX;
- Signals, Hydration; Reactivity;
- How to build a library from scratch;
- The web dev history;
- Frontend dev mistakes to avoid.
📚 Concepts explained:
- Signals - • Signals Explained
- Hydration - • Hydration Explained
- Resumability - • Resumability Explained
- Rendering - • Web Rendering Explained
- Reactivity - • Reactivity Explained
📖 Blog Article - www.awesome.club/blog/2024/th...
🖥️ GitHub Repo - github.com/awesome-club/not-a...
Patreon - / awesomeclub
#javascript

[@MrHedy90]

We can fix it only when web developers will start to learn fundamentals instead put "HTMX developer" or "NextJS developer " in their resume.

[@awesome-coding]

I was just thinking the other day that the "full stack developer" role is a really dumb concept :))

[@erickmoya1401]

​@@awesome-codingwhy?

[@leandro.cuminato]

@@erickmoya1401 Maybe what he's saying is that all Web Developers should be full stack developers, not only this or that You should be able to work with the web

[@fixiple2722]

@@erickmoya1401 I think it's also a matter of preference, I for example absolutely despise PHP, so i DO NOT want to work with PHP at a Job for example.

[@griffadev]

Mostly agree although I'd just reach for htmx and web components for interactivity requirements. But tbh if you're writing everything in typescript just use a full stack react framework and build something valuable instead of fiddling with internal libraries Also the example you shared of nodejs sat in the midlde is only true if the backend isnt written in node or youre off in microservice land where the simplicity ship sailed long ago

[@awesome-coding]

HTMX + Web Components is a really good combo, even though I HATE the default web components DX. I agree. However, as far as I know most backends are built in solutions other than Node.

[@griffadev]

​@@awesome-codingyeah that's fair

[@Lemmy4555]

I don't think even google believes in Web Components anymore, because after an initial push between 2012 and 2016 with the advent of WebComponents v2, Angular 2 and Polymer, the innovation there practically stopped. WebComponents today are the picture of what has been done until 2016. Yes Google released Lit that is the successor of Polymer and there're a couple of minor framework that leverage on WebComps, but they are harder then classic frameworks and you have to learn a number of limitations that are intrinsic when using WebComps. Let's not even talk about them being unsuitable for ssr that is per se a big down. HTMX plays well only when supported with other templating frameworks to build html pages, otherwise it quickly becomes cumberstone to do everything by hand. So dispite what many are saying, HTMX doesn't necessarily makes things easier. The most common combination of Go (Web Server) + Temp (Go's template engine) + HTMX means that you need to know two very different languages and at least 2 different framworks + the stdlib of Go to build a REST API. That's much harder than installing Next or SvelteKit (1 language, 1 framework). Moreover managing JSON in Go is of course significantly harder than in JS.

[@vigneshwarrv]

@@awesome-coding you did work on web components. what library you used work with? People are complaining more that web components are class based so I thought of using jsx like syntax and transpiler to convert it to class definitions ( never implemented though ). what is your take on that?

[@alexandrucomanescu9857]

So fixing it by creating another framework?

[@mehdiyahiacherif2326]

this is how all other frameworks are created lol, even react and angular were "simple internal tools"

[@alexandrucomanescu9857]

@@mehdiyahiacherif2326 They basically rewrite the htmx in this video 1:1. Edit: I should have said “by creating another identical framework”.

[@awesome-coding]

HTMX: is thousands of lines of code, 10 kb gzipped and minified in total The code in this video: 160 lines Comment: you rewrote HTMX 1:1 👍

[@awesome-coding]

@mehdiyahiacherif2326 Hey! This one will be really different ok?

[@alexandrucomanescu9857]

@@awesome-coding You know what I’m talking about.

[@shantanukulkarni007]

Htmx will never take off or get widely adopted. Because using this will mean all the ultra egoist ideological framework gurus will have to accept defeat and accept that they wasted last 15 years of humanity for no reason. Which will never happen and JS framework industry will keep on coming up with more and more complex solutions to feel supirior to those who has life and wife

[@TechBuddy_]

Oooooh! This comment is now my tweet 😂 thanks

[@awesome-coding]

Yep! We need all this good stuff so we can justify 6 figure yearly salaries for "frontend senior developer" positions.

[@buc991]

That’s such nonsense, in real world most frontend developers, just like all other ones just using what they’ve been told to use at job, mostly it’s react, they pay for it, i use it, if it will be htmx i will use it. And this take that react is complex or smth is showing that you don’t know much about it, it’s a very small and simple library, after using both htmx and react i can say react is even easier and have less api. Also if people will continue to use htmx in real world projects soon you will see that tons of libraries and “complex” ecosystem will appear around it also.

[@shantanukulkarni007]

@@awesome-coding bro i am a "frontend senior developer" please dont insult my job like that 😭😭

[@shrin210]

It is not a developer problem i think. The business world likes marketable terms Cloud, HTMX, Angular, Reactjs etc. Bcoz of these complex system we could have life and wife. We understand Web and Js is broken, nobody is ultra egoist. Let's see even if it will end.

[@egemengol306]

How can we say that we built a messaging app if we use long polling instead of server sent events

[@awesome-coding]

It's a messaging app from the past! :)) You are making a good point, my intention was to come up with a solution which is flexible enough to do various forms of interactivity. It might be worth exploring server events in this context though.

[@vigneshwarrv]

Ahh I am big fan of the comment section of your videos now. There are so many experiences, stories, dramas ( traumas ) and so much to learn

[@awesome-coding]

✌️yep! it looks like we are building a small community here, which is amazing!

[@TechBuddy_]

WTF!!! The video quality is gooooood!! And the depth is awesome ❤

[@awesome-coding]

Thank you! I did put a bit more effort in editing on this one 😅

[@VitorHenrique-jk8yl]

I agree with most things you said at the beginning, the current state of web is a bit of a mess and we can all agree with that. As a proof of concept, yeah, being able to have a reactive framework in a few lines of code is amazing and very simple, I'd love to see more exploration there. That said, I'd probably hate if someone proposed this at work. I disagree with the "let's keep it short so we can justify building this internally" - the code is only small enough because as you said at the end, the implementation is naive. You're dealing with reactivity, but I assume this doesn't work in various cases? The one I can think of is rendering a list that reacts to certain input changes, does that model work with no additional code? My point is - when you start building an app, you'll often find corner cases that your framework doesn't cover for, then you find yourself tweaking the framework 90% of the time (and maybe having your team do that too), after all the tweaks, you'll probably end up with a little bit of a monster that's no as well documented as something like the mainstream frameworks.

[@awesome-coding]

I completely agree with your assessment about choosing a framework instead of building something internally - I even mention in the video that whenever you are exceeding a 1-2k lines of code you should probably use a library. However, I believe you'll end up with a monster with mainstream frameworks as well - just take a look at what React did in the past 10 years. Imagine starting a React project in 2018. You'd probably be locked in into Redux and Class components now. Or even worse, you'd have a pile of class components, function components, Redux, Context, Recoil and some server components on top of it all. And you are still relying on the Virtual Dom which is rapidly getting deprecated - so just more dead weight you have to carry around. Is this better than building something internally? I honestly don't know, but I believe it deserves a discussion. " The one I can think of is rendering a list that reacts to certain input changes, does that model work with no additional code?" - you could do this the HMX way: x-on:keyup="get:/list" x-to="list". So this is actually one of my points - we are so locked in into the current mindset that it's hard to see outside the current practices. As I said in the video - Van JS was a real eye opener for me - just take one step back, look at the problem, and you might find a way easier solution. (This is what Solid also did with signals)

[@VitorHenrique-jk8yl]

​@@awesome-coding I agree with all your takes in Redux, Context, Recoil and the Virtual DOM - the cost of maintaining legacy React is high, and what I take away from your video (which is really well put together by the way) is: things are too complex for no good reason. I have to admit SolidJS and this video on what we can do >just< with VanJS reshaped the way I view frontend. On the topic of: "should we be building this internally?" I think it depends on the team/project, and I apologize if I may have come off as rude on the first comment, let me re-state that: In the current project and team that I'm in, I'd hate to go that direction. But it could work for other teams for sure! I believe it to be more of a question to be answered collectively by the team you're working on - kind of like: "do we see enough benefit and are we willing to maintain this internally?". I'd be totally open to that kind of discussion.

[@awesome-coding]

@@VitorHenrique-jk8yl No worries at all - you didn't come off as rude. I get what you are saying, and I know most of the time the team will say "let's keep it safe and use what everybody else is using". I'm also aware that this video is a rather theoretical discussion, in the sense that no sane Tech Lead or Project Manager will every take into consideration dumping React or Angular for an in house tool built by the team for scratch. The risk / reward ratio isn't worth it. However, the problem still remains - things are overly complicated on the frontend, we are going into some pretty weird directions (see React Server Components for instance) and nobody seems to care 😂

[@dovh49]

I built `html-form` which is very similar to HTMX but focused on forms as the main place of interactivity which simplifies HTMX's complexity and allows you to easily make apps that work with or without JS. The main issue though is that HTMX is well thought out and covers a lot of bases. If you created your own HTMX it will start small and the bigger the apps you build the more you will find that you would have just reached for HTMX as your "small" library will become just as big as HTMX. And, btw, HTMX will be getting smaller here in the near future once HTMX 2.0 is released as it will no longer need to support IE and will be removing items that should have been extensions but weren't. I think they could go even smaller if they really wanted to - mainly by making it so you use forms for interactivity, if you want something outside a form then you a web component that registers event listeners (the hx-trigger).

[@awesome-coding]

I fully agree people should use HTMX if they feel the need to. Me building that "library" was just an exercise in showing that anybody can do it, and they should do it if their use case is small enough.

[@SG-br9vj]

If there's no JSX and React involved, I'm in! 👍😁

[@awesome-coding]

After almost 10 years of using React, JSX is the only thing I still like about it :))

[@coldagofee]

if you already use next (or remix), just read/write data from/to db directly without another backend

[@awesome-coding]

Yes - this works for some apps. You can run any DB code in the backend handler - and works for any of the existing meta frameworks. However, I'm not sure if this is the best option when it comes to scalability and infrastructure support.

[@coldagofee]

@@awesome-coding can you give an example issue in "infrastucture support" ?

[@awesome-coding]

​@@coldagofee Maybe not the best use of a term. I'm thinking of backend systems built for scalability - like being able to build a microservices architecture coordonated by something like ZooKeeper, with API Gateways (Zuul), AMQP messaging, Scheduling, Tasks and so on. I know that this is complex infrastructure not necessary in most cases, but you'll have bits used in smaller stacks as well (AMQP should be preferred over HTTP whenever 2 servers start to communicate with each other for instance). Now looking at next / remix in this context makes them pretty useless of course, since they were not designed to address these problems.

[@coldagofee]

@@awesome-coding thanks for your reply

[@lukasmolcic5143]

htmx and alpine are good solution for UI state and ajax communication with the BE, what is still missing is proper component equivalent with typed props in other templating languages which provide the same level of DX as react like solutions do, even if we get that templating support in one BE language, the advantage that React has is that it keeps that same model for working on the FE no matter the BE stack that you are using.

[@morphles]

React and advantage? Was forced to use React after buyout. Jesus what a pile of... PHP + vanillaJS any day, and types and typescript are way overrated. If you write mountains of boilerplate nonsense, of course very nice to have a helping hand. But if you write small stuff, like in this example, damn types, and specifying them for highly dynamic code, takes more space and time than damn code itself, complete horror show.

[@awesome-coding]

I believe we really got used to the component based DX React is offering, and for good reason - it feels natural to compose UI's and leverage JSX. However, templating support is really strong on the backend. Take a look at Templ for instance (github.com/a-h/templ ).

[@morphles]

@@awesome-coding , well I worked for ~15 years with php, I just fail to see innovations in lots of recent hotness :D Well, most recent stuff like htmlx sounds nice, (but reacts and the ilk definetly not), as you would roll something like that manually, in shitier approach using jq. But react stuff to me is, oop all over again, maybe that's why it's popular... But since I never was hot for oop, it seems convoluted, inflexible and verbose way of doing things. Instead going, div div span a, right there in my php template, I now have some custom bullshit components I need to look at across multiple files with half of file being complete useless boilerplate of imports and useState and other nonsense, and then I move companies or projects or whatever, and those custom components are new again, have fun learning them again (surely these will be useful this time!), in whatever incomplete messy sub-optimal way the other group decided to make them, where even finding what what you supposed to use takes half a day! I'll take my divs, spans, labels etc. etc., thank you very much :)

[@lukasmolcic5143]

@@awesome-coding so I've heard, I am exploring GO a bit because of that, but for example I have a custom setup with TWIG, HTMX and alpine for making custom wp themes for content websites which works perfectly, except that twig doesn't have types which would make it more viable for larger, longer maintained projects. I work at a php oriented company, so wp for simple cms-es, symfony and sylius for custom app and e commerce development and on the FE we use Next in most cases to connect to those backends over API. As you described in the video the decoupled approach introduces its own new problems to solve, and I am exploring ways to go around that, and for simpler sites wp enhanced with HTMX is perfect, but otherwise in our case we are stuck with Next, cause I don't think I can convert all our BE devs to start writing GO.

[@lukasmolcic5143]

​@@morphles higley disagree, any even a bit larger project benefits from having types enormously, especially if people are coming in and out of the project, a components interface serves both as a guardrail and as documentation for the next dev to know how to use it. I am talking here mostly about component prop types, which in most cases are trivial to setup IMHO. Working with API data is also a lot easier with good types, but let's ignore that cause we are talking about non decoupled solutions as an alternative.

[@pedrogorilla483]

I was just waiting for HTMX to come up

[@awesome-coding]

HTMX is always coming up these days...

[@32zim32]

jQuery: I'll be back

[@awesome-coding]

100% - just make it a bit lighter :))

[@Winnetou17]

@@awesome-coding Lighter ? Than the jQuery 3 ?

[@awesome-coding]

@@Winnetou17 Yea, I think that the Slim version is more than 20kb. Compare this to Solid's 7kb :D

[@Winnetou17]

@@awesome-coding Hmm, ok, I'll have to go check Solid then, I don't know about it.

[@awesome-coding]

@@Winnetou17 It is really easy and powerful. I posted a video about it last week - kzbin.info/www/bejne/q6OcoYprnbp9ock

[@coffeeintocode]

Simplicity at its finest 👌

[@asdougl]

This idea that everything is bad except this one thing doesn't get anyone anywhere. We should be focusing on ensuring we're well informed about the advantages and disadvantages of different tools so we can make decisions around what tool is right for the job. HTMX is great for simple primarily data driven applications, whereas Next JS would be better for complex applications with more interactive requirements, and maybe Solid JS is better for a simple client side app with minimal database requirements. You might disagree with these choices but that's ok, discussing why X tool is good for Y task is super important to growing as developers. The modern web dev environment has a lot of tools now because there are a lot of different kinds of problems we're trying to solve and no one tool can solve them all.

[@avwie132]

The problem here is that applications evolve and you’re stuck with your initial architecture choice.

[@fopsdev3676]

thanks for another interesting video. i have also build my own opinionated framework. it's also using js proxy to determine if an element needs to be rerendered. for my lob apps i can rely on modern browsers and therefore i'm also relying heavely on the browser apis (web components, fetch, ...) cutting down dependencies as much as possible. i luckily don't need server components or hydration because my js is small enough to be loaded quickly. but i have hydration on the client. that means i can save my state into indexeddb at any time and restore/rehydrate the ui as it was saved (also valuable in production and for offline usage). not sure if other frameworks went this far... so far i'm enjoying my journey :)

[@awesome-coding]

Please do share your work if that's possible. I'm always interested to see what other people are working on.

[@fopsdev3676]

would like to. but its currently closed source (its very opinionated and geared towards my typicical lob apps i create for my customers)@@awesome-coding

[@byte_it945]

bro i am a flutter dev and just started with web dev, it's just complete mess. I saw better option with Rust. But would rust be able to cut it. Like i'm in University and really wanna get placed next year.

[@awesome-coding]

Uh... welcome to web dev! :)) I would not recommend Rust if you are looking for job prospects. It's an amazing tech, but it's too early for them. If you want web dev learn React and / or Angular. These are still your safe bets.

[@byte_it945]

@@awesome-coding okay then mern stack it is. And one more thing, should i focus more on fundamentals (like diving deep into stuff) or focus more on implenentation

[@awesome-coding]

@@byte_it945 In my experience fundamentals really matter in this space, because those are the only constant. You'll do Angular now, and maybe React next year if you get a better paying job. 3 years from now you might get a Vue or Svelte opportunity, and you should be able to seamlessly jump through frameworks thanks to a very good understanding of the basics (JS internals, the DOM, Rendering, Reactivity and so on - I provided some links in this video description for these exact core topics)

[@coldagofee]

i think current state of the web is better than ever before. if we look back to the past when every browser have their own "JS" lol. and tooling around web like vite is really good. even ui frameworks is really similar one to another (solid, svelte 5, vue vapor, angular 17+, signal based with different templating language)

[@smithrockford-dv1nb]

Solid is good but for it be used by real businesses it needs to have a wider ecosystem such that devs don't have to reinvent the wheel. Most websites are not apps, and the video applies, but if you are building an app and trying to lower costs as much as possible using react for the web, native (electron & capacitor) just cuts costs so much.

[@awesome-coding]

I agree - this video is mostly a technical discussion for technical people. In the real world, management will not care about any of this abstract stuff. Budget, existing know how and experience, and the ease of recruitment will dictate so React or Angular it is :D

[@Lemmy4555]

There're many vanilla JS libraries that you can integrate with in Solid. Integrate with vanilla js libraries is much easier in Solid than React.

[@aarholodian]

Unless you're building a huge highly reactive platform a'la jira or something (even then it's debatable) what exactly is missing in something like solid, genuine question? I see this point being mentioned a lot, but have not seen a real example that would noticeably hinder feature rollout speed. I'm not really a frontend guy, so maybe I'm missing something

[@namaefumei]

Couldn't agree more. Too many damn layers.

[@ruaidhrilumsden]

"Node server make additional requests to 'actual' backend server". I'm not sure I get this. Surely if you're using Node on the backend then that is your server?! I've never seen any instance of a Node server being used as some sort of intermediary server. Is this slightly disengenuous or am I missing something? Also HTMX and Alpine are in no way zero JS. I think it's very important to draw the distinction between "no JS by default" - where no JS gets sent to the browser, and merely not actually writing JS like those librarys achieve - they are still very much JS.

[@wi0lono]

I think he's saying that lot of people don't use node on the backend, so in that case your frontend application is talking to a server side rendering node js backend, which is then talking to the _actual_ server containing your backend business logic

[@ruaidhrilumsden]

@@wi0lono OK that makes sense. I suppose an example is Remix, which is a handler put on the server with an adaptor. It's so damn easy to forget a lot of these details until you have the need to confront them!

[@awesome-coding]

@ruaidhrilumsden Yep, exactly what @wi0lono mentioned in the previous comment. I think it is fair to assume that if you are building any type of larger scale app or enterprise product you'll not use Node JS on the server. It's probably going to be Python, Java or C# (if we are being honest, it's going to probably be Java if we are talking enterprise). A lot of big apps did switch from their backend templating solutions to SPAs in recent years (mostly Angular or React backed). But now these SPAs need to be server rendered. My Java servers have no idea how to render JSX, so I need to add a Node JS into the mix just for that. While this seems trivial, it is my experience that it can turn out to be extremely painful in an enterprise setting.

[@ruaidhrilumsden]

@@awesome-coding right, gotcha. Thanks for the insight. That doesn't sound trivial, sounds like a nightmare!

[@neirenoir]

I'm gonna be honest: after working with roughly one year with WebComponents, I don't think they are ready for prime time just yet. Even using Lit to abstract some of the rough edges still feels wonky, what with the constructor being essentially a "noobtrap" and requiring more complex lifecycle hooks for setup. Handling events still sucks, and don't even get me started on what's supposed to be the web's bread and butter: forms.

[@awesome-coding]

I agree - DX is still terrible. However, I don't see how this can be improved with the current specification.

[@neirenoir]

@@awesome-coding I am pessimistic. I don't think it can be improved. We should start anew.

[@AnthonyBullard]

I work at a large Fortune 500 company, our entire modern Web UX stack is Web Components. We have custom framework (that’s too complicated tbh) for making some of this better - and make react devs feel more comfortable. But it works and we do some really amazing things with it

[@clementmmas]

Put your input in a form to listen for the Enter key onsubmit. There's no need to rebuild basic HTML behavior in JS.

[@michaeltendo]

This is not by any definition simple, and is not complete. Web development lives in a very very versatile environment. If you tried to complete this, you would end up with a usable framework, only 5 years later. Just be thankful to framework authors who are actually doing their best to fix this problem, especially new frameworks.

[@AlexanderMazuruk]

How to address interchangeability for the parts of the system? what if you'll need to integrate with the third party REST service or several GraphQL endpoints or web sockets? How to sustainably test separate visual rendering from the data/service aspects, to test this app you'll need to instantiate every layer db + service + ui rendering. How would you approach testing UI with mocked network interactions with services which are not always available 24/7? Say you have some cheap developers from India and you don't want to let them to have an access to the internal services and you would like to outsource UI development to them so they can build it in isolation from the monolith/microservices hell? :) In our reality you just give them the link to the swagger and that's it. But for htmx approach you indeed will need a separate node/whatever backend to fulfill the endpoints which will mix&blend the html bits for you. By interchangeability I also mean can you redo entire UI using different technology like Flutter later? while not touching the backend services?

[@cameonn]

Did you just remake HTMX in video??

[@awesome-coding]

I wish that was the case - this is just a combination of what I like most from HTMX, Alpine and Solid. It's 160 lines of code, so it's far from being any type of remake.

[@kilo.ironblossom]

Im rootimg for the BETH stack

[@awesome-coding]

Fair, but it is pretty unconventional :D

[@HaraldEngels]

The biggest issue I have with Alpine JS is that it is a mess when you try to do the W3C validation of the website. CSP is also a serious issue.

[@ivan.jeremic]

Just spend a bit time and learn react.

[@levyroth]

I remember when buttons were gifs and we liked it. Not every UI element needs a state. UX fatigue is real, simpler is better.

[@chiebidoluchinaemerem5860]

Wasn't `Function & with` dangerous to use in JavaScript nonetheless?

[@awesome-coding]

Yes - it's use is discouraged, but there is no other easy way to add state in the functions scope in a seamless manner. Despite it being dangerous, libraries like Alpine or Petite Vue are using it to solve this problem.

[@AndrieMC]

I smell fireship

[@antoninoadornetto6958]

Great video! 7:44 Had a question about something that caught my eye and was seeking input about if the init function can potentially be problematic To explain, there is an asynchronous closure called ‘get’ that retrieves an attribute and sets some innerHTML. Wouldn’t the forEach call not wait for each promise to resolve before continuing through the next iteration? My hunch is that maybe this isn’t a big deal because the order of execution is not of importance? Would love to hear what others think

[@mma93067]

The day js support type hints and people stop hating classes, we’ll have sanity in the frontend space

[@awesome-coding]

So.. never? :))

[@luizAugustoll]

js support type hints (jsdocs) but the best way of use it is with d.ts file. Classes? you mean css classes, or poo classes?

[@awesome-coding]

@@luizAugustoll I don't think jsdoc is a standard - it is just one of the many ways to do some type checking for js scripts.

[@luizAugustoll]

@@awesome-coding yeah, but anyway, I rather js supports ts type hint in the future, even if has some resistence.

[@mma93067]

@@luizAugustoll there was a RFC out to add python / TS style type hints for JS earlier this year. I don’t recall what they decided tho. I meant plain old OOP classes. The react economy poo-poos anything non-functional which drives me insane. Entire paradigms ignored for little benefit

[@AndrewTSq]

I think this also looked overly complex for what it should be?

[@awesome-coding]

Right - there is a level of abstraction here as well, mostly to show that you can cover quite a lot of scenarios with a few lines of code.

[@nromancarcamo]

To be honest, I advanced the video until the end, it started nice with a bit of history and you endup in htmx

[@awesome-coding]

Hey! Thanks for your feedback! I understand how HTMX might seem like it is the conclusion of the video - it's probably because I didn't manage to clearly state what the real point was - keeping things simple. I am mentioning Solid and Van in the video as well, and part of that implementation (the reactive state on the UI) is inspired by those libraries, but, somehow, HTMX ended up being more visible.

[@Lemmy4555]

"Manage state is hard" only in react. Never needed a state management tool neither in Angular in the past or Svelte today

[@awesome-coding]

Technically you don't need one in React neither. Angular has a bunch of store options - NgRX, NgXS, Akita to name a few. Sometimes they just work around it thanks to observables and services, but that's still overhead. Not to mention that they are now shifting to signals for state... Svelte is not a fair comparison in my opinion, since it is a "newer generation". However Svelte has an internal store you can use, which, funnily enough used a different reactive mechanism compared to the Component implementation, hence their unified implementation under "runes" in V5. So while some did a bit better than other, I think it's safe to say nobody got it right from the get go.

[@Lemmy4555]

​@@awesome-coding I was specifically referring to stuff like Redux and anything else that resemble its "messages and reducers" pattern, those are complicated monsters that makes the experience of developing FE hell, and they really got track only in React expecially with the introduction of hooks because the nature of React (the function is re-run at every render) makes management of state extremely hard. I also built React applications without Redux, but i can't say that was easy. At that time i remeber thinking that Angular 1 was actually easier. I agree that even the basic services and observables of Angular are overhead and the last thing i want to do is advocating for Angular, but that's nothing in comparison of Redux. I would not put in the same bucket svelte's stores or signals because they are very simple and intuitive to use and they don't require to understand new practices and patterns to get productive with them.

[@jcy089]

When even the most basic Android phones have 6GB of RAM these days and iPhones come with LiDAR, it’s pretty ridiculous web devs still complain about DOM speed. Our HTML + CSS alone is almost 1MB and UI in pure JS is another 2MB. Never had any user complain of slow UI or loading speed, you just need to learn to optimize 😉

[@QueeeeenZ]

htmx is for all the backend devs who hate frontend.

[@awesome-coding]

However, nobody hates frontend like the frontend devs ✌️

[@QueeeeenZ]

@@awesome-coding frontend devs don't hate frontend. frontend is awesome and evolving in a good way.

[@lukeweston1234]

I never quite understood this take because I always preferred sending JSON to the front end. I think it’s for Rails devs that hate large dependencies and build tools

[@fuu812]

@@awesome-coding ahhaha let me help you by creating "Yet another JS framework" 😂

[@alexandrucomanescu9857]

Sărbători fericite!

[@awesome-coding]

Multumesc frumos!

[@Winnetou17]

Și la mulți ani!

[@emptydata-xf7ps]

To fix the web completely you need a new language entirely which would require a new browser… to optimize the web with the current tools, you need to remove JS from the backend, and minimize it on the front end. CSS and html are capable of a lot of things, and the rest is mostly unnecessary and just slows everything down.

[@bear458ziif-s]

wrong, webassembly exists. there are also plenty of languages that can compile to javascript. wasm is the most promising but it still doesn't solve the framework problem. which is why wasm frameworks exist. i'm not saying you need react, but you need something if you want good dx.

[@emptydata-xf7ps]

@@bear458ziif-s WASM doesn’t connect to the DOM it still calls JavaScript. So unless your bottleneck is processing large amounts of data(not the case with 90% of websites) wasm doesn’t gain you much performance.

[@Nellak2011]

The optimal state management solution I found for Component based architectures like React, is to use services and state objects. Essentially: Parent passes service and state object to child. Child does actions defined in service, without having any knowledge of state management solution such as redux. Child also is notified of state updates with the state object it it given, so it would be the same as using a useSelector hook. This way the children are completely decoupled and modular, being re-usable in other contexts, as long as the parent using it gives the correct object field names. As for the bloat and other stuff, I am still looking for a simple solution that is elegant and scales.

[@otmanm4095]

Isn't HTMX like Unpoly and Hotwire ? Seems like these are old things too 🤔

[@awesome-coding]

You are right - at the end of the day very few ideas are truly original these days. Think about the fact that Signals, a concept introduced decades ago, was "revolutionary" in the frontend world for the past 3 years :)

[@otmanm4095]

@@awesome-codingYour video is good BTW. I did not said that to show disrepect or so, just curious about your point of view about these two others, maybe there was something more to catch with HTMX

[@awesome-coding]

@@otmanm4095 No worries at all - I got your point. HTMX just enjoys a bit more popularity these days, and it was launched at a time when we are starting to consider the server again more and more. A few years back there wasn't much talk of moving back computation, rendering and routing on the backend, but these are pretty much accepted ideas now. In this context, libraries like HTMX, Unpoly and Hotwire seem like reasonable alternatives. There is some sort of cyclicality in the web dev space, where old ideas become fashionable again once enough people agree we need a change.

[@cqanimohamed1939]

this was intersting but we can made realy something

[@awesome-coding]

what do you mean?

[@bobDotJS]

HTMX is so un-fun to use. DX is extremely important and I just don't see HTMX becoming the standard.

[@AlirezaMotevallian]

You still haven't got it I am sure you will write in a few years that you were wring. Any html-first franework that has veen tried in the past has miserably failed asthey do not recognise html is not a good language for dynamic content.

[@voidmind]

Frameworks like React provide other benefits over plain DOM. They force you to funnel mutations using common state change methods, which takes care of many hard to find bugs that you would typically see in vanilla JS spaghetti code, because the latter doesn't impose any code structure. I'm not yet sold on server components as being how I want my server code to be done, however it's undeniable that having JS/TS both on the frontend and backend means teams are more agile in what they can do, VS having only some team member being familiar with Rails /Spring / other language based frameworks.

[@lucemiserlohn]

How to fix the web? Step 1: Throw everything that is "web tech" today in the bin. Step 2: Rebuild from scratch using actually robust and useful technology. You're welcome.

[@hexxt_]

bros solution for the overwhelming number of frameworks is to make another framework in all seriousness though, i sont see a way out of this mess with javascript, a brave migration to a more preformant well structured language is inevitable

[@awesome-coding]

Hey! Hear me out! My framework is actually better because of this small implementation detail that makes a big difference in one niche aspect that I subjectively picked!

[@pinatacolada7986]

Totally agree. Solid JS is the best option in the current paradigm. Writing vanilla js inevitably leads to more code, less standardization and worse performance.

[@irlshrek]

less standardization? i dunno if i agree with this one. if you write web components theyre going to work no matter what the framework du jour is

[@awesome-coding]

I think what @pinatacolada7986 meant was that in Vanilla every team will implement their own take of reactivity, rendering and so on while in Solid you are following some established DX patterns.

[@irlshrek]

@@awesome-coding fair. I guess the question is whether it's more important to have intra-framework standardization or inter-language standardization. Like you suggested in your video, there are so many JavaScript frameworks. You really have to cross your fingers that everyone on your team likes it. There's only one web-component protocol though.

[@awesome-coding]

@@irlshrek I agree 100% - web-components are "the standard" so that's the "safe" approach long term. However... the DX is terrible, and that affects everything from finding people willing to work with it to speed of implementation.

[@irlshrek]

@@awesome-coding I think you're right. A lot of boilerplate

[@hereallyfast]

Is there even one example of a dominant JavaScript framework that is made by a company that makes less than 1 million per year?

[@awesome-coding]

Vue maybe?

[@benasmockus6988]

Actually nice work lol

[@awesome-coding]

Thank you!

[@Shazam999]

State is a problem in React because React wasn't designed by programmers that knew what they were doing. Dealing with state in Angular is much, much simpler and straightforward.

[@turolretar]

Stop it you’re making Dan cry

[@punsmith]

​@@turolretar Dan has always been a talentless hack, like everyone who worked on react.

[@awesome-coding]

I think it's more of a "reactive" state problem. I agree with you to some extent, but I don't believe Angular is any better than React. I remember NgRX being pretty terrible, and people gladly adopting simple options like NgXS or Akita. As for their native reactive state support Angular is yet another framework which "discovered" Signals in 2023, and are slowly moving away from their old Zone JS implementation - again, more deadweight you have to carry around in a project using "established, state of the art" frameworks. I don't have anything against React nor Angular, but they are both terrible. Objectively they are like at their third iteration and, while Angular finally seems to aim for more simplicity, React is pretty much going off the rails with their Server Components. And, surprisingly enough, people are really convinced that this is a step into the right direction.

[@Shazam999]

@@awesome-codingLike I said, it's straightforward in Angular. I think you're overanalyzing the issue in terms of ZoneJS. Server Components are hilarious. Rendering on the server is a terrible idea these days. I mean it always was, but there was little choice back in the day.

[@Lemmy4555]

I partially agree on the fact that Angular (the first version, because the second is a maze of modules, factories, services and other bullshits) is easier to understand than React. But the React's developers where quite ingenious, you have to consider 3 things: IE was still a thing, node wasn't popular for doing UI stuff and the compiler approach of svelte and solid wasn't a thing yet; so they had to do something that was smaller and faster than AngularJS and they did it. React's engine run entirely in the browser and since the want to keep the library small in size they decided to give away DX. For comparison AngularJS and Vue are both bigger and slower than React. But the world kept innovating and today the foundations of Angular and React is anachronistic. Both Svelte and Solid leverage on a compilation step to ship only the strictly necessary js in the browser, they both use extremly fast js compilers like esbuild, they both assume that many website will use Node to build the HTML pages with SSR and they both are built assuming that you are going to use something like Vite while developing locally. When React came out, Webpack didn't even reach its peak and gulp was still a thing.

[@unnwas]

I feel like the only way we can ""fix"" the state of the web is if we remake browsers and everything around it lol. Maybe one day we will have new browsers that work totally different but can still display old content, perhaps this will be achieved by using AI to display legacy stuff, or maybe in this scenario AIs would be used to convert sites from today's mess to the simpler future equivalent

[@awesome-coding]

This is actually a really interesting discussion - it's crazy that we have a lot of options and variety on the backend, but the JS is the only option is still the only viable option on the frontend. Web Assembly might become an alternative at some point... maybe...

[@unnwas]

@@awesome-coding Yep. JS and CSS are both too convoluted at this point. Coming from a gamedev background it always felt really weird how browsers display stuff, positioning, scrolling, dimensions, etc., all a pain in the ass and the solutions that come out only add more problems later down the line. And JS is just... JUST. Idk, at this point just remake everything lol

[@awesome-coding]

@@unnwas It must be frustrating coming from a game dev to web dev. I mean, I'm sure the transition is easy since the barrier of entry on the web is so low compared to game dev, but I imagine the whole JS experience feels like a mess compared with some of the alternatives.

[@erickmoya1401]

The problem es react. Not js or the web dev ecosystem. Just drop it.

[@awesome-coding]

I'm seeing the same mess in the Angular space.

[@coldagofee]

yess. 100% agree. web dev ecosystem is a lot better right now. frankly speaking the problem is nextjs + rsc comunity

[@notangelmario]

fuck yeah 20 seconds ago

[@awesome-coding]

You were fast! :))

[@stone-snare]

all of these comments defending the current state of js makes me cringe. "it's so innovative and it's amazing". anyone that has real experience with these frameworks knows the pain. it's all marketing from sponsored articles and videos that make everything seem so great. most js developers have a limited viewpoint because they've only used js so they think it's the greatest thing ever. these abstractions exist because of flaws, not because it's adding onto something great. it's never going to end either because these "solutions" are not real solutions. at a certain point it won't even look or behave like js and it's on pace for that.

[@awesome-coding]

100% this. "at a certain point it won't even look or behave like js" - this is my feeling when I'm looking at React Server Components :))

[@angelurena]

FWIW, your comment is cringeworthy as well. It's not all "marketing". These frameworks make it really easy to create something that looks and feels great to the end user because you can leverage a sea of UI libraries that have been built on top of them with out-of-the-box functionality so that you can stitch them together and focus the majority of your development time on actual business logic. That's the point of having abstractions. This isn't a silver bullet and has its own drawbacks, but if you can't see the use cases where these are great then you're missing the point. Every project has different needs.

[@stone-snare]

​@@angelurena the fact that this is the easiest way to build applications, proves my point. it _could_ be easier currently, but the industry is forcing this upon all of us. i don't think vanilla javascript is the solution, but these complicated frameworks aren't either. it says a lot when people think this is easy. it's not easy, it only appears to be that way because it's the norm. as i said though, it doesn't have to be this way. the problem with the js community is that everyone strives for perfection, but as a result, you end up with all of this complexity. it's not difficult relative to these frameworks, to build a custom jsx transform, with signals, rendering for ssr, ssg, etc, and end up with a relatively small bundle. those are *all* of the things you need to build applications with good dx and a great user experience. you don't need extra bloat despite what they all market and tell you.

[@vigneshwarrv]

@@angelurena Not all abstractions are good you know. For me, Good Abstraction means that you never need to know the implementation details in order to get things done using it. Example - HTTP, Web APIs in browsers, html tags, css properties are good abstractions. They do what's they been told to do while abstracting away the implementation details. but framework and libraries are not abstracted good enough these days. why there are so many version updates on frameworks and libraries these days? I see it as improper abstraction

[@Shazam999]

As for "broken", you've never dealt with IE.

[@awesome-coding]

I actually did. The thing is that everybody agreed IE was bad, and just dealt with it. Now everybody thinks their framework of choice is amazing, when, objectively, they all kind of suck...

[@Shazam999]

@@awesome-coding Whenever I think something's bad in the web world, I think back to IE4 and its memory leak whenever a form was rendered.

[@dwighsonPavion]

I think that to get to the point that this approach gets widely adopted, we also need to realise that there is no such thing as front-end or back-end developer. You're either a developer or you're not 😅 Front-end devs are scared to lose their jobs, Back-end devs hate writing "css". So yeah it might take a while.

[@awesome-coding]

I think the first step would be to call backend & frontend devs just "devs", and people doing UI and CSS "designers".

[@dwighsonPavion]

@@awesome-coding exactly 💯

[@Wielorybkek]

very soon people will reinvent JSF

[@awesome-coding]

This is a joke very few people on this channel will get😅 Go PrimeFaces!

[@Wielorybkek]

​@@awesome-coding I had to google it and hooooly cow, what is this sorcery

[@someone-new811]

I don't see any drawbacks in the current state of web development and it is NOT broken, not by a long shot. It's evolving... Yes, there is a plethora or frameworks, libraries etc. But this doesn't mean that its bad. Choice is only beneficial and new ideas are always welcome. The one who never tries something new, does not accomplish anything. As your example of server side hydration, I find it totally wrong. First and foremost you can handle most backend stuff with Nodejs. As for the complex, enterprise level stuff... look no further as to Netflix - it consumes around 15% of global Internet bandwidth and runs Nodejs microservices as containers, and then say something about Nodejs being not scalable. I see the TS/JS community as a driving force in the current Frontend ecosystem and a significant player in the Backend. Sure, golang, rust, to name a few are really good and they advanced the backend development way further, no questions asked. But at the end of the day - it is up to the software engineers to pick and choose.

[@awesome-coding]

I might be wrong, but Netflix is mainly running a microservices architecture mostly written in JVM Languages on the backend. Heck.. they are famous for open sourcing Java libraries like Eureka, Hystrix or Zuul and making contributions to Spring Cloud. So I don't think they use Node JS on the backend, other then for supporting UI via SSR - I might be wrong though. Regarding hydration, I'm not sure why that might be wrong. Qwik's main selling point is just that - "Hydration is redundant, and we have a better alternative". Astro's pretty much the same - Let's to SSR whenever possible, and only partially hydrate (preferably also in a lazy manner) only the bits that really need interactivity. As for Go and Rust, sure they are good, but they are nowhere near having a chance to shape the future of the backend any time soon. Java and C# (.net) are miles ahead when it comes to adoption rate and overall support and both stacks enjoy large budgets and talented teams who push things further. Don't get me wrong, I like Go and Rust as much as the other guy, but these are mainly in the mainstream because they get views and clicks. Nobody is going to watch a Java video, just like nobody is going to watch a React video. Finally, the issue I tried to outline in the video was not the number of exiting options, but the direction in which the ecosystem is going and all the iterations people (me included) were eager to adopt, just to end up being deprecated in a couple of years.

[@someone-new811]

@@awesome-coding are you sure about that? kzbin.info/www/bejne/fpDMfGqgrNySoJo

[@someone-new811]

​@@awesome-coding I guess the main selling point of ssr and TS/JS on BE in general is isomorphism. You have full stack developers out-of-the-box. And the technology came a looong way. If you would told me that one could run Javascript on a server 10+ years ago, I would laugh in your face. Also you haven't touched on one important topic: tooling. As I mentioned Javascript ecosystem is still in the evolution process, new tools come out of nowhere i.e. Vite, rollup, Deno or Bun. Yes it's hard to predict what will get steam and flourish and what is gonna be obsolete in a couple of years. But see the bright side: you'll have a job to modernize someone else decision to pick a technology that didn't took off ;). oh and in case you would like not to be deprecated or irrelevant in a couple of years, pick one of the established frontend offerings (React, Vue, Angular, Svelte may also be fit in here after being backed by Vercel).

[@brokula1312]

Not sure what is broken...complexity has to live somewhere. I just use Nuxt3 and it's fine. Don't really care about shaving off 3kb or reducing loading time for 100ms. No one really cares. Rely on cache for speed...If you're really so impatient than F U....I don't care. I can wait for an app to "download". We do that all the time with native apps, and somehow people want for web apps to be instant while having media rich full blown UI in under 3kb. But Mom, how can I put an elephant into a shoebox???

[@dpgwalter]

The problem is a lot of the complexity really doesn't need to exist in the first place. Most applications you and I build are simple websites that serve data from a DB, with some interactive elements (like a chat) that can be fixed by polling for data regularly and inserting it into the page.

[@awesome-coding]

@dpgwalter This. The problem is that frontend devs live in a vacuum where they don't need to worry about performance or resource consumption. Things got so bad a couple of years back that everybody is running back towards the server because, of course, there is no reason for you to download 200kb of data and eat 100mb of memory to render a news feed on the screen. On the backend you have available resources and hardware costs keeping you honest. On the frontend it's either the bad network or the users device 😅

[@brokula1312]

@@awesome-coding What vacuum? If 200kb to download some scrip that will end up cached on a client and load megabytes of images and other media....why even bother with 200kb? It is only on web that we expect for a server to render a client. Idiotic. Sure, if you are displaying a simple 1995 style list, server "rendering" is fine, but rich apps do require much more interactivity, animation, media, etc. What is next, server should render every animation frame? The year is 2023, web is NOT what was made for and looks more like app store then hyper linked text. So don't bother with kilobytes...having 30kb of gziped framework is FINE. Guess what...you'll have images bigger than that. But hey, if you want disable JS altogether and enjoy your "pure web experience" then come back and share the experience. Than come back after a year and make "new" trend with an article titled: "You might need Javascript". Revolution! It's like that time when people jumped on Dan Abramov's hype train with Redux...an obvious idiotic idea, but yes, FB said it so it must be great...let's write a bunch of boilerplate to mutate one variable. Now we need web purist telling us how we should be afraid of every downloaded byte because someone somewhere in the desert with 1G connection won't be able to download the script on his Nokia 3210. People get upset for not being able to watch HD videos and here we are, shaving every byte like it's a dawn of computing.

[@I_get_to_start_my_bucketlist]

Rich features, handle complicated business logics, reusability, ....so many aspects lead my conclusion. Simplicity is mirage, pursuit for it is futile and pointless. Say you can come up with some new framework tomorrow to hide all these complexity of mess code. Then maybe VR will take over web tomorrow , and render your framework obsolete.... Don't bother.....just pick the most convenient tools/framework/libs Craftsmanship seems to be the least valuable in IT business....

[@awesome-coding]

You sound as burned out as I am. 😅 "I'll just build it the quickest way possible, it's not like you guys really care about quality or details" - am I right?

[@bear458ziif-s]

the react community is a cult. it's frustrating that when you offer constructive criticism they take it as a personal attack. they could reject constructive criticism and respond in a respectful manner. they choose to be smug and believe they know everything. everyone else that disagrees is wrong and doesn't know anything in their mind.

[@turolretar]

Stop this madness

[@AlexanderMazuruk]

You are starting by saying "frontend" keyword but quickly dragging into full-stack territory occupied by htmx and friends(low js/calories approaches) This is not a frontend anymore. With that approach you are mixing/coupling everything with everything. Nothing from what you'll build htmx way can be reused in isolation nor developed in isolation by separate teams contributing on the same project. How would you suggest to mock partially the backend endpoints and/or switching endpoints between environments say dev/staging/prod? when you are hardcoding each bit of the url in the htmx attributes along with i18n loading translations from different sources? The objective you are following is smaller number of code lines, not the separation of concerns :)

[@awesome-coding]

I get where you are coming from, but here are two points that come in my mind. - Component reusability is most of the time a myth - at least in my experience. After a point, people drop reusability in favor of speed of development and simpler maintenance. This is at least my experience while working on both small and big projects. I might be too dumb to do it, or maybe I was not lucky enough to find Product people willing to pay time & money for the promise of building reusable components which might be useful one year from now. - Separation of concerns applies for frontend apps until meta frameworks got in the mix. You now have the option to query the DB directly in the route handler, or, even worse, execute queries directly in your React server components.

[@ryo_5748]

If HTMX is right, as you say, then perhaps I should be prepared to move away from our favorite front-end frameworks...

[@awesome-coding]

This is my take: - If you really really need an SPA - use Solid; - If you really really want to use a meta framework - Use Astro + Solid; - Use HTMX or something similar for anything else (but think twice if you really need HTMX, or if you can do without a framework / library).

[@ryo_5748]

@@awesome-coding Thank you for your kind advice. I'm going to follow your opinion, but I hope your opinion hasn't changed in a year 😄

[@awesome-coding]

@@ryo_5748 Oh, and if you are just looking for the safest option to easily get a job in the industry it's still React or Angular, and this will not change any time soon.

[@ryo_5748]

@@awesome-coding I fully understand that reality and ideals are often far apart (^^)

[@awesome-coding]

@@ryo_5748 Well said :D

[@szmarczak]

Alpine is not zero JavaScript (e.g. for loops). Misleading.

[@awesome-coding]

You are right about that. Thanks for clarifying it

[@unironicdev]

Bad video, called 10 - 15 years of innovation unnecessary and then tooted "just use solid".

[@remsee1608]

“Innovation” that powers bloated web apps and closed source control

[@sentinelaenow4576]

Why not just do everything wrong that hype seeking juniors did for the last 15 years again and again and again and again? It's been 15 years naive devs are forever stuck in the vicious cycle of trying to replace JS with more JS because the propaganda told them so, jumping to the next hype crap with enough advertising bugdet, just to realize how awful life gets, or even worse, becaming depressive because they think that's anything close to webdev. Guess what, you're doing it again. Savvy webdevs know HTML, CSS, and JS are enough for everything in the most easy, powerful and efficient ways. WebDev corporate propaganda and its naive minions are broken crybabys. "Modern" webdev, as corporate propaganda says, is just a bunch of middleman trying to profit and herd developers, trying to replace the last week hyped framework, and naive devs fall for it, and start reselling their propaganda. Dev naivety is broken. The web is not broken, it's more powerful than it ever was.

[@naranyala_dev]

HTMX, HTMX, HTMX

[@vojtasks]

We should definitely learn from past mistakes a do not write jQuery again. There was a history when we learned that we don't *just write* such simple apps.

[@awesome-coding]

It is worth mentioning that browsers are also completely different from 15 years ago. Remember that React came up with the Virtual DOM because the DOM was too slow. These days it is pretty much unanimously accepted that the DOM became good enough.

[@Winnetou17]

WTF, jQuery is awesome, the only good thing that JS landscape produced. The only library which actually cared about its design, who actually is simple and powerful. And not bloated. It is because it was that easy and powerful that people started going to stupid places. Just like people having easy access to powerful cars leads to car chrases and road fatalities. jQuery is awesome.

[@awesome-coding]

@@Winnetou17 and this is why it is still used in more than 75% of the websites on the web.

[@vojtasks]

@@Winnetou17jquery is awesome, but the paradigm in which it operates is horrible.

[@bradyfractal6653]

I love your videos but I can’t listen to them when you talk like a robot trying to sing karaoke … it’s so unnatural and distracting that it I’ve had to mute the video and read the captions for the past 20 videos 🥲. Please just speak normally!!!

[@awesome-coding]

🥲 sorry to hear that - I literally have no idea how to fix this, and, believe me, not for the lack of trying. I'm just bad at voiceovers I guess 🫠

[@bradyfractal6653]

@@awesome-coding Haha I'm sorry, what I said was obnoxious. You're amazing at what you do and your videos provide me great value on a regular basis... so don't sweat it!!!

[@awesome-coding]

@@bradyfractal6653 No worries! I actually value real feedback so I actually appreciate it. The sound quality is something I definitely need to improve.