Can we all admit this project is dead?

[snoopiesnax]

And update the website and README accordingly?

[helloromero]

yep

[jtara]

Insert random Dr. McCoy clip here...

[ElliotNB]

@arschmitz has been talking about the need to re-group and draw in more contributors for almost a year now. Unfortunately, I don't see the leadership undertaking any public outreach to achieve that goal.

If this project had new proactive leadership that engaged with the community and actively recruited contributors, then I have little doubt that it would thrive again. As @delocker pointed out, a project with 2600 forks is too good to die unceremoniously like this.

Though it hasn't seen a significant release since version 1.4.5 in 2014, jQuery Mobile is still a brilliant UI framework for rapidly building user friendly mobile applications. I am particularly fond of jQuery Mobile for the fact that it is strictly a UI framework and keeps framework-specific constraints and rules to a minimum.

[ppetree]

@ElliotNB hit the nail on the head here "Though it hasn't seen a significant release since version 1.4.5 in 2014, jQuery Mobile is still a brilliant UI framework for rapidly building user friendly mobile applications. I am particularly fond of jQuery Mobile for the fact that it is strictly a UI framework and keeps framework-specific constraints and rules to a minimum."

However, we really must admit that JQM is not just dead... the corpse has rotted. Basic issues have been unaddressed for YEARS. Simple functionality is broken. Forum help is somewhere between good to snarky to non-existent (usually snarky). The documentation is woefully inadequate and, at times, completely wrong.

But, the good news is JQM has followed a path many other tech products have followed: Maturity, followed by arrogance, followed by neglect, followed by decline followed by demise. I say good news because we at least we can recognize the process and know it's time to move on... so, without changes, this will be my last JQM project.

[emiliogarza]

With the recent vulnerabilities reported about jQuery under version 3, it's unfortunate the JQM team still does not have a production release ready that is compatible with jQuery 3! Definitely agree with @ElliotNB and @ppetree

[ElliotNB]

@apsdehal @jaspermdegroot Do you know what's going on with the project? None of us have heard anything from @arschmitz in quite some time.

As you can see from this thread there are plenty of people here who are interested in the longevity of this project. There are plenty of potential contributors -- myself included. However, there must be some sort of active engagement and recruitment effort from the leadership if the project stands any chance of revival. No one wants to contribute to a project that seems destined for a slow death. There must be some sort of initiative from the leadership to kick start and encourage the process. One blog post per year and sporadic meetings on IRC/Slack isn't going to cut it.

[PanderMusubi]

I'd also like to see development and maintenance back at a healthy level. Some ideas are:

• Can the JS Foundation help? Donations for jQuery et al go to https://js.foundation/about/donate The foundation mist have some instruments to guide jQuery into safer waters. (Also because I do want to donate but not at the current state of affairs.)
• Start consolidating forks, branches and PRs outside the main repo. There are way too many forks, so much that GitHub does not list them anymore. This also discourages people from forking for new conributions via PRs.
• Contact people with forks and ask then to remove the forks if these have no contributing value, e.g. when they have no commits.
• Connect this issue to a related forum post.
• Start a petition or poll amongst users regarding reviving jQuery

"The JS Foundation provides the guidance and support necessary to ensure growing and diverse contributor bases that will deliver high quality, long-lived open source projects."

[Zhuinden]

Honestly, we spent enough time back in the day (3 years ago?!) debugging why 1.4.5 (current "latest stable") broke scrolling on iOS, had the navigation drawer "stop showing and disappear" on Samsung Galaxy S4 4.4.2 and stuff like that; that I'd rather see this project stay dead (so that people don't accidentally choose it like we did).

Use Ionic 3 or something, maybe that's better.

[ppetree]

Yeah, I think ionic is where I'm heading.

Problem is, I have two MAJOR apps based on JQM (both 10K lines of code) and I want to milk the current code base as long as I can. There are a lot of bugs in 1.4.5 and were supposedly fixed in 1.5 but given the lack of support (and frankly, the activity around 1.5 .died as quickly as it began with no updates since) that day may be coming sooner than I hoped.

[ElliotNB]

Same boat as @ppetree -- we have an existing app with tens of thousands of lines of front-end code using jQuery Mobile. Dev on that app started back in 2014 when JQM was looking very healthy. I haven't had the difficulties that @Zhuinden describes with iOS scrolling and the navigation drawer on Galaxy S4. We test on a wide variety of devices and JQM 1.4.5 out of the box still largely works fine with older and latest iOS and Android. On the other hand, the Cordova compiles definitely can cause some strange device specific issues.

[frankie-loves-jesus]

Would Ruby on Rails + Turbolinks be a viable alternative?

[PanderMusubi]

It would be a waste to throw it all away, especially if there has been build so much with it. Who would like to help start a dialog (not here) with the maintainer and the foundation behind this? If we do this in a coordinated way with a few people wee might succeed. Especially if there is existing funding to run this project, that should go to people that pick up the maintenance if the current maintainer does not want to do this anymore.

[agcolom]

It's nice to see some support of the Project. It feels now is the right time for me to give some hindsight into the situation...

I have been involved with JQM since 2011, and my role was in testing, bug triage, and the development of the API docs from scratch. (I also updated all the jQuery API code examples to make them consistent and adhere to our coding style).

As with all projects, people leave (often due to lack of time available to allocate to the project), and here, the project team (me included) has failed to attract enough new contributors to replace those leaving. It then becomes extremely difficult to continue to maintain/contribute/develop the project further.

In my personal case, it was getting more difficult for me to attend team meetings which were taking place at times when I needed to prepare dinner and help my kids with their homework (I'm in the UK, and also have a full-time job). The development team was also in the middle of a major rewrite, so I didn't feel as involved as I was initially. When you lose momentum, it's difficult to get it back, but not impossible. I would also like to add that all my contributions have been in my own personal time. I was not sponsored by my employer or the project or anyone else. It's therefore very difficult to see comments from people who used the project but never contributed, complain, sometimes quite rudely, just ordering us to fix things. I often wanted to say (and maybe should have said) "I would love to, but I do not have the time to do this".

I have enjoyed working with some amazing people over the years, and if somehow someone manages to restart the project, I'd be happy to take part again, with API docs contributions and testing.

[PanderMusubi]

@agcolom Thanks for your reply and for your the contributions you made in your personal time. I'm not familiar with how much funding there is and how it is used. Perhaps somebody could elaborate on this, hence my question "if there is existing funding ...".

A way to support a restart could also be made with help from Mozilla, see https://www.mozilla.org/en-US/moss/

[ElliotNB]

@agcolom Do you have any advice for how we might get in touch with the project maintainers? A few of us have made a number of attempts over the past couple months to reach @arschmitz but we've had zero luck thus far.

[ppetree]

The last I heard from anyone there was when we were told to consider 1.5 in beta. 1.5 looks like a rush job and there was no indication that it had been run through a test suite or anything else that would happen with Alpha code going to Beta. I lost interest at that point.

Beyond that, the entire UI is way behind the market. I know they're replacing the JQM widgets with JUI but even JUI is way behind the times when it comes to use within mobile apps.

[joegrist]

A whole lot of the code in here could be replaced with pure CSS stuff these days. It's not a good choice for starting up a new project. This project should probably be clearly marked maintenance only or dead.

[cstruter]

Funeral?

[ppetree]

Wake! With lots of alcohol! ;-)

[rszimm]

So what are the alternatives to jQuery Mobile now. Have mobile browsers become sophisticated that you can use something like React, Angular or Vue? Maybe JQuery UI (is that still a thing). I'm rewriting a codeset that's currently using JQuery Mobile and looking for something painless (yeah right!) to switch to.

[ryanlin1986]

Not only this project is dead, also the jquery-ui is definitely dead, just don'e use it or do a migration

[PanderMusubi]

I've switched to bootstrap.

[ppetree]

jqWidgets or leave jquery all together.

[boussou]

I am testing various frameworks on desktop & tablets, compared them on Ipad 1 & 2, highend android phones, desktop and some old android devices ("old" meaning max 2 years). To see how "reactive" they feel.

Testing the demos with basic forms, buttons & widgets, I can't see where is the problem with jquery mobile. Quite the opposite, I found it is the fastest, most reactive especially on old devices. It is as good as Bootstrap IMHO. Last theme doesn't look that bad. I can see it is easy to patch. The only pb I can find is that it is a bit "fat". is it a problem nowadays? I would say no. Obvious: When it is fast on older devices, it is lightning fast on highend devices.

FYI I compared mainly to

• Mobile Angular UI http://mobileangularui.com/ (based on Boostrap, but poor regarding controls),
• http://framework7.io/templates (THE slowest on Ipad)
• Onsen UI https://onsen.io/theme-roller/ (very slow & buggy on old ipad).
• Vue elements https://github.com/ElemeFE/element
• Iview https://www.iviewui.com/overview/

The Last 2 look awesome, especially if you like Vue like me, but when you start to use them, you can feel how bloated they are, & on top of that they don't work on older devices. And they rely on Vue framework heavily. and Node's build.

Simple: Does someone have a clear view about the reasons why we should avoid using this framework? (except going over the 154 issues). Said differently, Is there a webpage summarizing it? I like it a lot, It is so easy to use especially for prototyping.

What are the risks using it? I can't see none, ie some of my applications still use Bootstrap 2 and it is all fine. After all, css won't change so much on the next decade right? while on the other hand, frameworks like vue or angular will, for sure.

jqWidgets why not.

[joegrist]

Please refer above, notably the page transition issue referenced, which is a blocker. This issue also causes unresolvable problems with keyboard presentation. This framework needs major design changes to work with iOS12. But nobody's maintaining it. Stay away.

[boussou]

That is one fact. Surpringly I did not test in iOS12 ;-) I will try on recent iphones.

Btw why can't it be fixed? Or avoided (removed).

Thanks for the quick answer.

I shall rephrase maybe the initial question If I wanted to use it like a responsive framework, like Bootstrap, for a website, without the need to make it look like mobile app on mobiles (so used "offline" with Cordova & using native like effects & transitions). just like a responsive framework on a responsive website, what would be the problem?

[ElliotNB]

@sparklellama @boussou Do you have anything reproducible for iOS 12 issues? Anything logged to Github already?

We use jQuery Mobile and implemented it as a single page application. It works great for us on iOS 12. We also have no issues with page transitions -- though our implementation is likely different than yours since we're using jQuery Mobile in an SPA setup.

[jtara]

bossou, you are comparing apples and oranges. The frameworks you tested take on a much larger task than JQM. For one, I believe they are all client-side MVCs.

After all, css won't change so much on the next decade right?

CSS will change plenty in the next decade.

Reasons for avoiding:

• dead project
• unsupported
• already broken by newer browsers

There has been plenty of time for "somebody" to step forward and take the project over. They haven't.

Using it in a new project is painting yourself into a corner, unless you have a large staff to take over the project, fix it, and keep it up to date with new browsers.

Any thought that any web-based framework/library/project or even a web page or site is "done" and does not require ongoing updates and maintenance is folly. I do realize, though, it's a common public misunderstanding. It is true only if you use it only for in-house use, and freeze your browsers in amber.

As far as "page transition" issue:

https://github.com/jquery/jquery-mobile/issues/8637

They are using JQM 1.3. Why do they expect it to still work?

"The Moving Finger writes; and, having writ, Moves on ..." ― Omar Khayyám

"It's dead, Jim!" ― Mr. Scott

[ElliotNB]

@jtara They are apples and oranges, but if @boussou only needs a CSS framework with some simple UI widgets (or is capable of implementing JQM as an SPA himself), then the comparison is still appropriate. At my work we have a legacy jQuery Mobile app that now runs as an SPA using the Nimbly framework I wrote. If you know how to use $.enhanceWithin then it's not too difficult at all to run jQuery Mobile as an SPA.

There has been plenty of time for "somebody" to step forward and take the project over. They haven't.

True and it's a shame. The current leadership is basically AWOL and yet still refuses to relinquish their maintainer roles nor recruit any successors. They are responsible for driving this project into the ground.

[joegrist]

We're gradually removing it from a large scale application. Problems come when you have long pages or form fields and multiple pages, and try and use it on smaller screens. Not worth trying to fix as this library does a lot of DOM manipulation that's unnecessary, and can be done using CSS. Most of the controls can be done with a style sheet now, but the extremely heavy-handed JS way JQM does it gives us major performance implications, for example on forms with several thousand fields.

Also other problems like for example Modals/popups are flawed at the design level, they just aren't responsive enough for a real application - they only have one UX and try to use it on all screen sizes.

This library spells doom for your project once it gets real world use. It's just not responsive or mobile friendly in the modern sense of the word.

[jtara]

The current leadership is basically AWOL and yet still refuses to relinquish their maintainer roles nor recruit any successors

Who shall they relinquish it to? Any volunteers?

There has been 4 years for any to emerge.

[ElliotNB]

The current leadership is basically AWOL and yet still refuses to relinquish their maintainer roles nor recruit any successors

Who shall they relinquish it to? Any volunteers?

There has been 4 years for any to emerge.

It's a pretty long story. There have been people interested over the past couple years in helping to revive the project -- myself included. My opinion is that the leadership should have actively recruited replacements. Instead, Alex has publicly stated that he will remain the project lead on jQuery Mobile -- despite essentially zero project activity over the past couple years. When you have leadership that publicly states that they will remain in charge while simultaneously doing very little to move the project forward, any potential volunteers will just lose interest. It's just not the proper way to run a dying open source project -- the project leads and maintainers have to lead the charge or get out of the way when someone expresses interest in reviving it.

We're gradually removing it from a large scale application. Problems come when you have long pages or form fields and multiple pages, and try and use it on smaller screens. Not worth trying to fix as this library does a lot of DOM manipulation that's unnecessary, and can be done using CSS. Most of the controls can be done with a style sheet now, but the extremely heavy-handed JS way JQM does it gives us major performance implications.

Yeah, if we had implemented JQM like that (the traditional path of JS-heavy explicit DOM manipulations), then I would have definitely retired it as well. Building a large web app that relies on explicit DOM manipulations is just out of the question -- state management becomes rapidly unmaintainable. Component-ized SPAs are the way to go.

If I had gotten involved with jQuery Mobile, I would have definitely advocated pairing it with a framework so JQM could be implemented as a modern SPA -- whether the framework is the one I wrote or something else.

[boussou]

It feels strange, because obviously there is a community here. This project, is it dead yet or dead "dead"?

[joegrist]

If nobody's working on it, it's dead. Unfortunately a bunch of us are still stuck with legacy apps.

[jtara]

IMO, the seminal event was withdrawal of major support/funding by Adobe. That was the handwriting on the wall. And that was a long time ago.

IMO, it filled a need for Adobe, in that it gave developers an easy way to create nice looking pages with nice transitions for Cordova/Phonegap apps. While it had broader applicability to websites as well, I'd imagine that Phonegap was their motivation.

In the end, we have to realize that Adobe's motivation was ultimately to sell Adobe products that developers would use to create content. One must ALWAYS examine the motivation of sponsors! When that motivation is gone, often is support as well.

I have no insider information - just speculation.

It had a good run. I used it in a number of hybrid mobile apps (Cordova, Rhodes). But when I saw the support dwindling, I had to bail. I've used Bootstrap 3 and 4 in some projects since, and now moving to Web Components.

The ease of use was great. It fit a niche, which is not readily filled today by other libraries.

[ppetree]

If you read the last blog (December 2017) Alex is now in charge of JQM and JQUI. In this blog post he (Alex) clearly states that he's looking for volunteer developers and maintainers.

Having said that, I've heard from several people who have told me just the opposite. That they have reached out and either not heard back or been "dissuaded" from pursuing JQM any further. Since I only have one side of the conversations, I can't vouch for the accuracy but another comment within this thread leads me to believe what I was previously told is true.

Considering how many years went by without an update on JQM, and considering that JQM 1.5 was placed into Beta in May of 2017 (nearly two years ago) and has had zero activity since that day, I question whether anyone is doing anything with this project. With so little activity and no one championing JQM, I question how the project owners expect to recruit anyone for anything.

As others within this thread have stated, other than being fat, the framework mostly gets the job done and is decent for some apps. However, times and technology have changed and users have higher expectations than what JQM, in its current state, can deliver and no one at jquery seems motivated to speak up, lay out a plan or, more importantly, show any form of progress.

As of today, I have two apps that still use the JQM framework and one of those is getting a major update and will still use the JQM framework through this release. However, our road map calls for moving completely away from JQM because it's not being maintained.

Trust in technology is fragile. If you're not delivering, developers, users and customers will find someone who will. The fact that so many developers are speaking out is an indication of how far JQM has erroded that trust.

[rszimm]

So I’m curious here. I’ve got an old project I’d like to refresh. I used the jQuery stuff because it had easy to use controls that operated well on mobile and it had a framework that allowed me to dynamically/asynchronously pull and process json files from a server. It was really nice for getting maybe a dozen pages up and running quickly without a super heavy framework.

Any suggestions for something that’ll fit that niche?

On Mar 23, 2019, at 7:26 AM, Phil Petree notifications@github.com wrote:

If you read the last blog (December 2017) Alex is now in charge of JQM and JQUI. In this blog post he (Alex) clearly states that he's looking for volunteer developers and maintainers.

Having said that, I've heard from several people who have told me just the opposite. That they have reached out and either not heard back or been "dissuaded" from pursuing JQM any further. Since I only have one side of the conversations, I can't vouch for the accuracy but another comment within this thread leads me to believe what I was previously told is true.

Considering how many years went by without an update on JQM, and considering that JQM 1.5 was placed into Beta in May of 2017 (nearly two years ago) and has had zero activity since that day, I question whether anyone is doing anything with this project. With so little activity and no one championing JQM, I question how the project owners expect to recruit anyone for anything.

As others within this thread have stated, other than being fat, the framework mostly gets the job done and is decent for some apps. However, times and technology have changed and users have higher expectations than what JQM, in its current state, can deliver and no one at jquery seems motivated to speak up, lay out a plan or, more importantly, show any form of progress.

As of today, I have two apps that still use the JQM framework and one of those is getting a major update and will still use the JQM framework through this release. However, our road map calls for moving completely away from JQM because it's not being maintained.

Trust in technology is fragile. If you're not delivering, developers, users and customers will find someone who will. The fact that so many developers are speaking out is an indication of how far JQM has erroded that trust.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ppetree]

If you're just "refreshing" I think you could stay with JQM. MOST problems have workarounds. You can easily create a new theme or simply flatten the old one out. Liven things up a little without doing a lot of code work.

On the other hand, if you're doing huge work then you may be better off starting with something new. One project we ported to Bootstrap and that was OK... nothing to write home about but lots of support and continuing development.

We are also looking at Flutter for a project. Flutter is Google's own cross platform development tool (cordova's competitor). The cordova tool chain is incredibly fragile. Some plugins are desperately in need of an update and we're tired of all the "not my bug" finger pointing. One of our products is reliant on a google service and without using the SDK for that service we get billed very heavily. There is one plugin using the SDK but it's riddle with bugs. Flutter has a google provided plugin for that service.

[rszimm]

What about raw HTML5? Or am I going to be stuck spending hours trying to do simple things that come for free in any framework?

On Mar 23, 2019, at 10:24 AM, Phil Petree notifications@github.com wrote:

If you're just "refreshing" I think you could stay with JQM. MOST problems have workarounds. You can easily create a new theme or simply flatten the old one out. Liven things up a little without doing a lot of code work.

On the other hand, if you're doing huge work then you may be better off starting with something new. One project we ported to Bootstrap and that was OK... nothing to write home about but lots of support and continuing development.

We are also looking at Flutter for a project. Flutter is Google's own cross platform development tool (cordova's competitor). The cordova tool chain is incredibly fragile. Some plugins are desperately in need of an update and we're tired of all the not my bug" finger pointing. One of our products is reliant on a google service and without using the SDK for that service we get billed very heavily. There is one plugin using the SDK but it's riddle with bugs. Flutter has a google provided plugin for that service.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ppetree]

That's a hard question. Really it's the one question that @bboussou and others are trying to figure out. As @jtara indicated, it's never an apples to apples comparison because none of the frameworks are specifically designed for mobile apps.

I've seen people go native and, in my mind and especially in this day and time, that's simply barbaric (like using the cordova CLI). I've also seen people back off JQM and simply use HTML, jquery and a 3rd party gesture manager. We looked at going that route... ditching JQM and going to JQUI and using something like touchpunch for the gesture handling. We had also found a $500 replacement for JQM but we didn't feel comfortable enough with buying in.

I'm afraid, you gotta make your own decision on this one...

[boussou]

@rszimm if you want to go raw, maybe starting with bootstrap would be better. Css side, I like that framework : Groundwork CSS 2 ♥ A Responsive HTML5, CSS & Javascript Framework https://groundworkcss.github.io because it is lightweight & fast even on older devices. (I would say, this is how JQM should have evolved ;-)

To replace pure jquery stuff, the simplest I would recommend is Vue 0.12. Not the last version because it became bloated (some say "modern").

Or maybe Rivets.js, which is easy to use for jquery users? ;-)

[ShamimIslam]

Just took a look at Raw. I think we should redo JQM using Raw. Use Raw to create the JQM widgets. Thoughts? I've been a strong JQM advocate for a very long time. I'd like to retain backwards comaptibility. There are also a lot of designers out there that can do JQM 1.4.5 So I would suggest we create something that can read in JQM (for use with legacy or designers) and then use the translated Raw for implementation. It will also avoid the JQM runtime DOM manipulation that can be done ahead of time for speed. I would invite suggestions/comments.

I do agree with everyone else. Being in charge in name only means we should go to the higher level maintainer with a vote of no-confidence and elect someone new or we fork and start over.

[ElliotNB]

It will also avoid the JQM runtime DOM manipulation that can be done ahead of time for speed.

Interesting -- that's what we do too, but with the Nimbly framework. No manual DOM manipulations and all JQM component enhancements (e.g., enhanceWithin) occur in memory before the component hits the page.

I'd be curious to see what Raw is -- do you have a link?

[boussou]

Nimbly: isn't that close (in features) to Backbone + Epoxy or Backbone + BB Modelbinder? i would rather use that to avoid using ES6 proxy: it is far from compatible with every device (Safari & IE ahead, but as we know, Safari is the new IE).

[ppetree]

As far as I know, raw means native... I did some quick googling and I found nothing about a Raw framework so I'm not sure what @ShamimIslam is referring to.

[ShamimIslam]

@pptree @ElliotNB Apologies. I read the earlier post too fast and didn't realize the link wasn't "raw". It is Groundworks - See above.

[ShamimIslam]

P.S. Just tossing out ideas. Not suggesting we use only one particular source. But the niche provided by JQM is important. I used it BECAUSE under the hood it was vanilla JS. That meant, I would know every line of code that was running and not be beholden to hidden javascript conversions in my code. The only foreign code was the jQM library. Under angular and all those, there are javascript compilers generating syntactic sugar. Sure it makes some things harder, but it also avoids a particular platform deciding that a FEATURE of JavaScript is no longer available to you (e.g. Angular requiring a PIPE just to allow HTML in inputs). For those of us that are mature coders that cut our teeth on 8086 Assembly, syntactic sugar should only be that - and not prevent us from dropping down levels to do what is needed. This is something JQM was very good at. Alternatively, RUST requiring me to write unsafe code in C++ is a no-brainer. I can code safely in C++ faster than I code in a language that doesn't let me drop the training wheels.

[boussou]

"I used it BECAUSE under the hood it was vanilla JS." True. And if you look at it, React and all the similar are nothing but JS hidden & used to generated HTML. Just like JQM. except you don't have to pull hundreds of mb at runtime and for building your application. And with the big difference that we know it works on older devices & browsers (So almost all) & it is fast.

[ShamimIslam]

I have my use case. I'm not about to drop JQM unless there is something compatible. Angular doesn't let me drop the training wheels. Angular has the same problem as Java. Someone else decided how to code. JQM lets you make those decisions. Now, if I could just type out the JQM HTML after the DOM changes for speed, that'd be great. I've done it before for individual line items but only through experimentation.

[Bachstelze]

On one way or an other JQM will live on. The code is going to be here forever as a test version or hopefully for the production. Everbody has to decide what he is doing in this state on his own. For me as a new starter to JQM is the question: What can be done to get a stable Version 1.5?