Statements about the Mobile Web(jlongster.com)
jlongster.com
Statements about the Mobile Web
http://jlongster.com/Radical-Statements-about-the-Mobile-Web
180 コメント
Yes... just seen that recently with the mobile site of scribd. If anyone of the scribd team is reading this: Why on earth do you think you can force us to install your native app by blocking reading the full content someone else gave you in order that _I_ can read it?
Are native apps more popular than the web? Probably not. Is it harder to make a web app to the same level of quality as a native app? Absolutely.
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.
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.
It's definitely hard to do animations and touch interactions as good as native apps. Making responsive websites is really really easy for an experienced designer and/or html coder.
> Making responsive websites is really really easy for an experienced designer and/or html coder.
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".
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".
You can't retro fit responsiveness. Or at least you can, but it's such a bad idea that no one should try it. It's the quickest route to legacy CSS that no one will every want to touch again.
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.
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.
I agree with you, but you could say that about any site migration though, right? It's never easy to pull an old site forward to a new design/structure, responsive or not. That's been a huge pain point for as long as large sites have existed.
I disagree simply because almost major website has significant usability issues with mobile. Often relating to touch input. I'm genuinely surprised anytime an image gallery is swipeable and it even half works.
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.
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.
> Well doing it right takes too much effort.
Who told you that? It doesn't take any more effort than a normal desktop site given the right tools.
Who told you that? It doesn't take any more effort than a normal desktop site given the right tools.
No person said it with words. Websites said it with their behavior.
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.
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.
That's not a good enough indicator - it is removed from important context that may be relevant.
img srcset + a polyfill?
> No person said it with words. Websites said it with their behavior.
No doubt, the majority of mobile websites need their asses kicked.
No doubt, the majority of mobile websites need their asses kicked.
This. And don't forget fastclick.
https://github.com/ftlabs/fastclick
https://github.com/ftlabs/fastclick
Off-topic but fastclick is mostly uncessary at this point: http://developer.telerik.com/featured/300-ms-click-delay-ios...
"Mostly" - but iOS 8 makes it mandatory, not?
"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!
"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!
Note that this behavior is already default in mobile web frameworks such as jQuery Mobile.
Right. But I guess I can't include jQuery Mobile alongside jQuery on a fully responsive app (no specific mobile version at this point of time), can I?
Why would you not be able to use jQuery Mobile alongside jQuery in a fully responsive app?
Absolutely. I think the disconnect is when some people compare native vs. web, they mean a web app that closely mimics a native app. That's absolutely hard to do, and often not worth the effort. But building a responsive website that simply functions well even if it doesn't try to feel native on every platform is not a major undertaking.
[deleted]
> That's absolutely hard to do, and often not worth the effort.
I'm not sure I agree. The JS libs are out there, you just need to find them.
I'm not sure I agree. The JS libs are out there, you just need to find them.
My GitHub search skills aren't the best, but here are some of the nicer ones I've found:
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?
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?
To underbluewaters' example of just getting a simple recipe on the screen, building a mobile-friendly page to display that kind of content is certainly not hard. For example, this is a recipe page that I personally worked on a few months ago (sorry, we didn't have a chicken tikka masala recipe...): http://tailgating.publix.com/recipes/29/caramel-hickory-chic...
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.
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.
That app's nav menu feels sticky when you're closing it.
It's definitely not perfect. Like I mentioned, it was developed on an incredibly tight budget/timeframe. I wish I'd had budget to polish several things like that throughout the site.
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)
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)
I'm sure I'm in the minorty, but I'm very anti-app. I'll never install an app where a mobile site exists. For one, I get URLs which are great. Find in page always works. I can always see when I'm on https which is a huge plus. Apps are for games mostly or for services who cripple their mobile sites.
yep. you are in the minority. This whole thread reeks of web devs hating on native mobile for no reason other than being web devs. the only website I use regularly in the browser is reddit and that is because I don't like any of the native solutions.
>> "web devs hating on native mobile for no reason other than being web devs."
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.
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'm not saying web dev isn't easier to deploy for multiple platforms. I'm saying native is much better to use from a user side.
Please educate me why. I'm not being funny, I truly don't understand.
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.
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.
1. you can do much more with interfaces and processing power in native mobile. Even simple apps like piazza or quora, I can't see being implemented nearly as nicely in the web. People think it is all about animations, but it isn't. A small example is how the entire web page has to be loaded each time you click a link on the hacker news mobile site or hit the back button or anything. A mobile app on the other hand would load all the links when you first open the app and when you hit the back button from looking at a link, you'd be met with zero latency.(not to mention persistent settings)
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. 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.
Re (1), doing full-page rendering on the server is not up to the current state of mobile apps. You can already partially update a page. Zero latency is on par as well on the mobile web, as a web app can load its code on the first render, store some data for offline (though this is a lot more work than it is on native because of the bad state of web databases implementations) and request data to the server when it doesn't fit on a phone's memory (surely, the native Quora app doesn't store its terabytes of data on every phone)
(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) 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
1) Is the result of shops putting all their dev effort into apps. Performant and high-quality mobile sites is easily achievable if you put in the effort. Native obviously has some advantages that can't be replicated in browser, but in-browser is repeatable across platforms and prevents lock-in (for both site creators and consumers)
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.
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.
Thanks. I very much appreciate your response. :)
One example - I use the ebay app on Android over the web site. It's miles better due to native integration. It remembers my login better than websites do (probably a security risk, but my phone's encrypted), it integrates photo-taking direct into the app which is handy for selling and buying e.g. buying: if you have a minor dispute with a seller you can just blast off a photo in the built-in messaging system. It sends notifications for watched items. The UI is also better than the mobile site - the click targets are nice and big and the lists scroll quickly - but that could possibly be improved in the site. The native integration is mostly what makes it nice.
same here. every time a website wants me to install an app that would not benefit significantly from being native, i think "great, what permissions is this shit gonna need?". invariably it's a slew of ones i dont ever want to give it.
For most purposes, I totally agree! I think what's really needed are better standards for exposing phone functionality to webpages in a sane and secure way (this already exists for location, for example), and perhaps more seamless interfaces to the web from mobile OSs (navigating to websites, login management, etc.). I don't really buy the mobile native > mobile web > desktop narrative on a universal level. It's certainly true for some experiences but for others the opposite holds.
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.
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.
Did you ever think that maybe these companies have data that disagrees with you?
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.
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.
From the Quartz article that Slate piece gets almost all its info in:
> 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.
> 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.
Virtually every smartphone comes with numerous pre-loaded apps.
Nothing in the quoted sentence suggests anything other than "people use the apps that come with their smartphone.
Nothing in the quoted sentence suggests anything other than "people use the apps that come with their smartphone.
If only all web apps where as simple as providing food recipes.
Very true. For some apps native is the only solution. I'd wager most apps are on that same order of complexity though.
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.
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.
My personal viewpoint is that I hate downloading extra apps on my phone, having to mentally manage what permissions I want apps to have, and move into a sandboxed place - it helps decrease the amount of crapware I have on my phone, and having to manage the inevitable rogue app (or few) that destroys performance and battery life, especially if they nag me to update via the App Store (iOS) or Google Play (Android). Phones are not powerful or have good enough battery life for me to want to risk lowering my phone's life while I am out of the house. Unless it is something immensely useful to me and/or performance is that big of an issue, I rather just go to a website. If performance is that bad on a website, I'll open up the link in the browser and just use that my mobile Chrome and desktop Chrome are linked to the same account & open the tab there.
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.
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.
YES!! And on top of that, I don't want an app for every damn site that I visit. I hate that! I go to a website and the first thing that I see is "DOWNLOAD OUR MOBILE APP!" usually gets me mad and, if I can choose, I go elsewhere!
Hey, let's compare comparable things. I.e. native apps to web apps, not native apps to web sites, ok?
Its much harder to create a decent webapp than a desktop app. For example, you can easily drag and drop together a semi-decent UI using winform/Android IDE in a couple minutes. The time it take construct a decent UI for the web is at least a magnitude longer. It's simply easier to delegate the "simple" web stuff to CMSs and move the harder logic bits to a native app where you don't have to worry so much about client-server problems, rendering etc.
Editing Android UI's is one of the most painful programming experiences I've recently gone through.
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.
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.
A few mobile apps are super popular, but they are apps that load webpages inside of them.
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.
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.
Most of the time, the people who argue against the mobile web are the same people whose livelihoods depend on Java and native apps.
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
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
It's not our livelihoods, it's our sanity. CSS + HTML = ?
indeed. for the vast majority of people and cases some mix of Google/Wikipedia/Facebook/Craigslist/Amazon/Ebay/Tumblr/WordPress/Reddit/Yahoo/3tc is going to scratch their itch just fine. (to name just a few "big hammer" tools/platforms)
[deleted]
Here's my guess for the future of the canvas web. JS will render to canvas. Later it will be discovered that the code becomes unmaintainable and multi tiered architectures will go in the browser/js with "BabyHTML" used as a template view language for the canvas to have a more standardized rendering - finally who wants to render pixels or vector graphics?. Then a BabyJS will be introduced inside BabyHTML to manipulate an object model called BabyDOM for the canvas to make more maintainable code and optional animation. BabyJS will be so fast that everything that can be written in BabyJS will be written in BabyJS. Then BabyHTML and BabyDOM will be claimed slow with frameworks based on BabyJS rendering directly to BabyCanvas which will be inside canvas which will be inside browser webview.
And all this repeats ad infinitum.
And all this repeats ad infinitum.
Everything old is new again. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
Exactly. Which aims at organizing better and teaching better. I loved the fact that early display engines were memory deprived to the point where most of the logic was lazy and streamed. Framebuffers allowed progress but also regress. History rotations.
[deleted]
That's funny because it's true.
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.
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.
woah(1)
I hope 2015 is the year JS devs really start pushing for real async/threaded support in the browser. I was working on the reapp HN reader app[0] for the last few days attempting to find out why Safari would choke for up to 20 seconds on displaying ~500 DOM nodes, and this article just sparked an idea which turned out to be true: flex-box was causing it.
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.
[0] http://hn.reapp.io
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.
[0] http://hn.reapp.io
Yup.
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.
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.
Interesting! Can you share more about it?
I've done the very basic ground work: https://github.com/davedx/lustro
Why am I not surprised to hear that OpenGL "just works" when for years I've been wondering why the clowns at W3C keep pushing for crappy substitutes?
You perhaps won't be surprised that using layers/absolute positions ends up being faster with Canvas rendering too. Frame by frame is not so much layout calc and mostly painting and composition.
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 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.
The addition of "async/await" to ES7 will make things like async DOM APIs practical to use. Until then, you'll be in callback hell forever.
No, generators + Promises is pretty much exactly the same thing as async/await, and that exists today.
To me, this "60fps or bust" notion that seems to have come up recently is complete and utter nonsense. It's masturbatory technofetishism.
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.
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.
And beyond the performance issues, app design on the web is a massive pain.
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?
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?
Just use flexbox. I've recently started doing iOS dev, and I really miss the simple, declarative, consistent web layout tools. In iOS, there's a broken drag and drop editor that can do about 80% of what you need. You then need to go in and call a bunch of arbitrary methods that do various things to different UI modules, with no consistency between modules. Everything is very ad-hoc and one-off and you don't have much choice in what to use. I will say that all the animations are pretty smooth once you call the right combination of weird arbitrary methods to do what you need.
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.
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.
I should have been more clear with the centering issue: I'm looking at something like GSS [0] as a model of what would be incredibly useful.
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.
0: http://gridstylesheets.org/
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.
0: http://gridstylesheets.org/
Yes I definitely agree on GSS. Can't wait to try it!!
CSS grids (http://caniuse.com/#feat=css-grid) are on the rise too I think.
Do you really do ANY iOS development? Because you talk shit.
Cocoa Touch is very consistent and I don't understand how can you call web tech mess superior to Auto Layout.
Flexbox: "The specification describes a CSS box model optimized for user interface design. In the flex layout model, the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions."
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.
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.
As someone who has implemented tables in a browser engine, the idea that flexbox layout just duplicates table layout is completely untrue. Tables are extremely complex, don't have a complete specification, and differ between browsers.
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)"
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)"
Are you really using all of CSS3? Centering and vertical alignment are trivial with flexbox.
http://philipwalton.github.io/solved-by-flexbox/
http://philipwalton.github.io/solved-by-flexbox/
This is dead right.
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.
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.
My guess is we'll come up with a sort of standard API using JSON or such that we will make available the information and ultimately mimic what HTML does now.
Let's use an xml-like (but not really xml) syntax instead. And we'll make it so the browser can view this format natively (with no javascript).
This actually made me giggle.
What a ridiculously backward situation we find ourselves in.
Maybe Google could write a performant DOM in Chrome before it is too late?
See Project Ganesh, demoed at the Chrome summit late last year and apparently in Chrome 41:
http://www.androidpolice.com/2014/11/19/project-ganesh-demoe...
http://www.androidpolice.com/2014/11/19/project-ganesh-demoe...
So, there is a cheap way to communicate between the DOM thread and web worker threads. It's called Transferable Objects. The technique involves postMessage()'ing a Typed Array's ArrayBuffer as your message payload. Rather than making a copy of the bytes in your sending thread's Typed Array, the byte buffer is "detached" from the sender's ArrayBuffer and "attached" to a new ArrayBuffer on the receiver thread. This allows you to do huge bulk operations on a worker thread, generating megabytes of data for the DOM thread and not taking a penalty of allocating memory, copying the data, and garbage collecting a big allocation on the sender thread.
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
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
The problem with Transferable Objects is that they only work for raw buffers. This is great for math intensive tasks such as image processing, but not that great for UI related tasks.
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 :(
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 :(
Nice to see the random Servo reference drop, it's cool to see it gain recognition outside of Rust circles. They're doing so much cool stuff.
I used to think Servo would just make the web a little faster, and never understood the true impact it might have until this comment: https://news.ycombinator.com/item?id=9011215 and pcwalton's response in that thread.
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.
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.
Another neat, releated, thing we can do in Servo is to run all CSS animations off the main thread, even ones that require reflows. I actually think that may be one of the biggest, if not the biggest, wins of Servo's architecture…
While that sounds really interesting, CSS animations are somewhat limited and its hard to do gesture or physics-based animations with them. We really need good, fast JS-based animations. Also, whatever handles touch input needs to apply the animation in the same thread.
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!
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!
Yes, it's true, it's already had a positive impact in this regard. I can't remember the exact CSS tweak that happened, but it's already done that one time.
I wish it wasn't true - but if there is a native app available for a website/service i wish to use - I choose native app almost all the time. Each of these services have a 100% work website & maybe a mobile-web:
- Ebay, Amazon, Mint, SigFig, Homejoy, MerillEdge, BofA BillPay, PizzaHut, Dominos... Somehow using their native app feels solid, real and not flakey. I don't have a feeling that I will loose my shopping cart or be logged out due to an error/network connection etc.
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?"
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?"
I think this also speaks to the effort these companies have put into their mobile web apps. For a while I used the web FB app because their iPhone one was fubar.
No, it just speaks how far behind (and the wrong origin) of the mobile web apps tech is compared to native SDKs.
You're right, that is the only possibility ¬_¬
The 60 fps thing is super weird to me. Do people really care if their website/mobile app is 60 fps? Who are these people?
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).
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).
Yes. Anything less than this becomes perceptible and starts to make the UX feel janky or sluggish. That is a huge turn-off for a lot of users, even if they can't pin down the exact cause being low framerate.
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.
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.
No. The amount of fames you need depends on the distance an object moves per frame.
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.
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.
Typically in a mobile app I'm flick scrolling at speed through lists. So the maximum distance travelled per frame is pretty high.
Same here. I was trying to point out that frames per second alone isn't a useful metric for "animation quality." Ideally, you'd want to compare the frames per second to how many pixel something moves per second (or something similar).
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.
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.
>The only place I could possibly imagine that mattering is for fast-twitch video games, or theoretically videos
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.
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.
When you're manipulating things with a mouse and keyboard, maybe not. When you're directly scrolling/dragging/pressing things with your fingers on a touch screen, jank and latency and frame rate make a huge difference in how you perceive the device's response to your actions.
If you could run at a perfectly consistent 24 fps, that would probably often be okay. But the typical failure mode is not running at a perfectly consistent lower frame rate; instead, it's variable length pauses with the tail of them being painfully long.
Valid question, not sure why you are getting down-voted.
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.
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.
Anything that maximises engagement increases impact/growth/revenue. When apps are joy-inducing people engage with them more. Jank works against joy.
60fps is more of a label than a measurement. Not 60fps, but "60fps", which translates to "as fast as native app transitions".
I'm pretty skeptical of React Native, for the same reasons you're nervous about the web. The great thing about Native development is you can drop down pretty low and optimize. During native development you do it alot. The native widgets don't suck, but performance can be awful as soon as you want to draw anything remotely special. So you drop down and start writing custom layout and drawing routines. I don't see React being good at that (maybe I'm wrong though, I haven't dug into it).
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.
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.
Layout and performance of the mobile web is a red herring in the argument of why mobile web is losing. It's not just this. There are so many other factors that I rarely see mentioned. Encrypted / protected caches, local databases, far more persistent logins and UUIDS, sensor integration without the annoying Browser requests x feature modals, launching from the home screen, consistency of experiences because of standard human-interface guidelines, background sync and notifications, integrated payment systems, and on and on.
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.
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.
local databases:
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.
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.
Can't upvote this enough. If there's anyone here on the W3C, consider this an upvote for bringing back WebSQL.
IndexedDB reminds me a lot of the Drag and Drop stuff the W3C settled on: several different kinds of awful.
IndexedDB reminds me a lot of the Drag and Drop stuff the W3C settled on: several different kinds of awful.
Agreed, IndexedDB delayed the mobile web for 4-5 years.
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.
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.
> launching from the home screen
https://github.com/cubiq/add-to-homescreen
https://github.com/cubiq/add-to-homescreen
Question: why didn't any of these issues prevent the web from taking over the desktop during the years between 1995-2005? Native has always been faster and more feature rich, on every platform and at every point in time.
Really? If you use Windows, you should be familiar with Windows Explorer. Since Win95 with Internet Explorer 4 desktop refresh (shipped also with Win98) you have a trident (IE) web engine in Explorer. The side bar with the metadata and info is DHTML in Win95(IE4), 98, ME, 2000. And a fork of trident code is used in XP and newer. Also WinXP "Software" application to uninstall programs is basically DHTML based. The newer control panel pages, the newer dialogs, etc. The EU demanded that Microsoft has to document the new UI-engine, used in IE "addons" dialog, Vista/7/8/10 Explorer bars & shell dialogs and Office 2007+, so that there no completive advantage. One has yet to find that in MSDN.
Corporate controlled most desktops. The web allowed you to access and run stuff even when IT told you not to. Installing a program simply did not happen without an act of God.
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.
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.
My guess:
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.
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.
I think its because the bar for native apps wasn't that high back then. Also the interactions required for desktop apps are much simpler than mobile apps, where gestures are key part of interactions. Gesture-based animations is actually part of using the app, instead of on desktop where they just make things look pretty.
Most desktops are far overpowered for the (relatively) trivial computing tasks they are used for. As a result the relatively poorer performance of the webapps most people use desktops for is masked to a large degree, where it's even relevant.
Besides accessibility, if you replace everything with JS and Canvas, you lose transparency. Content then becomes opaque, siloed behind services, and requires running code to discover.
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.
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.
For performance, I agree with many here, it's not the number one priority. The critical parts missing are:
(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?
(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 realize the web has a huge headstart on anything else, but what prevents someone (or us, as a community) form creating application containers that are not web browsers. Why not something like a "Python Box" where you can download and run applications written by developers in Python, and where the UI is rendered asynchronously in just the ways people say they want it (at least in this thread).
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.
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.
There will be no support for any alternative here,it's over. Vendors will never agree on what would be the right solution.
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.
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.
Please don't try to handwave away security like that. It's much, much harder than it sounds and there still aren't great solutions to safe sandboxing.
That said, what you're describing is native applications.
That said, what you're describing is native applications.
There's nothing stopping you, besides adoption. Typically when you launch a new application platform, you need to bring the users on board first. It's not enough to provide a good developer experience: you need to provide a way for those developers to support their livelihood, which means that there need to be enough users that some fraction of them will pay money for software (or be worth money to advertisers as eyeballs).
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.
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.
It's called a native application...
In many ways this is / was flash or Java Applets.
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.
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.
I know, why not make it easier to use this container (just until everyone transitions) by embedding it into HTML with, say, a plugin?
Oh, right, thats Java, Flash, Silverlight, Unity Player, etc etc.
Oh, right, thats Java, Flash, Silverlight, Unity Player, etc etc.
The only reason that matters:
Mobile. Your new format has to be accepted by Apple and Google at minimum. So good luck with that.
Mobile. Your new format has to be accepted by Apple and Google at minimum. So good luck with that.
The points raised are good, but I think web vs. native is a false dichotomy to be honest. It is quite possible for both to co-exist. The problem I see here is that, by losing the shackles of backwards compatibility, native vendors are able to move much more quickly and that upsets developers in much the same way kids get upset when their sibling gets a shiny new toy.
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.
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.
People keep saying "The DOM is slow", which is true, but they forgot to talk about how "Everything else is also slow". I.e. even with React and make sure every shouldComponentUpdate gets called, we're still getting slow performance. We need to start using all kind of hack to make it faster. Sometimes it's really frustrating to spend a day to make it look native while it'd take 10minutes with native android. I've been trying for years to develop cordova apps to avoid duplicate codebases, but I feel like it's just not worth it. It's supposed to save money and time, but in the end it just take more resources to get a shittier experience. So, definitely looking forward for background task and faster DOM manipulation.
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.
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.
Apple provides a WebView API in iOS 8 with JIT enabled. Any one who uses the new API will see same performance as Mobile Safari.
The WKWebView is buggy/breaking enough that the Cordova team has still not integrated it: https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-...
About prediction #1 - here is micro angularjs demo showing angularjs digest cycle running in separate worker http://glebbahmutov.com/blog/run-angular-digest-cycle-in-web...
The DOM is to slow on mobile issue is what spawned http://famo.us/. They go beyond virtual DOM by creating their own layout engine that then outputs to optimized DOM (or canvas/WebGL).
React also has its own implementation of the Flex layout system. Implemented in JavaScript and C++ (for react native).
I built an app when that first came out, and it was literally insane. Not in a good way. 100 lines of code to make a 'view' (their version of a div).
There's a progression from ignore mobile => make it work on mobile => responsive design => adaptive design => mobile first. But that's not far enough. Native mobile apps are mobile only, so in order for web apps to compete head-to-head, they need to be mobile only too. That's a cultural leap the web needs to make. "The web has failed to beat mobile because it lacks 60 fps" seems premature until we finally figure that out. I'm not saying all webapps should be mobile-only, just ones that truly want to compete with native apps.
[deleted]
I am not a "web developer" at the moment but rather into signal processing and I can only agree. Why is it so hard to just draw a pixel on the screen? Or why are there so many ways of doing it?
This is absolutely not related to the subject at hand though.
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.
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.
I'm not sure why you were downvoted but it's possible that your question was too basic from the point of view of a web developer.
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.
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.
>> The web isn't close to competing with higher-end native apps.
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 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?"
[deleted]
> By now it should be clear that too many users would choose a native app over a web app.
I, for one, don't.
Why install a 500MB Facebook app when I can get the same news feed with a 1kb bookmark?
I, for one, don't.
Why install a 500MB Facebook app when I can get the same news feed with a 1kb bookmark?
The point about religion is key. We really need to go back to basics with this stuff and reevaluate what exactly we're trying to achieve here from the ground up. We simply cannot retain first-class support for 20 years of legacy cruft and make meaningful progress. So if we could start again today, what would we want from a 'browser'? How about:
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.
- 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.
> The point about religion is key. We really need to go back to basics with this stuff and reevaluate what exactly we're trying to achieve here from the ground up. We simply cannot retain first-class support for 20 years of legacy cruft and make meaningful progress.
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.
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.
> A nice language that behaves well as a transpilation target
Could you rank your preferences?
Could you rank your preferences?
Lisp
Actually, we are building web-first. We believe we'll be able to optimize enough locally by caching files in a bundle and intercepting requests PhoneGap style. We've already tried it, but here's the web (non-cached) version:
http://qbixstaging.com/Groups
Built with http://platform.qbix.com
http://qbixstaging.com/Groups
Built with http://platform.qbix.com
I think major problem is connectivity. Make your site work offline and with slow connection and you are there.
500KB of javascript and CSS code is another problem
500KB of javascript and CSS code is another problem
I think James is on target in many ways, but I just wish it wasn't such a bleak near term outlook for high end mobile web apps. I don't want to write my app differently for different devices. I know that is the reality of today, but it is an unfortunate reality.
That said, many apps don't need to push the limits and PhoneGap or a similar solution is sufficient.
That said, many apps don't need to push the limits and PhoneGap or a similar solution is sufficient.
It would be lovely if this could get solved. Making an app that works across platforms would be ideal. But every app needs to work smoothly and without jank because engagement is key. Even if you don't mind it matters to more people than anyone trying to avoid native apps likes to admit.
Yeah, if you have the resources. But so many native apps are a Web view with a couple controls slapped on and extra ads that I am wary of installing anything at this point.
Aren't the browser vendors better placed to fix these issues? Why can't they implement a virtual DOM with super cool DOM diffing? Of course they can, and of course they will.
"The DOM is slow": with all the advancement of the JS engines we'll hit a wall if the DOM does not start improving by an order of magnitude.
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?
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?
I write a lot of mobile web apps and find that the DOM is blazing fast. I wish I knew some examples of why people think that it is slow, but I have a few guesses.
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.
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.
>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, 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.
Why is native-like better? Explain.
I'd love to see some examples of non-trivial apps written in pure JavaScript which:
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
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
Why browser compatibility? Why polyfills?
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."
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."
The original commenter asserts the DOM feels slow because we use bloated frameworks rather than pure JS. Sure, you certainly can use pure JS to target a select few modern browsers, but I've yet to see a practical story on how to build apps for the rest of the web at large this way.
Are we saying in order to go fast, we should eschew the progress we've made in compatibility to accomplish it?
Are we saying in order to go fast, we should eschew the progress we've made in compatibility to accomplish it?
In some cases, yes.
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.
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.
Good point. But I doubt any of my recent cross-browser web apps you would consider non-trival. I have recently only been doing simple wireframed prototypes for UI experimentation (like this: http://chrisbroski.github.io/sketchpad-calculator/) I did write a fancy web app with graphics and animations a few years ago but it was an intranet app targeted to iPhone only.
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.
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.
So really you did not do it? You had one complex app which was not cross-platform and then several experiments, but somehow you extrapolate what is possible and what is not?
Luckily browser compat is not really an issue any more. If you have customers on ie8, the new fastness does not apply to them.
> 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, except native apps let you have those animations without waiting, is the thing.
Well, except native apps let you have those animations without waiting, is the thing.
>with all the advancement of the JS engines we'll hit a wall if the DOM does not start improving by an order of magnitude
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).
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).
Agreed! Further, things like DOM diffing help but are an optimisation and can only take us so far. The answer is in the layout engine, no?
DOM implementations have had vast improvements over the past years, vendors these days are working on nanosecond improvements to DOM operations. "The DOM is slow" usually refers to design problems that can't be optimized away, like being 99% synchronous, exposing APIs that invalidate layout at arbitrary times, etc. So yes, a fundamental problem that was exacerbated by the incredible advancement of JS engines over the last few years, causing developers to build more and more complicated web apps.
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.
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.
I often see native, iOS app being sluggish and I don't blame it on Objective-C or Swift. I blame it on the application. I don't understand how it's different when it comes to web apps.
I don't know how fundamental the problem is in terms of fixing it, but it is fundamental in making mobile webapps. I remember making an auto-complete friend selector a while ago (the kind that filters as you type) - I had the JS filtering through names in less than 10ms, but the resulting DOM updates immediately brought every keypress to around 400ms, which is visibly slow, and worse, laggy.
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.
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.
It depends entirely on what your app does – but yes, I'd paint this as a fundamental problem for any app that needs to render a large amount of content (and keep it updated).
JavaScript is slow. DOM is really slow, but JavaScript is fundamentally slow. It's slower than Java and way slower than Obj-C and always will be. Excellent writeup here: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...
Why is the obvious so radical? Probably because YCombinator loves to delete anti-js comments on here? I mean hellbanning is one thing but completely removing the comments is another.
Once you go Canvas, you never go back!
Hell yeah! Noticed opentype.js is merging in some of that new Path2D sass too. Lets just use the DOM for what its good for, the slower more form based aspects of an app. Then use canvas for what matters most and be done with it.
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.
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.
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.