Why has web development become so complicated?

I'm learning React with JSX . Why is JSX even necessary? HTML works fine. Its simple and gets the job done.

I can't stand the node_modules directory either. Opening it up reveals what seems like hundreds it not thousands of dependencies that all have their own recursive node_modules folder and the dependencies continue.

Why are we creating more unnecessary abstractions on top of more unnecessary abstractions? What happened to K.I.S.S?

What was wrong with vanilla Javascript and becoming great at that and using just that?

you'll love the simplicity of
https://svelte.dev/
Svelte

@heyheni

Thank you for this, I hadn't heard of it. It looks very interesting.

Jsx isn't strictly necessary but it's convenient. I work with angular and if I want to inline a small template I have to do it as a string. Not super elegant in comparison.

I think KISS still very much exists but in a different way. For you as a developer it's easy. Yes react and angular are mega complicated projects but you don't really need to understand them to create something that works nicely.

I think creating a well designed SPA with something simple like jquery is 100x more difficult than with something like react.

Also you really shouldn't have to care about node_modules most of them are subdeps that are out of your control anyway.

@N0ps
It's actually a little more complicated than a string. It's language service integrated and a performs an intermediary computation so the symbols in the abstract syntax tree can be analyzed by the language service. Thats how you end up with having symbolic completion features in the IDE for template variables. It's significantly more advanced than what react uses, and is actually still 100% conforms to both html and the web component standards.

@SortOfTested yes I know angular compiles it's "HTML" like language. But the point I was trying to make is the way Jsx represents it's inline documents isn't half bad. It's certainly cleaner than just putting it all in a template string. Having said that except for one liners I don't like the idea of inline templating that much anyway

@N0ps
We can agree to disagree on that one. It feels like a regression back to asp/servlets for me.

Blazor all the way baby

the problem is not in jsx, react angular or whatever, the propblem is in using "cool" tools that's not suitable for the task at hand, I don't exactly know what is your level and what are you trying to achieve however it is true that sometime a framework is an over kill for some tasks, yet that's very rare as there is a certain level of abstraction and reusability won't be achieved without a framework, let alone future maintaince and extendibility.
that being said asses your own situation and if you are working with a team never hesitate to ask, why are you using react for this situation,
if you are curious why react are using the jsx approach actually they have discussed that in "rethinking best practices" just google it.
web development never been simple it is now more mainstream that's it.

@N0ps "Also you really shouldn't have to care about node_modules most of them are subdeps that are out of your control anyway."

That's exactly why you should care because you have no idea what code by whatever fucker somewhere in the world you're pulling into your project. That ought to make you concerned!

@Fast-Nop
There's an npm package for that 😎

@Fast-Nop good luck. I've tried it's a fucking mess. I just build my frontend stuff with js and don't care what's in the subdeps and my secure backends are JEE or PHP

@N0ps So you don't care what code you deploy to your users? It could be a bitcoin miner, but you don't give a fuck as long as your server isn't impacted? That's great.

When I make a website including frontend, I tend to just make static pages.

I used to go for Yesod framework for the backend, now I use rocket.rs — with both I get sub-10ms page loads, when using integrated SVGs, Redis-cached postgres data, and clean page layouts.

We invented AJAX because whole pages were slow to refresh on dialup. Then broadband came, and instead of saying "hey we can do static pages & full page loads again", we made pages heavier, by making heavier specialized AJAX loaders with routing frameworks, moving more and more logic to frontend.

Then we started to notice that people's poor slow Chromebooks couldn't handle all that SPA shit, and we started doing shit like SSR... Really? You move backend work to frontend to lighten the backend, then emulate that shit in the backend anyway?

If you just keep the whole page under 100kb... You solve that whole chicken & egg problem.

Of course, this is all argued from the point of view of a backend guy. 🤷

@bittersweet
Well, the smart people started doing selective SSR because of impression time requirements of marketing. Then a bunch of bootcamp grads were told "no spa!" and had to figure out how to use their limited skillset on the backend. Your standard lavaflow antipattern.

@SortOfTested I do feel like we're almost at the point where companies start using an Android phone emulator written in webassembly to display their mobile app inside the browser.

@bittersweet
Microsoft is basically there. Blazor runs aspnet on top of a mono runtime that pushes updates through javascript.

@bittersweet I think SSGs are vastly underused. It doesn't get faster than an Nginx reverse proxy spitting out static files.

I started a website for a project some years ago when the "natural" choice would have been WP, but I found the tech stack insanely convoluted for that purpose, so I went static.

Since the server itself is managed, I don't have to do anything. No weird updates including Gutenberg, no breaking shit, no security hassle, no hacked website, and the performance is insane.

Also, no gigabytes of JS trash from all over the world that compile down to "just" 1 MB over the wire.

React with JSX, Redux, Axios, webpack, and all the bells and whistles end up as just a bunch of JS files being run in an HTML page. You can do more or less the same with your own HTML and JS because the browser does not really care.

It is for us devs who choose to work with packages that abstract away a lot of repetitive and long routines and structures, letting us work on a higher level of abstraction.

It is a choice to engage with extra syntax and ways of doing things in exchange for reducing how much we have to worry about redundant and bug-hazardous code, that the extra libraries and frameworks cover for us with the assurance of a higher level of testing and community-contributed features.

Sure, it is extra learning and managing more packages, but that cost is easily outweighed by the convenience provided as the project scales.

I am a believer in the doctrine of keeping the number of extra bells and whistles as roughly proportional to the scale of the project.

Threads like this fascinate me. I literally only know a few of the acronyms and key words. The rest is like a foreign language. It also seems like a lot of JS programmers are angry too. So that makes things more interesting.

"itS jUsT JavAscrIpT" <----- no it ain't. Honestly, not everything needs to be a microservice, I don't understand why people got so crazy about it and if anyone asks I have been developing websites and entire web platforms since 2010. Monoliths are really not the end of the world as the people that are all about React made it out to be. I have seen the simplest programs made into a huge mess of node dependencies because someone wanted to add React to their CV. It ain't worth it and damn near more than half the web developers I know ain't building something the scale of Facebook to warrant the use of ANY JS frontend framework.

@AleCx04 It's also about the long term cost. Some library has a bug or even security issue, so you have to update that. However, that also pulls in a slur of dependency updates that break some other shit. You spend time and money to set the mess straight again.

Sure, e.g. payment solutions shouldn't be developed in-house. That would be crazy with PCI compliance, different currencies, different VATs and automatic customs handling for international sales.

But in general, web devs havn't understood that dependencies are at least as much of a liability as an asset, and that complexity in itself isn't something to strive for.

@Fast-Nop nailed it! exactly, and this is one of the reasons why the web ecosystem is such a huge monster now. I have seen many people turn an otherwise simple project into a mess of dependencies. Sure, with node one can lock the packages to prevent dumb upgrades, but the breakneck speed in which everything moves there severely makes it an issue in terms of maintenance.

@Fast-Nop it's not that I don't care it's just that it's literally impossible. If you're telling me that you're hand auditing every single subdependency and I don't care in what language you're programming in I'm calling bs.

Also stuff on the client side like bitcoin miners would be cought instantly during development. We don't just blindly pull deps we have a lockfile

@N0ps The solution is not to use an ecosystem which pulls in code from all over the internet without you having any idea what exactly is fetched, to the point where some stupid "leftpad" broke thousands of websites.

And that's just breakage. Maintainers changing for the worse, or having their accounts hacked is a far greater threat.

The fact that this sad state of affairs is common in web dev just shows how fucked up the whole ecosystem is. That so many web devs thought this crap could be a good idea doesn't speak well for them either.

Today webdev seems to be about who can cram the most fancy external stuff into their website. I'm glad I got out of the enterprise dev market a few years ago. I now use 3 libraries at best that don't depend on each other. Bliss.

@Inxentas

That sounds like a dream. What kind of development do you do and what 3 libraries are you using?

@Polymorphism Mostly websites for smaller companies, using ProcessWire (PHP CSM + API) and a few JS libraries that change with the times.

I exchanged jQuery for AngularJS a few years back and I might hop onto the VUE bandwagon. But I get to choose when and why to use a framework: I am not learning them just to remain an interchangable employee. If only the pay was better :-p