I've been using the likes of PrimeVue (https://primevue.org/), PrimeReact (https://primereact.org/) and PrimeNG (https://primeng.org/) because they attempt to give you a library of components that work well out of the box and have a similar API across multiple technologies: Vue, React and Angular, respectively.
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
Vue, React, and Angular are fundamentally MVC in disguise: a "controller" modifies some state (model) and on the next render cycle, the "view" is updated by the library/framework to draw the change. (Simplifying here to ignore details of the implementation like vDOM, components, etc.)
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.
indeed, good description. Noting that vue etc. are MVC in the browser, with (typically) calls to json http endpoints on the back end to read/write data.
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.
> 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.
Yeah, I think this is nail on the head. It was also a time of smaller apps and smaller teams so it was easier to manage the state even with direct mutation on the DOM tree.
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.
Very true. But it doesn't matter if you're building a typical website instead of an SPA, and the only "state" you care about are little things like whether a checkbox is checked.
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.
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.
I would say that it is structured complexity. Modifying a reactive variable is more complex than editing the DOM directly, true, but it minimizes the number of sources of truth. The developer no longer has to worry about keeping the on-page elements and JS variables in sync; that happens automatically.
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.
The complexity is the infrastructure you need to build an application with a JS framework, versus just including the libraries that you needed in script tags and done. Do we really need a build system for JS? Probably to make something as complex as Google Docs that is an application that runs in the browser yes, but not for 99% of web pages that you see each days.
Complexity has to live somewhere. We use abstraction to better manage it, and keep our codebases scalable and manageable. Yes it's not as efficient as it would be if every single function call were carefully planned for and orchestrated, but that's not feasible for modern applications that do many things.
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.
The key problem all these frameworks solve is to let you store (and track changes to) data in a different structure than your UI. The moment you're not building a pure CRUD app, where the UI and the data always follow the exact same tree structure, but something more complex, tightly coupling the data to the UI like you'd do with jQuery apps gets messy and problematic.
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.
I personally have. React launched in 2013. Here's a real-time enabled browser chat app I built in 2011: https://www.youtube.com/watch?v=WG_W0VxjzbM and at this point, it had been years of building similarly complex JavaScript apps.
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.
jQuery UI was a step up from the time, but it was still painful to do basic things compared to now. I much preferred developing front-end for apps deployed on the web in Flex and later Silverlight. I moved to Knockout and then Vue. I have used Angular and React, I just prefer Vue.
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.
The jQuery UI Datepicker widget[0] still remains my favourite date picker implementation, even though it sadly never supported mobile phones that well.
Non-confusing design, live-reacting to user typing the date with keyboard, accessible, configurable, and offering 0-effort localisation in 60+ languages[1].
Unless you require something special, just a regular <input type="date"> or datetime-local is a good choice these days. There's week and time types as well.
Current top comment links to PrimeVue and I feel like it solves month/year selection very similarly (except not with a dropdown): https://primevue.org/datepicker/
This is the first UI component lib I checked. I'm curious what's missing here in your opinion?
For building a serious business CRUD app, to this day, I've never found a JS UI toolkit that matches the power and scope of the 4.X era of Ext JS: https://docs.sencha.com/extjs/4.1.3/
> 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.
jQuery got the Nickelback treatment. Except I really did enjoy using jQuery, and only moved on because "the industry" was and I didn't want to be left behind.
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 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.
As far as front end development is interpreted in the modern way — as in, building a means to deliver informational or experiential content as hypertext that is well structured, browser-agnostic, and universally human-and-machine-accessible — the high-water mark was somewhere in the early 1990’s, before mouseovers and animated gifs.
In 2012, we build the front end of an application by making heavy use of the JQuery UI widget class and extending it for our own needs. That application is still running today largely unchanged on the front-end.
I spent way too much time building with this at Cartegraph. We utilized the jQuery UI Widget pattern[0] for pretty much any UI we wrote from 2011-2013 when we started utilizing Knockout instead.
I have to believe most of those components are still in use in production today. They were when I left in 2022.
One of my first major projects was a Cordova Android app written with jQuery UI. It was incredibly hacky because I had no idea what I was doing. It worked well enough to let me pass the course though.
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.
Crazy how over-engineered the Headless UI one looks. Like they had a 5,000 word assignment but could only come up with 1,000 words and had to keep expanding and expanding to fit their quota. The import statements alone give nightmares.
I've been using the likes of PrimeVue (https://primevue.org/), PrimeReact (https://primereact.org/) and PrimeNG (https://primeng.org/) because they attempt to give you a library of components that work well out of the box and have a similar API across multiple technologies: Vue, React and Angular, respectively.
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/
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.
indeed, good description. Noting that vue etc. are MVC in the browser, with (typically) calls to json http endpoints on the back end to read/write data.
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.
[0] https://htmx.org/
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.
Very true. But it doesn't matter if you're building a typical website instead of an SPA, and the only "state" you care about are little things like whether a checkbox is checked.
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.
Yes, agree.
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.
Why is it more productive? I like your description, but this statement needs elaboration.
When I look at modern frameworks, all I see is unconstructive complexity that sucks productivity
The answer is "state".
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.
I would say that it is structured complexity. Modifying a reactive variable is more complex than editing the DOM directly, true, but it minimizes the number of sources of truth. The developer no longer has to worry about keeping the on-page elements and JS variables in sync; that happens automatically.
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.
The complexity is the infrastructure you need to build an application with a JS framework, versus just including the libraries that you needed in script tags and done. Do we really need a build system for JS? Probably to make something as complex as Google Docs that is an application that runs in the browser yes, but not for 99% of web pages that you see each days.
Complexity has to live somewhere. We use abstraction to better manage it, and keep our codebases scalable and manageable. Yes it's not as efficient as it would be if every single function call were carefully planned for and orchestrated, but that's not feasible for modern applications that do many things.
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.
The key problem all these frameworks solve is to let you store (and track changes to) data in a different structure than your UI. The moment you're not building a pure CRUD app, where the UI and the data always follow the exact same tree structure, but something more complex, tightly coupling the data to the UI like you'd do with jQuery apps gets messy and problematic.
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.
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.
jQuery UI was a step up from the time, but it was still painful to do basic things compared to now. I much preferred developing front-end for apps deployed on the web in Flex and later Silverlight. I moved to Knockout and then Vue. I have used Angular and React, I just prefer Vue.
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.
I started working in a project using prime and the exposed api is just frustrating compared to MUI, at least for me.
Feels like they take the idealistic view of things versus pragmatism.
I totally agree. I miss something simple and complete for UI things as Jquery UI
seems awesome. FYI got a react error screen when trying calendar with time, not sure exactly how sorry
The jQuery UI Datepicker widget[0] still remains my favourite date picker implementation, even though it sadly never supported mobile phones that well.
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?
[0] https://jqueryui.com/datepicker/#dropdown-month-year
[1] https://github.com/jquery/jquery-ui/tree/main/ui/i18n
Unless you require something special, just a regular <input type="date"> or datetime-local is a good choice these days. There's week and time types as well.
It’s amazing how far you can get with just HTML and a gentle sprinkle of CSS these days.
That date picker is really good.
> 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.
Current top comment links to PrimeVue and I feel like it solves month/year selection very similarly (except not with a dropdown): https://primevue.org/datepicker/
This is the first UI component lib I checked. I'm curious what's missing here in your opinion?
It's not obvious you can click month/year. Unclear how to back out if you think you made a mistake.
One of the better ones I've seen is https://vaadin.com/docs/latest/components/date-picker
Fair! Thanks
EDIT: ooh wow that Vaadin one is super nice indeed!
It's as if today's UI designers can't imagine why someone would pick a date 20 years in the past.
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?
For building a serious business CRUD app, to this day, I've never found a JS UI toolkit that matches the power and scope of the 4.X era of Ext JS: https://docs.sencha.com/extjs/4.1.3/
I second this. The speed at which you could deliver stuff with ExtJs was truly remarkable.
Worth keeping in mind:
> 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/
God forbid you used this now a days, other developers may get mad at you.
jQuery got the Nickelback treatment. Except I really did enjoy using jQuery, and only moved on because "the industry" was and I didn't want to be left behind.
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.
I don't know?
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.
> Something's not right there.
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.
Bootstrap and Vue/React are orthogonal. People who use react use it with some css framework.
Afaik bootstrap is getting replaced by tailwind. Which is actually pleasure to work with.
> Afaik bootstrap is getting replaced by tailwind.
By whom? Not by me.
> Which is actually pleasure to work with.
Have you heard of jQueryUI, by chance?
The high water mark of front end development. Change my mind.
As far as front end development is interpreted in the modern way — as in, building a means to deliver informational or experiential content as hypertext that is well structured, browser-agnostic, and universally human-and-machine-accessible — the high-water mark was somewhere in the early 1990’s, before mouseovers and animated gifs.
In 2012, we build the front end of an application by making heavy use of the JQuery UI widget class and extending it for our own needs. That application is still running today largely unchanged on the front-end.
I spent way too much time building with this at Cartegraph. We utilized the jQuery UI Widget pattern[0] for pretty much any UI we wrote from 2011-2013 when we started utilizing Knockout instead.
I have to believe most of those components are still in use in production today. They were when I left in 2022.
[0]: https://api.jqueryui.com/jQuery.widget/
Same (2012 for us)!
The Widget Factory was awesome for its time and not well advertised.
Party over, oops, out of time!
Tonight we're gonna party like it's the year 2009!
One of my first major projects was a Cordova Android app written with jQuery UI. It was incredibly hacky because I had no idea what I was doing. It worked well enough to let me pass the course though.
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.
The Jquery UI Combobox is still the best implementation I saw
never liked jquery ui, don't remember anymore even why. Was it maybe ugly or something. bootstrap was the way, and now quasar(vue) so awesome and easy
Holy cow what year is it.
I miss these days.
I recall jquery ui was not really responsive ready
Blast of the past
Looking at the selection of the controls, does any of this even require any JS or can all this be made with HTML/CSS only?
Guys, didn't you get the memo? We're doing this differently now, we've replaced
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
Crazy how over-engineered the Headless UI one looks. Like they had a 5,000 word assignment but could only come up with 1,000 words and had to keep expanding and expanding to fit their quota. The import statements alone give nightmares.
It's astonishing... It looks like it's not meant to be read by humans, let alone debugged or extended...