I use server side generated HTML pages with progressive enhancement using JQuery (I prefere it to plain Javascript). Not complicated and works very well.
Of course this is not popular/cool, though.
Of course this is not popular/cool, though.
As for being cool, my opinion is that shipping stuff is cool, and if your project is maintainable that's very cool no matter how you do it.
It's odd that we're coming up on 2020 and software projects checking their dependencies and overhead against their goals is still seen as a matter of fashion. KISS isn't sexy, and doesn't sell consultant hours. Those are features, not bugs, IMO.
I have a ton of worry about other devs, especially ones with no React experience walking into my code though.
With jquery it is totally reasonable to expect anyone who calls themselves a front end developer to have a working understanding of it. Can’t think of any other JS framework that can boast that.
They generally have the form:
document.addEventListener('DOMContentLoaded', function() {
var m = {
...model fields...
_observers: new Set(),
notify: function() {
this._observers.forEach(function(observer) {
observer();
}
}
};
var elem1 = document.getElementById('...');
elem1.addEventListener('...', function() {
...update fields on m...
m.notify();
});
m._observers.add(function() {
...update elem1 from m...
});
m.notify();
});Huh? Wrong decade I think. jQuery wasn't released until 2006.
Like, in vanilla JavaScript, you have a single global tree representing the state (the DOM), and you write event handlers that manipulate that tree. But that isn't a good fit for every use case, so you introduce React, which encapsulates all your functionality into components.
But that turns out not to be a good fit for every use case, so you add a state-management library like Redux on top. With Redux, you have a single global tree representing your state (the Redux store), and you write actions that manipulate it.
Congratulations, you are now back where you started, but you've introduced two third-party library dependencies (probably more, if your libraries need separate adapter libraries to work with one another) and a bunch of overhead and complexity.
See also: client-side navigation. "Pages on my website load slowly because the browser has to run all the JavaScript I wrote. How can I solve this? Oh I know, even more JavaScript!"
"State management" is a problem you think you have only because you're trying to use React for things it isn't good at.
For all the other cases, I don't see any reason to use one, and my experience of the same application developed, by different people, with and without a reactive store, tells me that the solutions without a store are generally much simpler and look way more maintainable.
If you 'encapsulate' every tiny bit of information inside GUI components you end up with things like storing a string in a GUI label or storing a list in a list selection component. Then every time you want to access that information you have to extract it from the GUI, possibly keeping in mind the lifetime of the UI components.
Just, you know, have simpler problems?
SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with.
¹ one common tool in the pipeline actually being called babel never fails to amuse me.
I think a lot of these issues are symptomatic of front-end oriented toolkits trying to solve combined frontend and backend issues, causing oodles of arbitrary complexity.
It's hugely beneficial for some kinds of projects/teams, but so much of the challenge is simply due to domain impedence and using suboptimal tools for the job. Client-oriented solutions to server-client issues have some fundamental limitations.
Now if you have a very rich client side desktop-like application, such as:
https://www.tradingview.com/chart
https://ahrefs.com/site-explorer
or if you are Facebook, then maybe a SPA is required.
(by the way, I picked those two examples because I'm pretty sure they do not use a SPA!)
Using jQuery will just make you suffer in the end. You end up having to write loads of code to manage the state of the DOM and it just gets more complicated as your project expands.