A rascally wabbit told me that while google is currently flagging apps built on JQM and that us developers can clear those flags that will end around mid 2020 and apps built on JQM 1.4.5 will no longer be allowed in the app store.
To be clear, JQM isn’t the problem, the problem is that JQM only supports jquery version 2.1.4 and 2.1.4 has several known security holes. Because of Google and Android’s lackadaisical attitude towards security, Google and Android have been taking some serious hits in the media and user perception is switching to iOS being more secure. It’s these hits and shifts that are driving these security changes (notice how many apps used by millions of people have been booted from the app stores in the past 4 months?).
Which brings me to the point of this post… What ARE we to do?
For my main app converting to a progressive web app (PWA) is simply NOT an option.
Converting to Bootstrap 4, seems like an easy option, it really only solves part of the problem. The issue is you loose all the touch/swipe and page management features. While replacing the touch/swipe gestures is easy enough, the page management features is a much tougher problem.
I’ve looked at Framework7 and to be clear, I am a fan and there are many things that F7 does far better than JQM, there are also many things that simply don’t work (i.e. large square buttons with two rows of text or implementing fontawesome icons in specific places like the main menu or even a reverse animation on the page transition).
The next option leaves us jumping ship entirely and moving to React Native or Flutter but that’s an entire rewrite on an unfamiliar platform and, frankly, market demands dictate a release long before I could accomplish the rewrite.
I think their is an underlying problem that plays into this dilemma. As developers we are always wanting to use some new feature that exists within a framework that is not used by our base IDE we did pick. It would be great, and AS sort of allows this in the toolbox feature, to integrate the best of other frameworks into the IDE we’ve picked. Apparently nobody has really used this feature of AS, other than the items already included.
Whether you use the toolbox or just include another framework into your AS project, it still requires the various frameworks to work together, and that is not going to be the case, many times not practical to make adjustments so it will work. So it sounds like we will always be chasing the best overall framework, trading off this for that.
It would be nice to have a definitive comparison of frameworks and which ones play well with the others. Obviously we would like to also compare control types, styling, etc. as well, giving the developer an idea of what frameworks are designed for his/her project scope (like gaming vs data entry).
I’m going through a similar dilemna. I have a project that has a majority of the code base with JQM. It will be a monumental task to convert.
At this point, it would be easier for me to really touch down with React or Vue. At this time I am fav’ing React just because it seems much easier to dig deeper into and the community is huge.
With JQM, I can create anything. I remember the first time I saw JQM, it was all magical to me. Gonna miss it.
I have 5 projects out there based on JQM (all with custom themes) and while there’s a whole lot of spelunking involved in certain aspects and there are numerous pieces missing which are needed for a more modern UI, it’s still pretty amazing what you can do with it with little effort.
I have a few projects I can port over to Framework7 and I will do that in the spring however the one I’m most concerned about simply won’t port to f7. Like @cayocoder I’ve looked at React Native but it is a monumental task and requires deep learning, a new UI and whatever else. It’s not like you’ll pick up “Learn React Native in 24 Hours” and be even remotely capable of producing “Hello World.” However, according to this article, React is still VERY popular.
I wonder what it would take to unhook the page management from jqm? Has anyone looked (cough cough @ghenne )
I know there are some beginners on here so for those who don’t know there are two basic types of hybrid (html5) architectures:
SPA - In a Single Page Architecture, all of your app pages are held in one file which is usually index.html. When a user goes to a page, the current page is hidden and the new page is unhidden (displayed). This usually involves some form of animation that makes it look like a page is coming in from the left or right.
MPA - In a Multi Page Architecture, only one page is in the index.html and the others reside externally. The external pages don’t have all the “stuff” that’s in the index.html file. For instance the head and body tags are missing as is the javascript.
In either case, when the user navigates from one page to the next, this navigation is handled by a router. JQuery Mobile has a GREAT router that works with both SPA and MPA apps. React as a router as does Vue. However, once you get away from those frameworks, you loose the router. For instance, Bootstrap doesn’t have a router.
There are several open source SPA routers available but there are no MPA routers.
So, the question I get asked the most is “Why MPA? Why not just use SPA?” The answer to that has to do with size. The webview that runs your app only supports “about” 2700 HTML elements. This includes everything not displayed such as all those div and span elements. In one app I have 20 pages plus the index.html and I still have 3 pages left to write. Each of those pages also have javascript files and the index.html file has 8 javascript files PLUS all the .css files. An app can grow quite large and, when that happens, when the app loads (if it will load) the user interface looks like hell and it gives a very bad user experience.
Granted, most people only use a few pages (I think the study was 6 or 8) so they’re generally fine but once you’ve written several apps you start adding more pages (help, feedback, tutorials, about, settings etc. etc. etc.) and the size can stack up quickly. Also, why keep all these pages in memory when they’re not used very often? For instance, how often do you think a user will run the tutorial? Once? Twice? (if more than twice you may want to rethink your design a bit.)
@PPetree I just downloaded Framework 7. All kinds of goodness there. I downloaded their kitchen sample and it’s got pretty much everything one would need. I was able to compile an android apk out of it using cordova cli.
But I think my heart is set on React. It’s just so ubiquitous and the support, community, and resources are easy to get.
I’d love to see @ghenne add Framework7 to AS. I think that would be seriously awesome.
As for react there are two big issues:
The Mac Thing: Unless you’re developing on a mac then you’re not gonna build an ios app with react. That leaves most of us windows devs in out in the cold or forces us to spend a grand or so to get a used mac.
That Trust Thing: I don’t trust Facebook. Since pieces of the DOM runtime module aren’t shared, I get the heebee jeebies thinking about FB getting hold of my users data. I don’t want to build apps and then have it come out that Facebook is spying on my users (especially since many are government users) and I’ve not found anything wherein anyone can assure me that FB won’t / isn’t spying. How do you protect yourself against this legally? What will happen under GDPR if it turns out that FB is slipping something into the app? You really wanna pay a multi-million euro fine because you “should have known?” Yeah, not me.
I’d have to do that across 20 JS files and load in every page and manually run the tally but on the home page it’s 170 and it just displays 9 buttons. And, like I said in an earlier post, it’s not just the HTML limits, it’s loading in all the other crap too.
Not really too sure if it’s a “Mac Thing”. Back in the 90s if a I wanted to develop apps for Windows then I needed to compile on a Windows machine. Back then, I had to shell out money for a Win 3.1 operating system. In the mid 90s, if you wanted to develop for RIM Blackberry, you had to shell out money for their dev tools and their BIS server. I believe it boils down to the tools you have and the choice you go with.
Today it is a different story. The thing about Mac is I can deploy for for iOS, Android, Linux, and using virtualization just about any device I wanted – including Windows. I believe choosing the tools that will give me the most reach is important. At this time, I can’t say the same thing about Windows. Maybe that will change. Web Assembly is looking really pretty right now as well.
However there are options. If you get a hold of a OSX iso, you can compile an iOS app with virtualization technology, some of which are free. There are also services that allow you to rent a Mac for an hour, a day, a week, a month(s) for a fraction of the cost of what you would pay for a used or brand new Mac. The reality is, if you can’t shell out $300 for a used Mac, then maybe the iOS app store is not for you or the ROI is not viable and I get that. You only really need it to compile just like I would have needed a Windows machine to create a Windows executable.
As for React and Facebook and the “Trust Thing”. I’m not familiar with your assertion about FB controlling the DOM, I will need some education on that.
My guess is you may be thinking of React.js vs React Native. React Native is open source and is specific to mobile and from what I can recall, it can be inspected if you really wanted. React and React Native share the same parent(s) in that it was created by a programmer who worked at Facebook. But from what I understand, he nor FB is controlling any behind the scenes DOM manipulation.
In the context of this forum, when I referred to React, I’m looking at React Native. My apologies if that wasn’t clear.
After dealing with slow DOM manipulations from the window inet IE api, I know that large element counts can be very slow to search for elements, and generally those large pages take a long time to load. I’m working on a simple prototype, and it has 103 elements. I can easily see my proposed app being over 3000 elements.
Maybe this question should be a new thread, but how are we supposed to write serious apps with AS and not get a DOM bottleneck situation due to excessive DOM element counts?
We haven’t seen a project with a bottleneck due to excessive DOM element counts, and we’ve built some pretty big projects. I would be wary of premature optimization in this case. (“Premature optimization is the root of all evil.” This famous quote by Sir Tony Hoare (popularized by Donald Knuth) has become a best practice among software engineers.)
It might be better to approach a case like this (should it occur) by analyzing why it has so many DOM elements and whether it would be faster to dump and redraw them than to leave them around. (Hint: redrawing is much slower!)
My thoughts as well. I don’t want to think about problems that haven’t come up. But it is nice to know what to look out for.
I met Don when I was a kid. He hadn’t written his Art of Computer Programming at that time. Great book. So were his other papers back then. But he was pompous and a real bore in person.
)
lol