The Future of JQuery UI and JQuery Mobile | Hacker News Reader

The Future of JQuery UI and JQuery Mobile

blog.jqueryui.com

139 pointsapsdehal93 comments

jQuery is still quite relevant and helpful. Despite the hype with newer libraries, jQuery is used on 73% of _all_ websites. https://w3techs.com/technologies/overview/javascript_library...

I often tell myself, ok, I'm going to just use vanilla JS for this one, but compared to jQuery, it's way too verbose. Try doing $('.my-elements').show() in vanilla js.

The problem is the jQuery foundation has become too bureaucratic, making contributions harder. Example: https://github.com/globalizejs/globalize/pull/703

I think that number is inflated by CMSs such as WP early adoption of jquery. I have used jQuery extensively and I agree that's still relevant, but jQuery Mobile and UI never really took off.

Yes, 28% of all websites use WordPress (over half of the 73%). It means a lot of WordPress theme developers use jQuery.

Yes, jQuery Mobile never really became a thing, but jQuery UI has some pretty useful widgets (autocomplete, date picker, sortable, etc.)

That's actually a good example. My gut feeling was simply to write the following.

document.getElementsByClassName("my-class")[0].style.display = 'block';

The PlainJS site mentions that it's not quite that simple and suggests writing your own show() and hide() functions if you're avoiding jQuery.

https://plainjs.com/javascript/effects/hide-or-show-an-eleme...

Right, and that still doesn't handle applying the action to all _all_ items of that class.

It would need to be something like this, though it still doesn't automatically handle inline vs block:

document.querySelectorAll('.my-elements').forEach(function(el){el.style.display = 'block'})

And apparently there are issues even with that: https://css-tricks.com/snippets/javascript/loop-queryselecto...

For reference, this is how you do this in jQuery: $('.my-elements').show()

Ok, I kinda got sniped on this. Here's a first pass at a micro lib to do it using Proxy object:

    const $ = (() => {
        function listProxy(arr) {
            return new Proxy(arr, {
                set: (t, p, v, r) => {
                    for(let x of t) {
                        x[p] = v;
                    }
                },
                get: (t, p, r) => {
                    if(t.length > 0 && t[0][p] instanceof Function) {
                        return (...args) => { Array.prototype.map.call(t, (x) => x[p](args)) };
                    } else {
                        return listProxy( Array.prototype.map.call(t, (x) => x[p]) );
                    }
                }
            })
        }

        return (sel, root) => {
            if(root === undefined) root = document;
            return listProxy(root.querySelectorAll(sel));
        }
    })();

    // use like this:
    $('.my-elements').className = 'Important'; 
    $('.my-elements').style.color = 'Red';     
    $('.my-elements').classList.add('Another');

demo: https://codepen.io/anon/pen/RxGgNR

In this specific case jQuery's `show` is just giving you a shortcut to show/hide arbitrary elements.

Try doing this with CSS, please.

    <div class="element"></div>

    .element { display: block; }
    .element.is-hidden { display: none; }

    document.getElementsByClassName("element")[0].classList.add( "is-hidden" );

You should never ask yourself "How can I accomplish that without jQuery", but rather "What would be the best way to do it!"

To make that work for all elements of that class, you could rewrite it as

  document.querySelectorAll('.myclass')
    .forEach(el => el.style.display = 'block')

The jQuery is still shorter, but the vanilla js is definitely manageable.

Unfortunately, querySelectorAll returns a NodeList, not an Array. So you cannot use forEach() on it.

NodeList also implements forEach:

https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo...

It's a very recent addition. IE11 doesn't have it for sure.

Not in Edge though.

The page I linked has a compatibility chart that says Edge 16 has it (no idea if that's a planned release, haven't ever used Edge).

You can use Array.prototype.forEach.call(nodelist, fn), or Arrays.from(nodelist).forEach

I don't use Windows so I can't test it, but would this work as a polyfill?

    NodeList.prototype.forEach = Array.prototype.forEach;

In Chrome this even returns true:

    NodeList.prototype.forEach === Array.prototype.forEach

Tested in IE11, document.documentMode===11

  Array.prototype.forEach.call(document.querySelectorAll('div'), console.log)

seams to work

  Array.from(document.querySelectorAll('.myclass'))
    .forEach(el => el.style.display = 'block')

Though ie11 doesn't have Array.from()

Hrmmm... maybe someone should make a library that would smooth over browser differences and provide a consistent element selection syntax? Call it JavascriptSelection, or jSelection?

imho 'JavascriptQuery' or 'jQuery' sounds better, oh wait...

I tend to polyfill older browsers, Array.from is a pretty small one. Sad thing is at a point where it's probably worth it to have 2-3 builds in place... 1 for legacy browsers, one for modern without modules, and one for modules/import/http2 support.

Just haven't taken the time... at least the main app I work on at work doesn't need to support IE11. Latest Edge,, Firefox, Safari and Chrome ... and Chrome is the primary target.

It's like a corollary to Greenspun's Tenth Rule [0], in that anytime I try to do something in vanilla JS, I just end up poorly re-inventing half of JQuery just to do it.

[0] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

I ended up reinventing most of jQuery: https://umbrellajs.com/

But it was fun and I learned a lot, so there is that.

This comment is actually a fantastic example of why jQuery is so popular.

Missing:

Unfortunately, document.getElementsByClassName isn't universally supported[0], so even if you wanted to do it that way, it still wouldn't be that easy. Never is.

[0]https://caniuse.com/#feat=getelementsbyclassname

whenever i feel the need for jquery these days, i typically reach for the much smaller, faster, ie11+ https://github.com/franciscop/umbrella

nice. thanks. despite the plainjs appeal in practice i still find that using jquery is faster, easier, and safer.

the parts of it i want are very simple though. i can (and have) written my own replacements, but I don't want to throw my own one-off replacement into the projects I use, so having some kind of community library is much better.

From the author of the Picnic css framework. That bodes well for conciseness, documentation, and style.

The biggest benefit that I've found for jQuery (and a lot of JS libraries) over vanilla is browser compatibility. I generally don't have time to check compatibility of every mildly complex piece of JS I write. Using a library often solves that issue

That was a relevant answer couple of years ago. These days you can achieve most with having a properly setup IDE-intellisense ( e.g. WebStorm ).

Does that really solve the issue though? All the IDE can tell you is that some browser version doesn't support what you're doing, it doesn't write the polyfill for you.

Most of the polyfills these days are pretty much syntax sugar & ES6 transpiling. If you do your code in non ES6 plain JS way, I'm quite sure the IDE will give you the benefits that you receive with jQuery.

By "these days" do you mean "needed to support the latest version of each major browser"?

Just read through that issue thread on github. That makes me almost cry! Here's an awesome project (whether it's dated or not), and then there are all these people trying to make valid, good contributions, but for some reason (however valid they are) they have to go through all these red-tapes.

I don't know where to stand. One side, maybe you need all these red-tapes so that you don't get in any trouble. But this makes me feel like things are not going to progress and people will eventually turn away.

Haven't we already seen too many examples like this? Things start small, they get popular, people jump in to use, then things get political and it dies out.

That github thread was maddening to read. They actually got a lawyer to chime in with their explanation for why the new CLA is needed, and then we got this nonsense:

> Among other changes, the updated CLA gives the Foundation the ability to re-license contributions under Apache 2.0.

But they already said:

> There is no need to get new signatures for old contributions

So they're not planning on getting all old contributions to be updated to the new CLA, but they think the new CLA will let them relicense the entire code base under Apache 2.0. That's not how that works! But it gets worse, because when challenged the lawyer quotes the updated CLA language:

> You understand and agree that the JS Foundation projects and your Contributions are public and that a record of the Contributions (including all metadata and personal information you submit with them) is maintained indefinitely and may be redistributed consistent with the JS Foundation’s policies and the requirements of the Apache v2.0 license where they are relevant.

"You [...] agree that [...] your Contributions are public and that a record of the Contributions (including all metadata and personal information you submit with them) [...] may be redistributed consistent with [...] the requirements of the Apache v2.0 license where they are relevant."

That's clearly saying that they may need to provide people with the record of your contribution in order to prove that, eg, the Apache v2.0 license is being complied with. It is not an agreement that your actual contribution is licensed (or can be relicensed) under the Apache v2.0 license.

This is just magical thinking. You can't just mumble the words "Apache 2.0" somewhere in the general neighborhood of a legal document and have it magically relicense years of contributions. You certainly can't make people agree that metadata about your contribution can be shared with some people, and then expect that to magically change the license under which the contribution itself exists.

Agree. And for quick prototyping it's also very useful.

Seems like most of the comments on here pertain to the relevance of jQuery, rather than jQuery UI and jQuery Mobile.

Sure most sites still use jQuery, but do very many use jQuery UI anymore? jQuery Mobile? I've never seen a project use jQuery Mobile.

I've seen mobile on a moderate number of mobile-web-app side projects... though I haven't looked into these lately with anywhere near the frequency that I did a couple years ago. Generally it seemed pretty quick and easy to do good-quality simple stuff (like UI), though nobody did much beyond that because it was tricky to fine tune (like UI). Not sure what (if any) the current hotness is, aside from React + random components found online.

I tried to use jQuery Mobile for a project once many years ago. It was a disaster, I ended up rewriting the entire thing

I had the exact same experience. Performance on Android was horrible!

I used it for a project when I was at university. It was appalling to use. Lots of the examples on the jQuery mobile website failed (e.g. weird redirections when closing modals, lots of odd flashing and jumping around).

A few years later I went back to check the examples and they had the same problem.

I built a complete mobile app using jQuery mobile and it was a total disaster as well. I had so many ugly hacks in place just to achieve what any decent SPA framework does out of the box nowadays. To this day I have no idea what the actual purpose of jQuery mobile was, it sucked for single page apps and felt more like a quick way to make HTML pages responsive. Which can of course be achieved with a bit of CSS or one of the many responsive CSS frameworks.

Thankfully the app never made it to production, for various non-technical reasons.

If you have to select a mobile framework today, what would you choose?

I play with Framework 7 https://framework7.io/ and it looks very nice.

Any other suggestions?

ionic. in fact if you took jQuery mobile and made it reactive via something like Angular, React, or Vue.js it might make it usable for today's expectations.

quasar - ionic like vue framework.

F7 is my favourite as well. Two of the featured apps on the home page are mine :D

I had the exact opposite experience. I found jQuery Mobile to be very cohesive and simple to use. And the documentation was pretty much on the spot.

I'd bet the decline in both of these is 99% due to Bootstrap.

I used jQuery UI a long time ago and was not very impressed. Definitely not on the level of jQuery itself.

I saw jQuery mobile projects for sites with insanely large expected user base.

For instance a gas comapny’s customer information site, and the goal was to have html that could be displayed on post wap phones or super old blackberries.

It’s really less to do super fancy stuff, and more to have forms that don’t break on super exotic browsers we didn’t even know existed.

> on super exotic browsers we didn’t even know existed.

they do not work well with jQuery or even jQuery mobile. consider ANTGalio a browser that was used in a lot of embedded stuff could not work with anything above emcascript 3 and even than had some pretty wierd behavior. jquery did not work on it.

I have used jQuery UI for its "sortable" interaction. It did the job. I would use it again. Is there any alternative anyway?

Absolutely, lots of people are keen for jQuery UI features without the bloat of jQuery+jQuery UI.

For sortable, there's https://github.com/RubaXa/Sortable. It comes in at around ~6KB gzipped, compared to ~80kb for jQuery UI's JavaScript (not to mention CSS and jQuery itself).

I used JQuery Mobile to build http://letzcode.com/

Maybe it's time make it a real mobile app :)

I didn’t sign up, but I did click around the JS and scheme docs on my iPhone. The horizontal overflow is hidden so half the content is not shown. I cannot zoom out to fix the issue.

I'm using jQuery mobile for a small shopping list application. What I miss are manually sortable lists.

I wrote a prototype of a questionnaire system using jQuery Mobile version 1.0, to see what it was like [1].

The problem I wanted to solve mapped pretty closely to exactly what jQuery Mobile was designed to do: page through a bunch of screens with controls on them. But the results were pretty "blah", and I needed a lot more control over the presentation and behavior than it provided.

Instead, I just used raw jQuery, which worked fine.

But I did use end up using one jQuery UI file "jquery.ui.widget.js" for its "$.widget" Widget Factory [2] and Widget Plugin Bridge [3], which provided some useful plumbing. But I didn't use any of jQuery UI's actual widgets. I also used $.widget for jQuery pie menus [4].

If there's a better alternative or idiom than $.widget, I'd love to know! But it worked fine for me, and I didn't need to drag in the rest of jQuery UI.

The weird thing about jQuery is: a "jQuery object", the result of querying a selector, is not an actual widget or DOM object -- it's the result of a query, which might contain any number of "objects", or none. It's ephemeral, not for storing persistent state like a widget.

So you need another way to represent and bridge messages from "jQuery objects" created by querying selectors, to actual stateful "widget" objects associated with concrete DOM objects, and that's what $.widget provides.

It creates a new "widget" object the first time you call it, and after that it updates and sends commands to the existing widget (or widgets).

Because of the way jQuery selectors work, you can actually create and configure a whole bunch of widgets at the same time with one $.widget command! Which is useful: "make each object with this class an instance of that widget with these parameters". And you can use $.widget with jQuery selectors to update parameters and broadcast messages to multiple widgets at once.

Suffice it to say, it's not how you'd design a user interface widget toolkit if you were you starting from Scratch [5]. But it is, if you were starting from jQuery.

[1] http://donhopkins.com/home/prototype/prototype.html

[2] http://api.jqueryui.com/jQuery.widget/

[3] http://api.jqueryui.com/jQuery.widget.bridge/

[4] https://github.com/SimHacker/jquery-pie/blob/master/javascri...

[5] https://wiki.scratch.mit.edu/wiki/Smalltalk

Considering current trends for creating complex applications for the client I do not believe jQuery has much of a future anyway. It had been good while it lasted, I used to like jQuery a lot until better tools came along. These days libraries for DOM manipulation seem not only obsolete but also standing in a way of focused and efficient development. Let jQuery rest in peace and be remembered for its past greatness.

Disagree with this somewhat. I think jQuery still has a place in web app development, especially when you need something done fast. You just need to be careful not to over-bloat your js. jQuery has helped my team get stuff done really fast more than a few times in the last couple of months.

Depends on the context, I guess. While working on a code base employing DOM manipulation it's absolutely fine. Having said that I would think long and hard before starting a new project with jQuery, and then probably used another library. There are other ways to get things done quickly, efficiently and in a way which promotes maintenance.

> I think jQuery still has a place in web app development, especially when you need something done fast

I never got this argument and am curious - what exactly does jQuery do faster?

I've left it behind for CSS animations and native Dom selectors years ago and haven't looked back.

To a certain extent I have left it behind as well, but jQuery does add an extra level of convenience that is well suited to prototyping (and even getting things done quickly in prod). One example is the each function that works on object properties. Getting that to work on an older browser without jQuery is a bit convoluted, but with jQuery it's easy. Not saying it's the only/best way to do it, but it is probably the easiest.

It's certainly easier to just include JQ on an existing site and get to work for simple stuff, but I just deal with Angular now. Easy enough to get up and running with ngcli, and a year down the road the codebase won't look like the abortion which is loads of jquery.

It's definitely less necessary than it was a few years ago.

I find it useful when you just want to add a little bit of interactivity to a mostly static page, and you're not sure who's going to be maintaining the page in the future or trying to use it as a template.

A lot of people who know a decent amount of HTML and CSS but aren't that familiar with straight JS dom manipulation, or what functionality works cross-browser, can tweak jQuery-based code more easily. That's really a tribute to the jQuery project--the documentation is simple and a lot of the methods (e.g., show, hide and append) are very intuitive.

This article is about JQuery UI and JQuery Mobile, which are not the same as JQuery.

The slack url in this post overflows the text and zooms the page out on my phone making for an apropos blog reading experience about the future of jQuery mobile. Photo here https://twitter.com/potench/status/943950784592363520

Same here. +1

jQuery UI and jQuery Mobile are deprecated. Take in mind, it comes from an age before HTML 5 became set in stone. Browsers weren't caught up yet. JavaScript libraries weren't plentiful and mature as they are now. CSS frameworks like bootstrap also didn't exist until years later.

And there was more optimism toward the concept of creating a widget toolkit and a webview mobile app. And while to an extent - we embrace that now in some form - it didn't work so well the first go around [1]. Media queries becoming a normal practice and CSS frameworks made jQuery Mobile feel clunky. Heavy duty mobile apps went native - and I can't know where they are now.

For jQuery UI, over time, the theming got a bit old. And stuff like "Buttons" (https://jqueryui.com/button/), you can already get via CSS. Most CSS frameworks, for that matter, do a lot of the widgets with far less JS, if any at all.

I'll miss them. They were a stepping stone in getting us to where we are now.

[1] https://techcrunch.com/2012/09/11/mark-zuckerberg-our-bigges...

> In the past, when someone wanted to join the jQuery UI or jQuery Mobile teams we expected them to contribute to the library as a whole.

I'm not sure about the accuracy of that. I was a jQuery UI team member in the '09 - '11 period (I can't recall exact dates) and I only worked on certain components, though I did participate in discussion and planning for the platform as a whole. It was also common for contributors/team members to pitch new plugins that weren't worked on by the entire team.

So maybe this is just jQuery UI getting back to it's open source roots more so than anything. I'm sad to see that the project has fallen on hard times, but I'm not shocked given the direction most of front end webdev has moved towards these days. The amount and types of UI frameworks and component libs available today are myriad. And at jQuery UI's peak (and hell, jQuery as well) there were only a few.

I'd like to add a meta-note that Scott Gonzalez was always great to work with, and if you want to read some interesting, independent thoughts, he's a good follow on the twitters.

People in the comment threads seem to be confusing jQuery UI with jQuery. jQuery UI is collection of interactions, effects, and widgets built on the more ubiquitous jQuery library.

jQuery UI was also tightly tied to Filament Group so it was a commercial product looking to capitalize on the jQuery name. That whole think was not so successful and jQuery UI was never that great. 5+ years ago it was bloated and buggy and it has not seen much development since.

Filament Group was a sponsor but the project was not "tightly tied" to the company. I believe that's a bit of FUD right there.

Or a mistake, due to successful sponsorship. No need to assume the worst.

Could someone please tell me how modern DOM manipulation looks like these days?

I understand jQuery is old, but do not have fresh information on what's used nowadays.

With native APIs, jQuery was only useful for providing an abstraction layer over browsers' differing implementations, but they are mostly standardised now.

Good times with those gradient styled widgets, but today they should be retired and developers should start looking at upcoming tech, like Houdini project https://github.com/w3c/css-houdini-drafts/wiki .

When I used it many years back, both UI and Mobile, I found it kludgy and odd. The UI wasn't all that pretty compared to Bootstrap so I just started using that and actually forgot about this entirely. I think that's where the actual migration started, with Bootstrap. The other frameworks started popping up later when jQuery wasn't scaling for UI code such as Ember and using Mustache then later Angular, then React, Angular 2, Vue, etc so now, so now jQuery UI/Mobile is completely irrelevant. I would also throw in Sencha extjs as dead too and classify that as enterprise jquery UI.

jQuery certainly did a commendable job of lowering the bar for web developers!

So low that many people thought of jQuery as a way to avoid learning JavaScript. (Not that there's anything wrong with that, mind you.)

That's why there's such a huge demand for a free jQuery plugin that can add, subtract, multiply, divide and compare numbers.

http://www.doxdesk.com/img/updates/20091116-so-large.gif

"-1 not enough jQuery"

https://github.com/cbrandolino/jQuery-basic-arithmetic-plugi...

jQuery basic arithmetic plugin

$.add(arg1, arg2 [, args...]) adds two or more numbers;

$.subtract(arg1, arg2 [, args...]) subtracts two or more numbers, the leftmost being the first operand;

$.multiply(arg1, arg2 [, args...]) multiplies two or more numbers;

$.divide(arg1, arg2 [, args...]) divides two or more numbers, the leftmost being the first operand;

$.equals(arg1, arg2 [, args...]) checks two or more numbers for equality.

I remember years ago (when I was still active in browser dev) having to argue with people who wanted jquery to be embedded in the browser and/or be part of the DOM spec.

I'd like to imagine that this kind of article would help people understand why browsers don't just do that and instead try to develop general APIs that enable frameworks to grow and evolve or simply be replaced as new dev models spring into being.

Consider this: jQuery needed a bunch of DOM operations to be very fast and have certain behaviors (it's a long time ago, but iirc there were selectors, property apis, certain kinds of nodelist behaviour). Multiple webdevs proposed build jQuery APIs into the browser, so rather than making the underlying operations fast, we'd just have the critical path implemented natively inside the browser. While that would have solved some performance problems it would not have helped any other framework.

By instead making those core functionality faster, and providing general APIs for the things jQuery needed, other frameworks could also make use of them.

My hope is that by seeing these posts (which are honestly tending toward EoL notices) people will remember than no one library is ever likely to be permanent, and will stop asking for browser to just include the libraries internally.

</grumbling>

Can't wait for Matrix to become the defacto tool to connect teams, instead of dropping IRC for Slack, they will drop IRC for Matrix. It makes me sad to see JQuery moving to Slack when I think they would be better off moving to Matrix instead. I hope they at least considered Matrix.

I would sugest they pick another name because it is hard to find them with google. A name like TeamMatrix or MatrixTeam might be better.

I've never heard of Matrix, but it looks like this is the project: https://matrix.org

I’ve heavily used jqueryUI and can’t thanks the team enough for all the work they done during those years.

But when I opened the blog post on my iPhone and got only a small column, around the quarter of the screen, with content, I thought about how ironic it was, regarding the jquery mobile topic.

Oracle JET (javascript enterprise toolkit) has a strong dependency on jQuery UI.

Question to those of you who use JQuery UI: Why JQuery over, say, React?

What are modern alternatives to jQuery mobile ?

TL;DR they are both dying

That's not the TL;DR of the article at all.

It would be if it was written by someone neutral and not the creators of the tools.

Here is real TLDR;

- Scott Gonzalez has lead the jQuery UI project for many years now and has helped to improve the quality tremendously.

- However, we do hope to continue reducing the amount of duplicated code and widgets in the projects moving anything common to jQuery UI.

- We think going forward this needs to change; we will now be looking for and accepting people that are just interested in maintaining a single piece of the library, requiring a much smaller time contribution.

- Over time however, we have seen a large decrease in the number of people on IRC while other projects have had great results with easier to use tools like Slack.

- Anyone who is interested can feel free to reach out to Alex Schmitz, the new team lead for both projects, join our slack channel or even find us on IRC (we are still there).

They are just trying to give it a positive spin.

Reply on news.ycombinator.com