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
> 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.
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.
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...
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...
document.querySelectorAll('.myclass')
.forEach(el => el.style.display = 'block')
Missing:
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" );
Yes, jQuery Mobile never really became a thing, but jQuery UI has some pretty useful widgets (autocomplete, date picker, sortable, etc.)
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.
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.
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.
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.
A few years later I went back to check the examples and they had the same problem.
Thankfully the app never made it to production, for various non-technical reasons.
I play with Framework 7 https://framework7.io/ and it looks very nice.
Any other suggestions?
Maybe it's time make it a real mobile app :)
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...
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 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.
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...
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.
I understand jQuery is old, but do not have fresh information on what's used nowadays.
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'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.
<grumbling>
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>
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.
- 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).
