Can we all admit this project is dead? #8612
Comments
|
yep |
|
Insert random Dr. McCoy clip here... |
|
@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. |
|
@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. |
|
@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. |
|
I'd also like to see development and maintenance back at a healthy level. Some ideas are:
"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." |
|
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. |
|
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. |
|
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. |
|
Would Ruby on Rails + Turbolinks be a viable alternative? |
|
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. |
|
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. |
|
@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/ |
|
@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. |
|
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. |
|
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. |
|
Funeral? |
|
Wake! With lots of alcohol! ;-) |
|
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. |
|
Not only this project is dead, also the jquery-ui is definitely dead, just don'e use it or do a migration |
|
I've switched to bootstrap. |
|
jqWidgets or leave jquery all together. |
|
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. FYI I compared mainly to
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: 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. |
|
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. |
|
That is one fact. Surpringly I did not test in iOS12 ;-) 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). |
|
@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. |
|
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.
CSS will change plenty in the next decade. Reasons for avoiding:
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: They are using JQM 1.3. Why do they expect it to still work?
|
|
@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
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. |
I have absolutely no idea. I've got similar code out there with multiple customers. Once in awhile, when using a mobile phone, the menu jams. Tends to be worse on iPhones. No matter what you do the menu just hangs. In both cases, I'm using a Single Page application, with I've got a hamburger menu icon that pulls out a left hand drawer with five menu selections. Sometimes the whole thing just hangs. Edit: I'm able to reproduce the failure on desktop emulator. Select each of the five menu selects in order. Then reverse. When I get to my sixth menu select (item # 4) the whole thing hangs. Home-2-3-4-5-4-lock-up. Most other combo's work just fine. I've been unable to figure out what is causing it. There are no error messages. Not seeing anything in the tail logs on server. Sometimes you can clear the menu by dragging from left of screen. Generally you have to clear Safari (iphone) or Chrome (Android) storage to clear the issue. Note: I'm using a file I picked up from JQM demos, Happy to show you the details (send me an email) I don't want to hijack this issue with my troubles.... |
|
Have you considered using the closure transpiler to compile to ECMA3 on the
iOS devices or all devices for that matter?
Also, if it' a PWA, you can use a macOS VM and test it in safari or in
chrome w/ the debugger.
What version of JQM?
…On Sat, Jul 20, 2019 at 1:29 AM Zip ***@***.***> wrote:
Menu hang? From what?
… <#m_4298357630405760119_>
I have absolutely no idea. I've got similar code out there with multiple
customers. Once in awhile, when using a mobile phone, the menu jams. Tends
to be worse on iPhones. No matter what you do the menu just hangs. In both
cases, I'm using a Single Page application, with <div data-role="page"...
navigation. Authentication via Ajax call to Google Auth, and confirmation
via node server. Remember I'm using a Progressive Web App, so you can't
really see the jqm # url in display.
I've got a hamburger menu icon that pulls out a left hand drawer with five
menu selections. Sometimes the whole thing just hangs. Not when I'm using
the site in a browser, but only on a phone. I can repeat the failure on
mobile devices, but I've been unable to figure out what is causing it.
Generally there are no error messages. Not seeing anything in the tail logs
on server. Sometimes you can clear the menu by dragging from left of
screen. Generally you have to clear Safari (iphone) or Chrome (Android)
storage to clear the issue.
Happy to show you the details (send me an email) I don't want to hijack
this issue with my troubles....
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8612>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAXKQTTRXLZVGEZUSWOJWE3QAKPDRANCNFSM4EPWIU5Q>
.
|
|
Oops.
Edit: As I think about it... perhaps this menu lock up issue is way better discussed in the open over at StackOverflow with [jQuery-mobile] tag... Even if we have to do so after the fact... Edit #2: So I've created a stand alone [jquery-mobile] question over at StackOverflow... . It took awhile to create a simple app that displayed the issue. Appreciate any feedback on the issue... thx. |
|
Follow-up. For my use case, I'm jumping over to Bootstrap and a simple sidebar menu, ref: https://github.com/zipzit/Bootstrap-SPA-Sidebar-Menu This works well with no more menu lockup. |
|
On the subject of whether JQM is active/dead can I ask people's opinion on the following. I am about to start a module on mobile app development in my third year of a CS degree and I have just learnt that JQM is the platform we'll be learning. Should I be concerned about this? From what I've read this is not a desired industry skill/not being properly supported/basically being deprecated. Should I challenge the university on this or do people think JQM is worth teaching/learning? Thanks |
|
While you are learning JQM you could look into other nostalgic skills like fighting using a halberd or leechcraft (.... I'd push back on them) |
|
In the JQM forums the moderators are advising people to not start any new projects using JQM. That’s as close to an official statement of death as the JQM people have the guts to give.
Learning jQuery is probably a part of that course so none of that time will be wasted.
Beyond that, challenging the instructors will do little as they are incapable of changing directions at this late stage however in your end of course review it would be wise to point out they’re teaching dead technology.
|
|
IMHO, for teaching purpose, it may be still relevant because when learning it is better to start on simpler examples. Learning should be like adding bricks to a wall. JQM has the folllowing properties:
It shall be interesting to list the alternatives that are not linked to a framework (ie https://framework7.io/ which is very slow) |
|
The only drawback to JQM has been that there was never a JQM compiler that would either package the screen as data or pre-decorate and store the HTML so you could use it to speed things up. JQM always had the first hit as the decorate step on every browser. Not sure why because the decorated code was supposed to degrade gracefully. |
|
The major problem with JQM at this point is no support and no future. IMO, there will be no future releases, whether new versions or maintenance updates. It is hard to ignore that one. jQuery Foundation needs to put out a clear statement that "it's dead, Jim!" The project lost it's major sponsorship (Adobe) years ago. Contrary to popular belief, most popular/successful open-source projects have deep-pocket sponsors, and are not grass-roots efforts. This was particularly the case with JQM. Adobe (and a few others) contributed both money and personnel, and that sponsorship is no longer in place. JQM 1.4.5 - the current production release - was published on October 31, 2014. More than five years ago! JQM 1.5.0-alpha1 was published on January 11, 2017. Almost two years ago! The web moves faster than this. JQM is rapidly receding in the rearview mirror. No, that is too generous! It is a tiny, barely-visible dot. And simply not true that it is "still fast and works on every device and in a browser". Cracks are showing everywhere, and will continue to develop. JQM was one of the earliest steps toward web components, plugging a gap until an industry consensus developed and the browsers have now implemented web components with similar concepts. (FWIW, I also see React as an interim gap-filling technology that is also itself now past it's prime. Schools should now be looking at teaching web components rather than React. By the time current students are in the work place, React will be well on it's way to being an obsolete technology.) "Decorating" the DOM in Javascript is an "expensive" (slow) operation. Long lists have always been a performance problem, which I've solved in past projects by pre-rendering, or just skipping the use of Listview and creating your own CSS for simple HTML lists. While Web Components essentially do the same thing - decorating or elaborating the DOM - they do it in a much more efficient way, with they heavy lifting now done by native code within the browser APIs. Decorating using Javascript is now an obsolete technology. Nobody should be teaching JQM in a university course. Yes, push back. If this is not a required class, skip it. If this is a required class, I would suggest a critical review of the entire curriculum. Somebody did not get the memo. If the course is optional, and there is one featuring Web Components, substitute the Web Components course. That would be forward-looking and much more appropriate at university level. In addition to being a pragmatic tool going forward, it actually would introduce some useful computer science concepts. The only usefulness of this class is to teach a lesson that will perhaps be useful in the future in a real job. You will sometimes be tasked with using some obsolete technology that has no future. Sometimes there will be a good reason - e.g. existing project, without a budget to update to newer technology, and perhaps not the need - e.g. the product has a short remaining life. But sometimes, management is just clueless, will not listen, and you will just have to suck it up and do as they say. BTW, re: "moderators". There is one moderator for the jQuery forums (to my knowledge) and that is Jake. Jake has no connection with the jQuery Foundation and no control over release schedule, policy, etc. He is a volunteer long-time peer member of the forums. I have been a frequent contributor, but much less so lately, as I haven't used jQuery Mobile in years, and am phasing out use of jQuery altogether, as there is little need for it today in new work. The forums are by and large "just us chickens". Representatives of jQuery Foundation make some rare appearances. But the forums have never been represented as anything but a peer-peer exchange of help and ideas. If Jake or myself did not respond to posts, there would likely be no responses. P.S. I would love to know what university is still offering (requiring?) a course based on JQM. Are you willing to name and shame? |
|
Yeah, what he said.
|
Perhaps the University might step up, volunteer to formally help the JQM infrastructure, and convince the current github owners to relinquish control? (Frankly I don't understand why the current folks wouldn't release to a group with a hopeful chance of success...) ?? I will say, I did really appreciate the nicely written programming guides that went along with JQuery Mobile. And I still like the overall appearance of simple websites produced with JQM content... Sigh. But on its current path, I'm not going to commit another moment of time to it... big Sigh. |
|
I agree. The JQM owners need to cede ownership if they're not willing to work on it to those of us who are. I've been wondering why we have to wait so long for the JQM folks to accept that they're not able to sustain the project any more. It's not about credit if the main person doesn't have time and others want to take ownership. I personally forked the jqm.com and jqm repos yesterday just in case the JQM folks decide to go by the wayside. However, it would be VERY beneficial if there was some transition or knowledge transfer from those that are no longer able to maintain to those that are. There is no reason to hold that knowledge hostage if JQM is going by the wayside. It's not like JQM is going to be monetized any way whatsoever other than through supporting projects. If the work on the project is ceded, then there are more opportunities for JQM experts to provide support. Especially if they first teach the new maintainers of how things are meant to work. Clean room reverse-engineering is so tedious. |
|
P.S. The last project that died without any recourse was the Intel XDK. But however, that one was proprietary in it's license and could not be ceded because Intel was unwilling to do so for company reasons. I don't think JQM has any such encumberances. |
|
I feel kind of bad putting out there but I think people should know it's Birkbeck, University of London. Thank you for your responses, I think it's appropriate that anyone reading this who is thinking of going to BBK knows what is being offered. I am going to try a module transfer to something else and let them know about my thoughts and reasoning. Hope the comments may help someone else down the line |
|
@AndrewMacmillan87 FYI - many of the JQM and JQuery concepts were used by other products such as Angular - at least in prior instances such as AngularJS. |
|
@shaminislam - Intel XDK was a big loss to the cloud build community.
Several years ago I visited Framework7 and found it and the support
"lacking." I've recently revisited the product and it's leaps and bounds
ahead of JQM. If you completely rewrote JQM, it would take you years to
catch up with F7 and the support is far, far better than it ever was and
you get the added benefit of not having to deal with the passive/agressive
snarky comments from the JQM support people. If I had one gripe about F7
it would be the documentation really needs improvement. At this point,
we're still evaluating F7 but it looks like we'll port a core project over
and give it a whirl.
|
|
@ppetree I would agree about the Intel XDK. I pleaded with the Intel XDK group to opensource the editor at least so that we could extend and maintain it. The designer was awesome. I was able to fix some things that were broken in JQM under the XDK designer (hammer.js) and others. Even w/o the cloud build option, it was amazing. I still miss it. I'll checkout Framework 7. Please keep me posted about the F7 porting. Thanks. P.S. Everyone seems to be on the Angular/React/Vue bandwagon these days. Thoughts? |
|
@ShamimIslam - there were a ton of us who tried to get them to open source
the project or even buy it from them but their response was that "too much
of the product was licensed from other people and it would be a nightmare
to work through transferring all the legal agreements (and some wouldn't
transfer)." Yeah, I really miss it too... especially the debugger! That
thing was aces! JQM made a lot of things easy but only if you were doing
the simplest of apps, when you tried for a more modern app then JQM fell to
pieces. The product really needed rearchitecting. I'll post here about F7
as I get through it. Right now working on adding fontawesome to it,
disabling menus items etc.. The hard stuff I've figured out (those were the
deal breakers) so now its just nailing down some of the easy things. I
would encourage you to download the kitchen-sink (core) and building it
into a test app. BTW, they also have F7 integrated with Vue and one other
but we have too much code in jQuery and no need to port all that.
|
|
@ppetree I'll watch for your posts. In the meantime, I just have one dumb question. Who in the world decided that the Android default HTML5 calendar widget was usable on mobile devices? Do any of these toolkits have a better option? The only option I found was Jtsage's flipbox calendar but that doesn't work with everything in every scenario. There was another one that I can't remember but it wasn't open source. |
|
F7 has a default, range, multiple and various other calendars you can play
with in Kitchen-Sink.
|
|
@ppetree Touch enabled? All these calendar widgets that look like calendars are NOT usable on mobile devices without a stylus. |
|
Touch enabled... yes... mostly... all the taps are handled and you can easily add taphold. Generally, F7 didn't implement a touch or swipe handler such as hammer (which I hate) so I added touchSwipe which is a jquery plugin and works well with jQuery. |
|
@ppetree - but does it have 1/2 inch x 1/2 inch or 3em x 3em hit-boxes? If not, I'm not interested. Almost every calendar widget that looks like a calendar is too small. If it looks like or works like a drum or a dropdown, it works better. Drum is preferable. |
|
Best advice is to just download it and build it into a simple app... there is a .js and a .css you have to copy from one directory into their rightful places but overall its a 10 minute job. I have a project just for trying and testing new things - typically I just modify the config.xml or drop in a complete www and build via PGB and I'm good to go. I have the kitchen-sink on a domain but I have no way of IMing a link to you. |
|
It is really sad to these the project not being developed anymore since it still has potential. For small screen devices and simple APPs it is a great framework and very easy and fast to develop. It does its job very good but slowly gets outdated. If there are so many legacy apps and companies it should be possible to get enough subscribers for paid support or monthly fee to get access to new updates. Sadly PrimeFaces using JavaServerFaces also dropped their support for jquery mobile since they removed their PrimeFaces mobile framework. |
|
I agree with that. The touch/swipe handler was excellent as was the multi-page router. However, the rest of the widgets had really fallen behind in the market. I've looked at splitting those sections out but really just don't have the time. |
|
I don't understand why this great project has stalled, it has so much potential and can be used as comprehensive platform ui framework for windows, android and ios - still with the old version 1.4.5 it is still useful for such projects. |
|
As I was told by an insider, there was just too much infighting over the
future of the product and the person behind JQM left out of frustration.
There were a lot of features that were excellent (multi-page routing, built
in touch/swipe handing) etc. that made it a nice framework. Now you can
use jquery and bootstrap or framework7. Framework7 is the closest drop in
replacement but I wish whomever did the docs for JQM was doing them for F7!
…On Fri, Jul 24, 2020 at 5:10 AM Andre Lorbach ***@***.***> wrote:
I don't understand why this great project has stalled, it has so much
potential and can be used as comprehensive platform ui framework for
windows, android and ios - still with the old version 1.4.5 it is still
useful for such projects.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8612 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSDEKJUBQLUDJTEKJET3DR5FFYLANCNFSM4EPWIU5Q>
.
|
and others
And update the website and README accordingly?
The text was updated successfully, but these errors were encountered: