I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
Yes, it's definitely worthwhile moving past jQuery, but no you don't have to do everything described in this article.
There's a lightweight framework called Mithril that when used with MSX will give you the feel of React, i.e. the state of your app flows in a straightforward way from the state of your objects, rather than from a series of imperative jQuery operations.
Just start with this example and customize to what you want to do:
This comment is kind of ironic, isn't it? OP asked whether he has to use a framework (albeit a seemingly-complicated one) and you suggest another framework for him to use. Not saying you're wrong, or anything. I just found it kind of funny.
What comment are you referring to where someone asks whether he has to use a framework? The comment I'm answering is this one:
I guess I'm behind the times in that I still use jQuery. Is it really worthwhile to go through everything described in this article to create a simple filterable table?
There's a vast difference between everything described in this article and using a framework.
if ALL you are displaying is a table, then you can write a quick little jQuery(or native JS) function to remap the array and re-draw the DOM.
If your fancy little table is part of a large app, or even a simple app, it is much easier to implement the entire app using a framework like Angular. The model view concepts really help to tie things together.
Even for trivial SPAs it's often easier to roll the basic functionality yourself. Flipping over to something like Angular introduces technical and cognitive overhead that often isn't worth the trouble for something simple.
It depends on where you draw the line for "trivial". Does it need routing/browser history? What browsers are you supporting, any legacy ones? Does the frontend do any kind of translations or visualizations with the data it's getting from the server? Does the layout have a bunch of panes and reusable views? Do you want your frontend code to be testable? All of that is an order of magnitude simpler using an actual SPA library or framework. And if you're not doing any of the above, you're probably better off making a server side rendered app with some AJAX sprinkled in anyway. At that point making it an SPA at all is probably overkill.
The huge frontend frameworks have an upfront learning cost and tend to be unfortunately leaky abstractions, but they're still much easier to maintain than a jQuery/JS mess with a bunch of DOM-manipulation code and HTML strings living right next to the business logic. They at least force the code into an understandable architecture and separate the view from business concerns. Experienced developers know how to structure their frontend JS already, but novice ones--the same ones that would feel the pain of learning a framework/ecosystem on top of JS when they first try to pick it up for an SPA--almost certainly won't.
Except then, no one else on your team has any idea what is going on and spends hours making minor changes. And it's probably not tested because jQuery is generally quite a bit harder to test so everyone is scared of making changes.
One time I directed an intern to implement an in-browser list filter functionality using an existing open source library. When I saw his work, he didn't use it. Indicated that he didn't fully understand how to use it. He wrote his own implementation using jquery. It technically worked for the few test cases we tried. It was a mess to look at, with Jquery hooks all over the place. Argh..
What about maintainability? You want everyone who touches your code to figure out your custom solution for data binding? Or you could just follow the conventions established by an industry popular framework that is instantly consumable by another developer?
But that's just the problem with the modern proliferation. Finding a developer who is proficient enough in all of the frameworks you might be using is difficult. It's not enough just to have a JavaScript developer, you have to specify about 20 frameworks that you are using. It's not possible to train everyone in all of these, so then, even your framework system becomes personal, because it is setup to your personal choices (much like a custom function!). Since new people can't reasonably be required to fully understand the totality of the system, they will still come up with personal hacks, precisely because the set of things to know is too large.
Remember, they don't know which part of the framework you are using or not, or which parts are important or not, so even if you are using it for one little thing, they probably have to learn most of it to understand how it interacts. Since so many frameworks overload standard functionality, it is impossible to know how a framework interacts with your code until you know all of these things.
Using 20 frameworks is about as efficient use of your time as having one you built yourself. The sweet spot for a medium-sized application is using 2-4 (maybe a few more if they are really standard or do really specialized functionality - i.e., a PDF library) for the most critical components, and still maintaining the remaining quirks yourself.
So, for example, Ruby-on-Rails + Bootstrap + JQuery goes a very long way, and doesn't put an undue burden on people trying to get to know your code.
Very few teams have the opportunity to switch later on, and if they do, it's at the expense of the job of the person who chose to go without a framework.
Everyone has to refactor into new frameworks later on. Going without a framework early on doesn't add an expense, it actually just subtracts one. It is only if they had chosen the framework (and other code decisions) with perfect future vision that this cost would be mitigated.
I estimate that every 20% that a codebase grows it needs some amount of refactoring. Definitely anything that moves from skunkworks to production will need some pretty heavy rewrites, and will probably need a framework that better meets its newer needs. The question is how much cost was sunk in getting there. The refactor will have to happen no matter what.
what is that complexity threshold? Self determined no doubt.
Guy A believes his custom design is simple enough to comprehend by anyone. Guy B doesn't agree.
It doesn't really matter at the end of the day. If you work in a team environment, the toolset will be pre-determined already. You don't have a choice.
No, not for a simple filterable table. Stick with jQuery for that. If you start to have many filterable tables that change based on multiple other criteria and live-update based on new data from the server then you should start to think about using a full-on frontend framework.
Just start with this example and customize to what you want to do:
https://github.com/insin/msx/blob/master/demo/index.html