Statements about the Mobile Web
jlongster.com
jlongster.com
http://www.slate.com/blogs/future_tense/2014/08/25/a_comscor...
This matches my experience IRL exactly. The whole Native Apps are more popular than the web narrative is a self fulfilling prophecy. People have trouble using websites on mobile because everyone puts up stupid splash pages on sites to force them to download their app. It "educates" people that the web is somehow inferior, when really those sites should be making a proper responsive website so their users can get on with their lives.
Nobody gives two shits about your app and it's smooth animations when they are just trying to pull up a recipe for chicken tikka masala.
For example, I don't think Flipboard's use of Canvas to wrap content with fancy animations and magazine-style layout is really a damning indictment of the web platform. It's a failure to understand the medium on their part.
We've got a mature, interoperable, write once run anywhere platform that's completely free to participate in. It has some critical deficiencies I'd like to see fixed rather than abandoned.
Making a "proper responsive website" for mobile is far more difficult than it needs to be. Assuming it can even be done. Some things you simply can't do. Can you reach just short of native quality by expending significantly more time and effort? Yes! Is that stupid and wasteful? Absolutely.
I'm not sure I agree. The JS libs are out there, you just need to find them.
Dynamic Physics Interactions for the Mobile Web: https://github.com/luster-io/impulse
Facebook and Path style side menus: https://github.com/jakiestfu/Snap.js/
Smooth scrolling: https://github.com/cubiq/iscroll
Add to home screen call-out for mobile devices: https://github.com/cubiq/add-to-homescreen
Cross-browser usage of the JavaScript Fullscreen API: https://github.com/sindresorhus/screenfull.js/
Anybody know of any more?
"That being said, it is unfortunate that we still need to include a JavaScript library to workaround a limitation of the mobile web."
Thanks for the great link though!
It's easy to say that obviously they are shitty designers and/or coders and all they have to do is take the time to do it right. Well doing it right takes too much effort. And doing it right still doesn't get you all the way there. For any site with even a moderate degree of complexity there are always little bugs. It's just a fact of life in the HTML/CSS world.
Who told you that? It doesn't take any more effort than a normal desktop site given the right tools.
There isn't even a widely supported, idiomatic way to switch between high dpi and low dpi images for crying out loud. It's been at least 5 years since such devices were common and wide spread.
No doubt, the majority of mobile websites need their asses kicked.
Migrating old websites that do not respond + adapting web based apps to mobile is however, not very easy. These two cases are probably 90% of the use cases, as opposed to the other 10% that are "really really easy".
It means starting again, from design and UX all the way up to build. So for the entity that owns the website/web app it's going to be painful, but for every new website/web app, it's the norm and is pretty easy.
On my phone, that page is every bit as quick as a native app. The presentation doesn't suffer. It's actually quite a bit better than many native apps I've had the misfortune of installing.
More importantly, the content is actually discoverable from web search. The alternative is forcing the user to choose a recipes app from an opaque app store search, wait to download/install it, then search in that single silo of content and hope it has the content they want. Then, rinse/repeat if they don't find a recipe they like. Even if they happen to find a nice native app on the first try that does have a good UI, good content, and the specific content they want, that is a vastly inferior experience.
Can you create a poor mobile web experience? Sure. The situation isn't very much different than janky, slow desktop sites that are laden with too many third-party scripts for ads, tracking, social, etc. Mobile does exacerbate the effect of that kind of sloppiness, but I think that stems from sites where content is secondary to advertising/social, not the feasibility or difficulty of creating a good mobile web experience.
I was going to add a disclaimer to the link above asking folks to be gentle if they peeked under the hood, because I developed that site in an insanely short amount of time for how much content and functionality is there, but maybe that's an important data point in and of itself. If it were so difficult to develop a decent mobile web experience, there's no way I could have shipped that full site in about two weeks of billable hours. Not to mention, we focused a lot more on the desktop layout than mobile, based on analytics. I wouldn't say mobile was an afterthought, but the phone layout was a fairly small fraction of the overall effort.
I do still think a user that searches the web for a hickory chicken tailgating recipe is still a lot better served by even that imperfect mobile web page than the alternative native workflow though. Not to say that native isn't ever a better choice for some types of apps, of course, but content like this is exactly the web's sweet spot.
(BTW, I've been playing with React lately and am loving it; great work. Looking forward to giving React Native a shot at replacing Cordova for some of my clients)
At the same time, the state of the browser as a graphical environment needs some help. HTML+CSS is a great interface for written content, but when it comes to dynamic graphical interfaces, it's a little insane how much we've tried to squeeze into a glorified desktop publishing engine. I'd like to think the future is something more like mutually recursive embeddings of a graphical language and HTML. We kinda sorta of have that graphical language in SVG, but I think it lacks some of the features that make HTML really friendly.
> Almost all smartphone owners use apps, and a “staggering 42% of all app time spent on smartphones occurs on the individual’s single most used app,” comScore reports.
http://qz.com/253618/most-smartphone-users-download-zero-app...
I'm not sure that this is evidence that people don't want apps. They just don't want a LOT of them. The ones they DO want, they want very badly.
Nothing in the quoted sentence suggests anything other than "people use the apps that come with their smartphone.
The company I work for has both proper native apps & responsive web sites. We push customers towards the native apps because the difference for us is tens of millions of dollars, at least.
For example, I find a lot of stories to read on Facebook and Twitter. On my phone, I use their mobile apps. And when I read a story, what I'm actually reading is a mobile webpage that loaded inside the app's captive browser view (I'm on an iPhone).
So both things are true--I'm spending my time in an app, AND I'm viewing a ton of mobile websites.
Ruby on Rails vs Java - Commercial #1 of 9: https://www.youtube.com/watch?v=PQbuyKUaKFo
Erase the Native vs. HTML5 Development Debate with PhoneGap: https://www.youtube.com/watch?v=uea1kAXlGIY
Well I'm not a web guy, but I can imagine at least one reason: having to learn and work with a slew of proprietary software stacks to deploy the same thing over multiple platforms - the web finally looked like the solution to this problem until about 5-6 years ago.
I understand some cases: * Need for offline; * Need to work like an IM (instant updates pushed from a server, like a telephone / IM / email service); * Need to avoid latency in user experience (a native game, vs a web-based flash-style game).
But I don't understand any others, and really would like to know.
2. With my iPhone at least, I enjoy the predictable user interface that comes with doing stuff inside IOS.
3. I'll be honest. I don't like typing in URLS on my phone, and typing in passwords. It is a real pain when alternatively I could just click an app.
4. I really hate the mobile sites for some companies. The mobile site for my school is awful and always redirects you to some ugly main menus from the page you actually wanted. I would much rather just have the regular website.
(2) is bit hand-wavy in my opinion
(3) is spot on, bookmarking to homescreen is something people don't know about; typing a password is okay if it's only once I think
(4) is about prioritizing resources to the most popular platform: a website on desktop, a native app on mobile
2) To each his own. I've never really figured out what a native look and feel was since every app looks different. And it's not like non-native slowed down adoption of the WWW for desktops.
3) Bookmarks. Android at least lets you put a URL bookmark on your desktop too.
4) Same as 1.
Given this, I never quite understood the gold rush to go appize everything. I may be a web developer now, but if anything, my becoming a web developer has made me use more apps, not less, simply because I make hybrid mobile apps currently.
Microsoft, otoh, has done a great job with UI editors since the Visual Studio 2008 days, especially with WinForms. But it still lacks standard behaviors that HTML has in spades. I constantly find myself surprised by strange/unexpected behaviors with different controls in both XAML and Winforms!
HTML I've been doing for some 15 years, and it's still as easy to understand and edit as ever.
And all this repeats ad infinitum.
It's about time that we take history more seriously.
I've been saying this forever, we already have OpenGL viewports, we don't have to listen to the folks at W3C. Browsers draw on the screen. Why is each browser concerned with the rendering engine? There's already a rendering engine in every computer, it's called a GPU. And there's already a way to draw on it, it's called OpenGL Viewport. Much ado about an already-solved problem.
Switching to display: 'block' and it's under 100ms. I think now I'll look at using css-layout to just spit out absolute positions.
I also appreciate the shout out in the article to reapp. I've spend the last few days working with WebWorkers, which have some interesting potential, but without access to the UI are going to be tricky to implement. Again, the React guys have gotten something working, and we had an interesting conversation about using Flux to communicate between Workers/main thread, which I'll be exploring.
Long and short of it is this: We've gotten pretty damn close with the web these days. For anything that doesn't use exceeding long lists of media-heavy content, you can actually get 60fps with react. But you have to be careful.
I'd love to see UI workers, async DOM ops, and even Canvas support for better accessibility. Web developers should all be writing and voting up articles like this.
I'm now using React and the Flux pattern to use a single source of truth to drive all absolute position math. I very much like the model's performance.
I'm currently working on a React-like interface over WebGL, and everything is just "absolute positioned" - read, it's just GL matrices all the way down. It just works.
In the eight or so years that I worked as a system administrator and the many more years that I have been the go-to guy for all things computer-y for friends & family, I have found the vast majority of people to be tolerant towards the inconveniences and failures of technology to the point of defeatism.
The things people put up with sometimes boggles the mind. Eight minute boot time to a usable desktop? "Oh, I just tap the power button and get coffee". Half a dozen browser toolbars they never installed willingly. Popovers and popunders. Nagging Java updaters and upselling "security software". Forced reboots that kill your unsaved changes over lunch when Windows decides to install updates. And, and, and…
That story hasn't changed one bit on mobile. "Well, I know know that I have to restart my phone [for two minutes] before I can play this game, because it crashes otherwise".
There's a good chance that this is the majority of people interacting with your app, site or gadget.
If you can squeeze out silky animations and buttery scrolling out of a complex web app, go for it. I'm the first to marvel at your ingenuity and applaud.
But if you honestly think that these people care enough about "60fps scrolling" that it warrants reinventing pretty much the whole of HTML and CSS in Javascript — badly —, then I don't know what to tell you.
Despite the advances with CSS3, we're still working with a layout engine that was designed for documents rather than applications (mobile and otherwise), so many seemingly trivial tasks (e.g. centering and vertical alignment) involve an unintuitive mess that I after 10+ years of experience, I still need to lookup from time to time. [Edit: I should have been more clear--I'm referring to issues that flexbox doesn't resolve such as aligning/sizing elements relative to each other rather than to their parents.]
On top of that, we're seriously in need of better tooling. It feels like we've spend the past 10 years developing a set of powerful primitives but ignored building tools that truly empower our creativity on the web. Sometimes I really miss how fun and simple it was to use Flash to build things when I was a kid...
...and that's the whole point really, isn't it?
What is this legendary interface system that is better than the web? I'd like to use it.
EDIT: As for tooling, I guess it's just a difference of opinion, but I love the fact that there is none for the web. It forces everything to actually implement elegant and understandable API's. Too many IDE-based systems use the IDE as a crutch allowing them to create inelegant systems that would not be possible to use with it.
As for IDEs, I've always used a text editor for web dev, but there's something incredibly fun about being able to draw components and move them around on your screen as opposed to having to mess around with something like the Canvas API. I built fairly complicated little apps with Flash when I was 10 that would take me 10x longer (at least) to implement in HTML5.
They just re-invented HTML tables.
The replacement of HTML tables for layout with "float" and "clear" was a disaster. It replaced a 2D model with a 1D model. There were years of Javascript hacks to deal with that. Now, the 2D model of tables is back, but with a new name, because the cool kids won't use tables.
Just to give one example, the algorithm for computing widths of table columns involves creating four "candidate guesses" of all the column widths using different algorithms for each, selecting the two guesses that most closely bound the available width, and then linearly interpolating between them [1]. And that's the easy case, when there are no colspans: when you get colspans, the layout parameters are defined by a complex recursive series [2]. Flexbox has none of this complexity: it basically does the simple thing you'd expect.
[1]: http://dbaron.org/css/intrinsic/ section 4.3
[2]: ibid, section 4.1, "intermediate intrinsic minimum width for span N (N > 1)"
The fun begins when you think about how this impacts anything that tries to scrape web pages, because the side effect is going to be a lot of impenetrable data silos.
Google and co will have to actually run web browsers in the cloud and use OCR to do indexing if they aren't already.
http://www.androidpolice.com/2014/11/19/project-ganesh-demoe...
Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects.
http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today's hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable.
How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame().
-- edits clarifying ArrayBuffer
We want to be able to share js objects, arrays and strings in a fast way. Otherwise you either need to build your entire app on-top of raw buffer but that doesn't look like JS anymore, or you've got to do a serialization step and you're not gaining much compared to JSON serialization.
I'm super excited about immutability because it lets us share objects between different threads very cheaply and still letting us use normal js constructs. I'm not sure anyone is working on it though :(
Servo is going to completely expose the worst parts of our current web. I'm hopeful it will start influencing standards to expose sane APIs that make it easier for current engines to parallelize.
The React Native devs have a lot of reasons for the above, if you want more reasoning might be good to check it out when its released soon.
Still, that sounds really cool!
I am a big advocate of truly native mobile web, but honestly the first thing i look for when i love a service or website is: "Do they have an iPhone app?"
The only place I could possibly imagine that mattering is for fast-twitch video games, or theoretically videos (though most of those are still 24 or 30 fps).
It's about scrolling and animations. In videos it 24fps is enough because you have motion blur. In fact higher frame rate makes videos seem unnatural..
>Do people really care if their website/mobile app is 60 fps? Who are these people?
People who prefer native apps to webapps. Quite a lot of them actually.
And framerate in UI is a different beast compared to video. A menu animation running at 24fps feels much choppier and sluggish than a video running at 24fps.
I really don't want to argue about this so I figured I just let you experience it yourself: http://jsbin.com/qizatugepo/1/edit?js,output
Frame drops are a different story entirely. The swap_control_tear extension for OpenGL takes care of that to some degree though.
Having said that, shooting for your monitors refresh rate isn't a bad idea — it's just that you could use those cycles (and watts) for something else. And even worse, if your app is running at 60 fps most of the time but drops to 30 fps every now and then, then it's gonna look a lot worse than the one that runs at 30 fps consistently.
It's mostly related to the animations. I.e. scrolling, dragging. This is what makes the experience amazing.
But also, it's because every time you do a costly operation, ti freezes the screen and the user loses control. This is a solved problems in so many environment, frustrating that it's not there yet while developing cordova apps.
Those problems aren't that far from the web. There's no reason you can't draw entire pages made of canvas[top="0"][left="0"] and then measure position/transform everything by hand. You'd probably get great performance that way. Its basically what Flipboard did from what I read. Its what native app developers do as well. Phones suck. They have no power. You basically have to do this stuff to make them work. I have no idea why the web-dev community freaks out when someone does it. "You wrote a custom layout engine! Are you nuts!" is not something you'll hear from Android or iOS devs.
Apps integrate with the entire rich ecosystem of the device and web apps barely / inconsistently do. There is work happening on all of the above things (kind of), but the experiences arent competitive, the work is piecemeal and the pace is far too slow for people who have the webs best interests at heart. The web is losing because the consensus model for standardising and making available the tools for building the web is antiquated and terribly ineffective. Unless there is a massive change in incentives for standards committees and mobile browser providers this wont change.
SQLite is available on Android and iOS by default, and available for WinPhone 8.
Yet, some die-hard NoSQL lovers stopped the HTML5 Web SQL Database API: http://en.wikipedia.org/wiki/Web_SQL_Database
It's still available in all WebKit based browsers incl. Android and iOS. But famously Firefox/FirefoxOS and IE/WinPhone don't support it. The proposed NoSQL replacement IndexedDB has a complicated API and never got traction, one has to basically use a shim library. Working with several tables and indexes is trivial in SQL, but complicated and requires a lot of specific code in IndexedDB (NoSQL).
There would be place for SQL as well as NoSQL in HTML5.
* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature.
* Also the argument that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).
Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL.
To sum up, NoSQL has it's place and SQL has one too.
IndexedDB reminds me a lot of the Drag and Drop stuff the W3C settled on: several different kinds of awful.
Mozilla should have just shipped SQLite early and focused of proper file APIs and threading so developers can use any database that can be written in javascript. It turns out that specifying a database API takes years, having people agree on it and implementing it takes some more.
Even today, as IndexedDB is implemented by all browsers, both Firefox and Safari have a quick and dirty implementation written on top of SQLite, giving us less performance on a reduced API. Chrome has LevelDB (which is awesome!) on the backend but the result isn't much faster in my experience. IE I don't remember.
1) Microsoft made Windows too damn fragile. Installing the app means that setup.exe will write all over the hard drive, and uninstall was never easy. Web didn't required install/uninstall.
2) Windows programs, with a few notable exceptions, were/are butt ugly. Web started as an ugly abomination, but designers catched up quickly. Web applications, even then, on slow connections, often provided more pleasant experience.
Web app on mobile today doesn't have the same luxury - native app install/uninstall is painless; native applications are better integrated and most of the time handle unstable connections better; good native apps are beautiful and often have superior usability compared to web apps.
Individuals control most phones. The goal of the developers is to intrude on your device and you have permission to allow it.
The issues here are same as "web toolbars". Developers want to intrude on your mindspace and the web doesn't allow that easily. Consequently, they have no incentive to build good web apps.
If we are to replace with a native-app style model, it needs to be far far more transparent that what is on iOS and Android with respect to exposing links and content in a way that is transparent.
If we convert the Web into a Web of Binary Applications, who query all of their information through private silos, we may as well just close up shop, because we'll be forgoing the greatest values of the Web, Links and Transparency.
We need to stop panicking over mobile native and FPS.
The idea that "60 fps is required" is a complete myth. Most triple-AAA game titles people pay $50 for on consoles don't hit a solid 60fps, most of the time, not even a solid 30fps -- typically frames are dropped in busy parts of the game.
The ideology that Apple has foisted on design, that somehow no one will use your app if it is not perfectly rock solid 60fps (iOS isn't even 100% jank free) is damaging.
(1) a way to install web apps that hasn't to be learned, like Mozilla's Intall API, and unlike the bookmark to homescreen UI
(2) offline APIs: ServiceWorkers seem great but, Safari support could come as late as fall 2016 I guess, and be botched up for a year or two like they did with the history API and IndexedDB; in the meantime, offline web apps are screwed
(3) full screen API: not having the ugly address bar all the time which reminds users this app is unlike others and may be substandard; and being able to lock screen orientation
(4) notification API: the users expect anything important your app displays, they can be notified about, otherwise, your app seems unreliable
Except, the notification API, both iOS and Android had all of those from the start. Only then should we worry about performance, sensors, frameworks, layouts, ...
Regarding image decoding, why can't browser vendors do it today off the main thread? Is a change in web standards required? It seems no one has implemented it, so if it was a low-hanging fruit material to performance, it would be done already. In my experience, image decoding is only an issue for infinite scrolling, when javascript inserts images too late for the browser to have smooth scrolling. Infinite scrolling is nice sometimes but not all lists have to be infinite, have they?
I know that on day one there won't be anyone on your "Python Web" or whatever alternative browsing box you make, but if its nice to developers, and if it really does give users a better experience, then eventually we'll see people use it ... just like any good idea takes root in the long term.
I know the web is already here, and it makes a lot of sense to leverage the fast V8 engines we already have pre-installed on all our users' desktops and devices, but I am really surprised that we haven't seen any alternatives in the two decades since we've figured out that Javascript/CSS/HTML really suck for a whole class of applications.
I suppose you could say the JVM was one attempt to do this ... but the JVM was proprietary and it wasn't properly marketed to end users.
The app box I'm talking about should be something that users feel they have to download because it will be an infinite amount of fun.
Security is a huge problem I know. But surely we can figure out something using containers/VMs etc. to airlock all the random code that will be downloaded into the box by users.
That said, what you're describing is native applications.
Furthermore. There is already a solution: bypassing the dom and using canvas/webgl for the UI, and whatever language you want for the rest.If you want to use Python or Java, i'm sure you'll find an implementation that compiles to Js. The future imho is clearly C/C++ and EMSCRIPTEM with canvas/Webgl which would allow gpu acceleration for the UI and asmjs optimisation for the code. Which is totally ironic I must say. Using a low level language on a "high level" plateform.
Pretty much all successful platforms start as consumer products first. The PC was first a hobbyist curiosity, then a gaming console, then a tool for small businesses with Visicalc and Word Processing, and only became large enough to create mainstream software markets in the 80s, ~5-10 years after introduction. The web was initially a tool for scientists to share research, then a publishing platform for kids to create fansites, then became a large e-commerce & application platform. The iPhone started out as a phone, then a PDA, then got applications about a year or so later.
Mobile. Your new format has to be accepted by Apple and Google at minimum. So good luck with that.
Apple is not going to let you run on iOS, but other than that you can be low level and cross platform with a plugin fairly easily. The issue is it would take 10’s of millions of dollars’ worth of developer time and there is few obvious revenue streams to support it. Sure, open source sounds great but this is kind of tedious low level cross platform work is not going to be particularly fun or interesting to most developers.
Oh, right, thats Java, Flash, Silverlight, Unity Player, etc etc.
The pragmatic kid will try to find ways of sharing the toy, or get one of their own, but the stubborn kid will convince the others that their toy is batter, faster, smarter, stronger, and all of the things. The analogy breaks down a bit, but I hope my point gets across.
The web, for all its warts, is a wonderfully resilient system. It can break any which way and it'll still probably mostly work. Most other systems simply don't work that way, because it's damn difficult to build such systems. By working within the constraints of the web, you're almost forced into it.
What we can do to help developers better leverage the web, regardless of whether their UI is native or HTML, is to not be religious about the things that don't really matter – which I think is what James is trying to really say. His points are clear and good, but the underlying (and in some parts quite explicit) message is one of: let's not be kids.
Our toys are sometimes broken (DOM, CSS layouts, single thread execution models) and we should consider changing them for better models or even new ones, that aren't so broken. But we have to stop the in-fighting, zealotry won't get us anywhere.
---
It should also be noted that James' post while talking about the web is actually more about rendering than anything. There is so much more to the web, architectural principles that transcend platforms – such as hypermedia, stateless message transfer, metadata. Let's not pretend rendering is the end-all be-all that the web has to offer.
But also, to be fair, if Apple could fix their damn webview, performance would be much much better. I've been told that they're not fixing it on purpose.
If you're talking in a general case, it's because it is actually hard. Send the buffer to your gpu, have it execute the command, send it to your screen which probably has a CPU of its own. Pushing a pixel is hard, and you have to do it 60 times a second. That's also why you don't just push a pixel but the entire screen at once. How hard it is for you depends entirely on the API. While Direct3D/OpenGL expose all the details, others like XNA or even Javascript's canvas do it rather painlessly.
What's really hard isn't pushing a pixel to the screen: it's doing it fast enough (i.e. same as your screen's refresh rate ideally) so that the user doesn't notice a visible delay. When 75% of the API is blocking AND you do work on the UI thread (Which is absolutely insane that browser developers haven't picked up this practice considering it's been advocated for more than 15 years on the native side of things), it's usually going to be visible.
To answer your question: one reason is that the developer needs to express how elements on a page place themselves not just on the screen but with respect to other elements as well. As you can guess, calculating this "layout" will occur pretty often, and if you have only one thread running all your code, then your logic and communication with the server can interfere with the rendering of the UI - thus making the response choppy.
On native apps, though some of them have borrowed web-type expressions of placement or layout, the entire calculation runs on a dedicated thread. Not on the same thread that also needs to respond to touch / slide / drag events!
HTH.
I made the switch from web development to native app development after leaning this fact at the HTML 5 conference a couple years ago. Every framework, rendering engine, etc., touted its strength in terms of a percentage of native app performance: this renders 80% as fast as native code, that responds 90% as fast, etc., etc. At the end all I could think was why are we wasting our time with mobile web?"
I, for one, don't.
Why install a 500MB Facebook app when I can get the same news feed with a 1kb bookmark?
- A cross platform execution environment
- Hot code loading
- Fetch, load, run in seconds
- Source based; inspectable by user
- Complete separation from the host OS except via well-defined, permission-based APIs
- A mechanism for including 3rd party code and UI modules, fetched at runtime, and appropriately sandboxed
- A suite of strong, high-level, declarative UI APIs
- A suite of strong, low-level, UI APIs
- Good crypto support
- Pain-free concurrency
- A nice language that behaves well as a transpilation target
- Ints, floats, and all the other wonderful number types (and not just in arrays)
- Strong support for displaying structured information
- Accessibility, extraction, etc
- etc, etc, etc
And I'm sorry if I'm offending your world-view here, but JavaScript is a complete fucking mess. If you love it that's great - nothing to do with me - but as the only language on the dominant end-user runtime environment? What a sick, twisted joke. Honestly how much time has been wasted dealing with it's deficiencies? With a language that has a monopoly, every little quirk, every tiny failure in the design process that makes it do something you didn't expect translates to hundreds if not thousands of man-years shat away. I'm not exaggerating either: shit adds up at scale (and if you don't believe me, consider that the subset of British people who actually had reason to call the government(?!) last year spent a cumulative 750 years on hold).
So much of everything we do (in the western world, at least) is dependent on the technology we have for creating, moving, and consuming information, and the browser is the king of this world. So it's not just mission critical that we get it right, it's economy/happiness/progress-as-a-species critical too. A big shift here would be in the same ballpark as the switch from steam to internal combustion! And we already know it's possible, we're just too risk-averse to commit - but that's the short term view, in the long term digging this hole any deeper carries significantly more danger.
I suggest we take the plunge and commit to a wholesale overhaul to something correctly designed by the best minds around, and with an aim to deprecate the current system in 5-10 years. We're (slowly) doing it with IPv6 because we have little choice, let's not wait for that to happen here - let's get it done before we're in a corner and are forced to make a tonne of half-baked decisions in a hurry.
This right here is the damn truth. I don't necessarily agree with much of the rest of your post, but this is hitting the proverbial nail on its head.
Could you rank your preferences?
Built with http://platform.qbix.com
500KB of javascript and CSS code is another problem
That said, many apps don't need to push the limits and PhoneGap or a similar solution is sufficient.
Is this a fundamental problem or is this a case of JS being so bad that now that it's faster it is exposing a need to focus on the DOM?
We already hit that wall a long time ago. DOM is the bottleneck in any non-trivial app (unless your app mines bitcoins or something).
I started work on a canvas-powered alternative before giving up - but I'm glad to see the React Canvas has gone with it. When I have some free time I'll be playing around with it to see if it lives up to the hype.
1. Your mobile web framework is slow, not the browser DOM. Ditch your bloated frameworks - writing JavaScript without external libraries is not rocket science.
2. There are deliberate pauses in the DOM. The onclick event is very slow and unresponsive. I get very fast UIs by replacing it with ontouchstart
3. You are using too many animations. Smooth animations can work in mobile web, to a degree. But honestly, if the big reason nobody wants to do mobile web is because it doesn't support copious animations, I see that as a positive. I'd rather have a UI that just does what it should without having to wait through all the fanciness.
Well, you would rather have it, just like some would rather have a Lynx-like interface. This doesn't address the point, which is users go to native because web just can't bring native-like experience.
Well, except native apps let you have those animations without waiting, is the thing.
a) has decent browser compatibility b) is not a rat's nest of shims and polyfills c) could be maintained by more than one person
I don't understand the logic that goes from "Modern browsers with fast JS engines make fancy web apps practical" to "let's make sure our fancy web apps run in old browsers with slow JS engines."
Are we saying in order to go fast, we should eschew the progress we've made in compatibility to accomplish it?
If you are committed to doing everything in JS, then you have two choices:
1. Deliver a degraded experience to modern browsers and a terrible experience to older browsers.
2. Deliver a good experience to modern browsers and no experience at all to older browsers.
Depending on your business model, #1 may be the best choice. But if you're trying to compete with native apps then #2 is the only thing that makes sense.
I know it is possible because I have done it. Sadly, few others have done it probably more because of the FUD surrounding mobile web than for any real reason (the best one I have heard is that mobile web can't handle animations well.) The truth is mobile browsers are better at handling JavaScript and DOM today more than ever, and continue to improve. Maybe today mobile web isn't ready for prime time, but tomorrow will be here soon.
To be honest, the fact that the DOM is as good as it is today is very impressive to me, considering how old it is and how much the landscape has changed.
IMHO state is where its at. Separate state from function and feed the component changed state and render as fast as possible. Much depends on what you need to render too. In my case I have a ton of rules for variations, which can be exchanged for even more variations, its its own injection solution.
Therefore I'm super happy about the dumb as nails canvas, it just does its thing and the state does its thing, really snappy. I don't need a scenegraph either, just a hit detection system, but hey, thats custom and thats fine.