61–70 of 176 posts
It’s been a minute since someone ranted about frontend frameworks. Take a shot.
And he ended up... creating frameworks himself. I fail to see the whole point of the article tbh. It's a rant against JS frameworks/libraries and the frontend in general all to end up admitting he did the same?
Well played. You got me to visit your version of the thing you complained about. :clapping-emoji:
Earlier quoted context omitted.
I write in vanilla TypeScript. I do not have any build step in my application. Since Node now supports native type stripping I don't have a compile step either. I just write my code and then point node at the main file, and this even includes front-end code for the browser.
Can you explain more about how the front end aspect works? I'm not clear how the front end code could by TypeScript without a build step, unless I'm misreading.
So many more problems solved… Those problems aren't 'solved'. The author has an implementation of a solution. It's one that they think is good, which is ace and I'm happy for him, but if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is…
Because you think whatever you want to pretend your web software isn't MVC isn't solved doesn't mean it's true. Oh brother, MVVM, Model-template-view (no offense, Simon), come on.
You define resources on an HTML page, the browser loads them, renders a page, loads scripts, and makes AJAX calls.
You don't need build scripts for this. More over, these frameworks and build scripts DON'T SOLVE PROBLEMS. They move them. They want you to become a React developer. Not a software engineer who writes web software.
They don't solve routing, because you rewrite it every year. They don't solve bundling, because you change bundlers every year. They don't solve event handling, because they just move the chain of calls where you define the listener.
It's all a lie.
Earlier quoted context omitted.
Can you explain more about how the front end aspect works? I'm not clear how the front end code could by TypeScript without a build step, unless I'm misreading.
Node strips types on all imported code regardless of where that code executes.
The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI.
Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" eventually gets patched in using a rube-goldberg-machine approach to architecture.
Labeling UI frameworks as artificial complexity is simply a sign of inexperience manifested as NIH syndrome. The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI. Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" ev…
Earlier quoted context omitted.
Node strips types on all imported code regardless of where that code executes.
Node doesn't run in the browser.
Earlier quoted context omitted.
Sure, and if you like working with the conventions and abstraction Rails offers that's great. Other people make different choices. That doesn't mean they're wrong.
To write good React you have to follow conventions, too. You can't get away from conventions. People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".
I don't doubt it. People make terrible websites with React.
However ... what might be happening is that you go to some websites, and some of them are great and others are terrible laggy garbage. When it's a bad one you open up devtools and see React, and that leads you to conclude that React is bad. But reality is that the good ones also use React, because most big websites use it.
Your reaction to the good ones is to assume they're well-built using whatever tech you happen to think is great (Rails, Vanilla JS, Vue, Svelte... whatever) but you're not actually looking. Hell, a great website isn't even a website, it's the experience of interacting with the business behind it. You don't even think about the tech when the website is actually usable.
Your reaction to the bad websites is to look under the hood, and you often find React.
That either means React websites are bad, or that React websites are good or bad, and it's not really React that's the issue. It's the team who built the site (and often not even the tech team; there's often some Product or commercial pressure that's driving the team to release something that's not really ready yet.)
Labeling UI frameworks as artificial complexity is simply a sign of inexperience manifested as NIH syndrome. The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI. Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" ev…
Not everyone is building complex UIs like google sheets. Most people are building static pages with a sprinkle of interactivity, or maybe form pages for doing CRUD.