| I still use jQuery and won't be ditching it anytime soon. End users don't know or care if an app uses it or React/Angular/Vue. I've built SPAs with it and don't see why that's a problem for others who've mentioned it, but that's because I don't know what specific problems they ran into. I've not run into any. But, I also use CouchDB as a backend, almost all my app code is JS running in the browser, and I don't use Node.js at all. I still do my server side work in Perl. So I'm not building apps like most are right now. React/Angular/Vue, etc, might work better for some apps, and/or apps with a zillion users hitting the server a zillion times, but my apps don't have either of those issues to deal with. They barely touch my web server or the CouchDB. All the heavy lifting is done in the user's web browser. The only real downside to that design approach, if we choose to call it that, is that we don't track every click a user makes, but as a user I really like knowing that. The best thing about going with jQuery is I didn't really have to learn how to use it. I do that on a need to know basis and generally go to Stackoverflow where I almost always find the best way along with a few other ways to do something. I'll offer that using a "much smaller, lighter weight library" offers a kind of a false sense of gain. You can use Service Workers to cache jQuery on the client side, or a CDN to deliver it, so it's not really costing you much (or any) bandwidth to deliver it to users, and modern web browsers are not choking on the size of it. I test my apps on a old Raspberry Pi running their latest OS and Chrome and they're plenty fast (very fast). Here's the thing. I spent about two months looking for the "Best" way to build apps. Most of that time was going over frameworks at TodoMVC.com. When I was finished I didn't have any better idea of what was best than when I'd started, but I did have a clue about what I'd have invest to get up to speed with them, and in most cases it was lot. So, I decided to instead explore what was the easiest way, and not just for me really, though I don't expect anyone should agree, but just generally speaking I tried to consider that. I use the Apache web server and CouchDB, PouchDB.js, jQuery, and Bootstrap. It's a pretty amazing feature set those tools provide, and how easy they are to use together. Almost no one I know does it this way. |
The main thing it provides is a sane toolset for what I was already slowly moving towards, which was templates in script tags (grabbed through jQuery), and my own home rolled templating in JS (it's just a few lines for something minimal). I get some JS from the server (or serve it on the page), and use a JS class to build the representation for display, but this allowed me to easily build the initial page and also get updated without a complete page reload and reliably update the page.
Vue is basically the same thing, but taken a few generations farther. You have a data structure, you define how to build the HTML from the data structure, and Vue tracks the data so if you change one five levels deep in the data structure, the page just updates accordingly (and it only updates the things that change, so half entered forms/text boxes don't lose all their state.
It's nice to just have to serve JSON, or a minimal HTML page with some JSON data in a script tag. No mixing Perl templating, and HTML, and JS anymore. At least for a select few new things I've deployed. It's not like I can just replace everything. I also forego the whole NPM and deployment stuff, and just include Vue with a script tag, and write my components either on the page, or in a JS file (or set of files) I can load, depending on whether the components have any use outside the page I'm writing them for. Dead simple.
If you haven't tried it Vue (and you very wel may well know everything I just mentioned about it already), I suggest you do one of the quick online tutorials to get an idea. It's actually a pretty cool idea (and since it's hard to get away from using JS anyway, you at least get to cleanly separate the front-end from the back-end).