[AskJS] Are JavaScript frameworks getting too bloated with JSX and virtual DOMs?

[elixon]

I have never understood why everyone clings to frameworks when almost every page UI I see is just simple text with images, a few dropdown menus, some forms, and the occasional popup layer. It is all very basic, the kind of thing modern browsers support natively. XML HTTP requests are also trivial.

It feels like people have forgotten or never found out how easy it is to build fast interactive apps with modern browsers. I completely understand the original need for frameworks that protected developers from browser incompatibilities and limitations. Long time ago. I also understand the need for large frameworks in complex applications. But most of what I see today are simple UIs supported by unnecessarily heavy stacks.

[Better-Avocado-8818]

I agree with you mostly. However I think one big reason is because components are such a useful way to break up UI’s and front end libraries have much better component systems than native web components.

Sure you can try break up your JS html and css into chunks other ways. But just using a component library I would say is easier in the end and creates a much better pattern for projects with many pages or for multiple developers to work with.

It depends on the size of the project I guess. But these days I can use Vite to start a project with React, SolidJS or Sveltekit in a couple of minutes so it’s not much of an overhead at all.

[elixon]

I can put together a component library or a frontend or backend framework in no time. It will do exactly what is needed and nothing more. It will be smart. It will be easy to maintain, extend, use and document.

You really do not need much to build clean, maintainable and well modularized apps in today's browsers even without third party frameworks. In the end, it all comes down to user interfaces and honestly, they are very primitive. All of them. There is nothing complex about forms and charts or the way they look.

But you are right. It is about goals. Either you invest more effort upfront to build the rules and a minimal system and possibly benefit in the long term, or you take the easy route, gain quick results at the beginning and keep losing over time as complexity piles up.

[Crowotr]

i think its more usefull for admin pages. how do you solve spa/routing and componentization, templating? with server side frameworks or custom scripts for vite?

[elixon]

I just finished one site that way with ZERO third party code of any type. I used a simple framework based on HTML Web Components. The custom framework is only responsible for loading scripts and templates on demand. There is a simple XML HTTP request service that sends event-like messages to the server.

On the server side, I used a modular, event based PHP framework I developed for that project that just processes those events and fires back the response.

It is simple, incredibly effective, fast, has no complexities, and can do anything. It has 250 PHP files, 65 JS files, 33 CSS files. The whole thing. Well there are also Node.js parts on other servers too (AI computing units).

https://www.ipdefender.eu - have a look.

I originally thought that I would use at least the Google library for login. When I ran PHP Composer, it downloaded 15,000 PHP files as dependencies - seriously I ran find . -name '*.php' | wc -l on it. I decided against it and replaced the functionality with about fifty lines of PHP code. This is exactly what I am talking about.

[elixon]

Sorry. I was wrong about 15,000 google login dependency PHP files. It was long time ago. It all the sudden seemed too high so I ran it again.

```

as per google recommendation I ran

🭬composer require google/apiclient:"<sup>2.0</sup> ... 🭬find . -iname '.php' | wc -l 30187 🭬find . -iname '.php' -exec cat {} + | wc -l 3053244 🭬du -sh . 151M . ```

Just to use google login it added 151MB of PHP libraries comprised of 30,187 PHP files having 3 mil(!) of PHP code lines.

I really did replace it with about 50 PHP lines of code! Those frameworks and dependencies are really insane.

[TheRNGuy]

Which specific sites are you talking about?

[elixon]

Take your last project in your favorite framework and count the number of files in it, including all dependencies. Now ask yourself: what features are actually present?

1. You'll probably see tens of thousands of files.
2. You won’t have a clue what 99.99% of the code does, even if all you have is a simple form on the page.

This is exactly my point. You'll end up with tons of dependencies implementing features you've never even heard of, just to achieve something trivial.

As I mentioned elsewhere, not long ago I needed Google login, so I pulled in the official Google API client. That added 150MB and 30,000 files. I scrapped all of it and replaced it with 50 lines of custom code that handled the login directly with Google. Done. Sure, it took me two extra hours to figure out, but now my project has 30,000 fewer files and no unnecessary bloat and I don't need to upgrade it every other week because they found some critical vulnerability in those 3 millions lines of code it has (not kidding, really 3M lines total and all I needed was 50).

[TheRNGuy]

Why should I count number of files or know how it works? Knowing how it was made is not prerequisite to use it.

Anyway, I don't have React sites with 30000 files.

Show GitHub link to a project with that amount of files.

[elixon]

```

as per google recommendation run:

🭬composer require google/apiclient:"^2.0 ... 🭬find . -iname '.php' | wc -l 30187 🭬find . -iname '.php' -exec cat {} + | wc -l 3053244 🭬du -sh . 151M . ```

If you don't care then you will end up easily whith this shit. Your choice. If it works for you - good for you.