4 ms·
I'm all in for reducing the usage of frontend heavy frameworks, but I also agree that as soon as you start with the "sprinkles" you're opening the pandora's box
by likortera 4y ago
I'm all in for reducing the usage of frontend heavy frameworks, but I also agree that as soon as you start with the "sprinkles" you're opening the pandora's box in the long term if not using state based ui rendering (what React, Vue, etc give you)
Example:
I have an application where a form input expects an URL. As soon as any URL is entered, I need to:
1) Provide feedback on wether that's a valid URL or not, before the user submits the form
2) Show a suggestion for a page title, which is usually the <head> title extracted from that URL. If the user clicks on the suggestion, that should become the value of the next input in the form.
Other than this, this is a pretty basic form. But how do you give a decent experience without JavaScript?
Right, a bit of jQuery would do it in this case... but then more and more similar small tweaks are necessary, and before you realise you're swimming in spaghetti.
- mod 4y agoThe idea that we should use react to do a form input suggestion... To avoid spaghetti code? I can't make that logical jump. If you can't keep that tiny bit of code organized, why do you want to pile on the entirety of react and why would that be more organized? Maybe you're saying it's a snowball of these things. I've seen that happen, but it didn't have to.
- likortera 4y agoI agree using React just for that is overkill. And yes, I'm talking about how it snowballs when you later get more requirements like now we need this dropdown to change accordingly, now we want to show validations as you write, now we need to check for email uniqueness before submitting, etc, etc... But, the worst part in my experience, is that without one of these "opinionated" frameworks such as React or Vue, each new developer that joins the team (after others leave) have a total different idea of how to organize the code, or they have a hard time understanding the "custom" organization and ideology behind the structure you've had to invent to keep in maintainable. Again, I'm not a fan at all of frontend heavy frameworks, but they do solve a real problem, specially in large apps and large teams or teams with a lot of turnover. I'd say it is the exact situation in the backend regarding using Flask vs Django, Sinatra vs Rails, etc... having a set of imposed opinions and structure have long term benefits as soon as you're not the only one working on the codebase.