jQuery UI(jqueryui.com) |
I feel like at some point I'll probably make a project with just jQuery and possibly jQuery UI for the sake of it: while what's there doesn't seem too flashy, it would probably work just fine for most web based CRUD needs. I might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery, but honestly something that you just drop in and that works has a lot of appeal. No complex toolchains, no configuring a bunch of plugins and registering them with the app, no endless abstractions for state management and things about render loops to keep in mind, just a silly JS import and writing some schlocky code that still sorta works.
I like to consider the UI of Kanboard as a good example. It's minimalist, but works great for what it is: https://kanboard.org/
> ...might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery
Not so with jQuery. You draw the change directly. You can write a framework on top of jQuery to achieve something similar where a model/state gets updated -> detect the change -> jQuery to draw the change. (That might be interesting or perhaps something like this already exists.)
In other words, in Vue, React, and Angular, you are discouraged from doing direct DOM manipulation; you always modify some state from which the framework applies the DOM changes and in jQuery, it's the opposite: you directly manipulate the DOM in reaction to some action. So the reason why people moved is that an MVC-aligned paradigm is ultimately more productive and a better abstraction than directly manipulating trees of rectangles.
JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser. In that model, the browser is essentially a terminal that renders output formed in the back end. JQuery was one of the early libraries to promote behaviour in the browser instead of "browser as terminal".
It feels like there's bit of a swing back to the SSR model, e.g. with the growing popularity of htmx [0] though there are still many strong proponents of the MVC-in-browser approach.
Even in that case, many of the fancy effects people used jQuery for can now be implemented in pure CSS. These days, when I'm working on a simple blog or landing page, I find that I don't even use much JS at all. It's HTML and CSS, not full-blown SPA frameworks, that have gradually replaced jQuery for me.
When I look at modern frameworks, all I see is unconstructive complexity that sucks productivity
I was doing consulting work up until a few years ago and it still showed up on a lot of projects, and the integrations were usually full of buggy spaghetti code. You can build low-quality apps in any framework, but the more full-featured frameworks at least to try to set the developers up for success.
Feels like they take the idealistic view of things versus pragmatism.
Non-confusing design, live-reacting to user typing the date with keyboard, accessible, configurable, and offering 0-effort localisation in 60+ languages[1].
Is there anything like this in React world?
> Is there anything like this in React world?
None in any world, to be honest.
It's amazing that most UI libraries go out of their way to make month and year selection as awkward and non-intuitive as possible.
I wonder if they ever had to enter their own date of birth on a form somewhere. Surely most of them are over 20 years old?
This is the first UI component lib I checked. I'm curious what's missing here in your opinion?
> Please remember jQuery UI is in a maintenance state: we’ll make sure the library is compatible with new jQuery releases and that security issues are fixed but no new significant feature work is planned. We’ll also try to fix important regressions from jQuery UI 1.12.1; older long-standing bugs may not get fixed. Note that this does not affect jQuery Core which is still actively maintained.
From the release notes of the latest release (October 30, 2024): https://blog.jqueryui.com/2024/10/jquery-ui-1-14-1-released/
Looking back now, we all were lead down a path of needless complexity. Even thought I'd never use jQuery or jQueryUI professionally now, I still have a voice in the back of my mind that will pop up every now and then to say "well, if it's not gonna be complex or long-lived..." when something calls for a quick UI.
I feel this way about Bootstrap and maybe now am old enough that I don't care if it upsets other developers.
Something like bootstrap seems so ludicrously non-complex that I don't think anyone competent should be getting upset with you for its use.
I mean, OK fine, go ahead and fanboy/girl Vue/React/(Needless complexity api) whatever. But really? They get upset looking through code for an HTML5/bootstrap page? Something's not right there. That's when you start suspecting they can only work in one api, and likely don't even really understand css.
I have to believe most of those components are still in use in production today. They were when I left in 2022.
The Widget Factory was awesome for its time and not well advertised.
Tonight we're gonna party like it's the year 2009!
I don't think there's any situation in which I would reach for this tool in the modern era. I'm honestly amazed that it has even managed to survive this long. But I guess if I had a working app already using this tool then there might not be a huge incentive to migrate away.
I miss these days.
https://github.com/jquery/jquery-ui/blob/main/ui/widgets/tab...
with the much better, much simpler, more readable and not at all depending on 42(!) modules (/s)
https://github.com/tailwindlabs/headlessui/blob/main/package...
What joy! (/s)
// inb4 oh but you don't understand anything... it's declarative
Imagine a big project with multiple teams.
Now they are building different components that all need to modify the state of the UI. With jQuery, it would be easy to create a UI state that your team doesn't understand and it's hard to trace exactly which mutation caused it. You're depending on a `div > div > span.firstName` and suddenly, someone injected a `div > div > div+span.firstName`.
When there's a model, it's easier to trace the model because our tooling (language servers in editors) can trace and track references. We can verify the behavior using tests by mutating the state of the model and then checking if we get the correct output state. This is also doable with direct DOM manipulation, but it's not as easy.
So ultimately, the "MVC-like" nature of Vue, React, Angular are productive for the same reason why MVC itself is productive compared to directly drawing rectangles.
Managing just your application's state, while letting some template logic know where to embed that info into the app, scales far better.
If you measure complexity strictly by the amount of code running, then a React or Vue app will likely be more complex. If you consider just the actual application logic, it's usually far simpler. This is especially true if you utilize components, which lend themselves well to rapid development with fewer side effects.
It's the same way on the desktop side. Writing everything in assembly instructions would technically be the least "complex", but it'd also be utterly insane and error-prone to do it that way. Even mid-level abstractions like C++ are hard to get right. It's why many modern apps are built in higher-level abstractions, because they're easier, more reliable, and fast enough.
It's really no different for a website. You can put all of your state in one place, bridge different libraries, and manually sync DOM changes, but you're essentially just frontloading the complexity. Abstraction is an important concept in structuring your codebase into clean and maintainable code, even if it is technically more complex.
I won't argue that React doesn't get overused for otherwise-simple pages, but many pages are not simple. The web today is full of interactions, tabs, dropdowns, search bars, notifications, modals, and tooltips. It all needs to respond to your device's form factor and input method. Every network request requires error handling. It needs to be routed, cached, and served smoothly and correctly.
It's a lot. It's a lot to manage in one layer. I am content to let some of that complexity be managed by Vue, or React, or whichever framework we're discussing. If it lets me worry just about my application's logic, and it simplifies the templating, error handling, routing, and so on, that makes things easier and less error-prone for me.
Honestly, I've written plenty of web apps in vanilla JS. I've experimented enough with closures, IIFEs, classes, and other techniques for managing state. It really doesn't matter how careful you are, any sufficiently-complex project will always turn into spaghetti. Frameworks help us stave that off, at least for a little while. Their component-based architecture makes relationships more explicit, and much easier to isolate. I particularly like Vue's Single-File Component (SFC) concept which organizes components into logic, template, and styling.
Not all frameworks require a build system though, and there's plenty of options available for tackling smaller problems. Alpine is great for reactive data. htmx helps manage apps with many server calls. You don't necessarily need the full React or Vue package, if your app isn't so complex.
But if it is, I think you'll be glad to have them.
To be frank, when all you see is "complexity that sucks productivity" I wonder whether you've ever tried to make a non-trivial SPA without them. You'll either end up building lots of spaghetti (like happened with every jQuery app I ever saw), or inventing your own makeshift framework that solves the same problems, kinda-sorta, hopefully-good-enough.
> I wonder whether you've ever tried to make a non-trivial SPA without them.
Many sufficiently complex apps existed long before React. The "OG" Outlook Web App was certainly not lacking in complexity.
The challenge is that it requires far more skill and a deeper understanding of DOM, JavaScript, and CSS. It requires being more diligent about encapsulating logic.
What React did was it made front-end more accessible to a wider audience. The skill barrier is lower (though traded for complexity elsewhere, IMO). Devs now probably start with React and Tailwind before learning raw DOM and CSS. The good ones will eventually learn it, the mediocre ones will vaguely know that it exists.
I do think that using either web components or Lit offers a nice layer of encapsulation and reuse as well as some convenience.
There are a lot of options nowadays.
I agree. To me, TWBS is just a collection of intuitive components that have been tested vigorously. They also function in a way that way people are used to because of their lineage. That they can be styled in a way that makes them not look stock...ices the cakes.
Afaik bootstrap is getting replaced by tailwind. Which is actually pleasure to work with.
By whom? Not by me.
> Which is actually pleasure to work with.
Have you heard of jQueryUI, by chance?
JQueryUI is also in maintenance state, basically a retired project.
One of the better ones I've seen is https://vaadin.com/docs/latest/components/date-picker
EDIT: ooh wow that Vaadin one is super nice indeed!
> JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser.
With bigger and more complex apps, you needed multiple teams and now it's not possible to really effectively track the state of the DOM if multiple teams could be manipulating it from different components.
You can see that shadow DOM and web components is one way of thinking about this problem. Separating the render from the state (a la Vue, React, Angular et al) is another.
Or rather their LLM has never.