The headline is a little misleading: the article isn't about not using web technologies in favour of native apps - Instagram, for example, uses HTML5 for most of it's UI (you used to be able to see the error pages) and has great UX - but rather a call to stop making 'native app like web sites'.
> Our working assumption has been that all web sites should be app-like, and therefore tooled up to the hilt.
I don't think that's true. Some people create horrible scroll jacking functionality for whatever reason - maybe they thought it was more 'native app like', maybe they just thought it was clever. But many other web developers already consider that bad perf is bad perf and aren't willing to put up with it.
This post leads me to believe the author probably assumes there will always only be a handful of native platforms. I think, if we're lucky, the ecosystem will be far more diverse.
In the future I envision, noone in their right mind would ever think native is the way to go.
It seems we have different assumptions we're basing our arguments on.
I get the impression that the huge diversity of linux distros is enabled primarily by the fact that more and more development these days is web and not native.
I'm guessing they all (the linux distros), in one way or another, add value given each project's mission statement. Or at least they believe they are. Otherwise they probably wouldn't be doing it.
And I don't think we'd have to fear the OS will become a "glorified browser shell" if it wasn't the primary "app development platform".
Right now native app development is feasible. You have pretty much 3 platforms you really need to worry about developing for in order to have access to the largest amount of market share for the least amount of effort. Imagine even one more player enters the market and gains any respectable amount of market share.
Instantly every mobile app development team's efforts need to grow or every developer on each team's responsibilities grow linearly with the total number of platforms they need to develop for. From an operational standpoint it's not sound economics to make business decisions based on approaches that don't scale well.
There isn't any great diversity in Linux distros interface-wise. You basically have a handful of distros that use X Windows and one of the four old window managers.
I appreciate that. I agree it's not obvious what, if any differences exist between alot of the lesser-known distros. However I would argue that a large enough sample from the most popular Linux Distros has something substantively unique to offer.
But we haven't even considered BSD-flavor. Perhaps if we expanded to include BSD-based operating systems. To name a few: FreeBSD, DragonFly BSD, PcBSD, NetBSD, OpenBSD.
All of the BSDs mentioned above have a very unique mission.
It's easier for me (as consumer) to choose any one of those to run my desktop / laptop knowing that I'm going to pretty much get all the same access to apps that I would if I were to run Windows or OS X.
Without any reassurance that I'm going to be able to do what I need to do on a BSD or Linux machine, I'm probably going to be stuck choosing something created and maintained by Microsoft or Apple.
None taken. It's probably not worth arguing who is right or wrong since none of us can reasonably assume we know what the future will be, but I will say that in general (1) diversity in ecosystems is good. (2) Monopolies are bad. Given only these two basic assumptions I think it's obvious that there should / will be a push for more diversity in mobile, and thus a larger number of platforms to develop for.
This can only lead to one result which is for developers to want a unifying platform on which to develop. I would argue that this exists, and is improving. It's called the web and web browsers enable this unifying platform.
> It's probably not worth arguing who is right or wrong since none of us can reasonably assume we know what the future will be, but I will say that in general (1) diversity in ecosystems is good. (2) Monopolies are bad.
Diversity is good, but too much diversity can be detrimental. A one-mobile-OS world is a terrible thing, since there's no need to push forward and improve. A two-mobile-OS world is better, as long as it's easy for users to switch to whatever is better at the current time. Once you get beyond three, you end up with a situation where it takes more and more development time to cover less and less of the market, and it becomes more likely that a single winner emerges (for example, the DOS-to-GUI transition in the 1980s-1990s).
In my crazy future I hope there will eventually be 100's of legitimate mobile OSes.
One of the reasons this would be possible is because the responsibility of app development theoretically wouldn't be aligned vertically with the company that developed the OS, or with some platform that company is responsible for developing.
There's still competition when you have multiple browsers. Companies might create a proposal for a standard and then implement it in their browser. This may or may not become a standard but usually it is pretty close. In this way we can have the benefits of diversity without the negatives like having to have different skill sets for each platform and then of course there is Apple's walled garden.
Unless you're making something that needs really good performance (3D gaming for example) building a hybrid app wins every time. Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app, with about 1/2 of the development time because it's all built with web technology. 90% is easily good enough for most applications. Cordova wraps a uiWebView in some boilerplate to make a web app effectively native to give you the 'icon on the homescreen' advantages (selling the app, in-app purchases, access to most phone APIs) with all the benefits of building for the web (easy development, lots of developers, etc).
I have, and I agree with what he said. One thing which isn't that great, are the plugins. I feel like there could be easier ways to access / write plugins. But overall, everything said was pretty spot on.
If cost of developing app is halved, many more apps will be built. The choice is often not between "expensive native app" and "cheap hybrid app", it's between "why is it so expensive? but I can afford this (hybrid app)" and "no way that's too expensive (native app)".
In theory, this might be true. In practice, I find that it is just an excuse to cut corners and ignore the problems.
I recently had to help somebody with their public library and a particularly magazine publisher for digital issues. They require a web app to read the issues. They were trying to use their Mac, but the site refused to load. The public library staff had no clue why it didn't work ("well, it works for us", and their attempts to contact the publisher was your stereotypical tech support horror story.) Long story short, their website doesn't work on all browsers. They implicitly know that it doesn't work in Safari because they apparently wrote a native app just for iOS. However, they have no native app for Mac and never bothered to fix their website.
But is it better to have more apps, if most of those apps work like shit? Wouldn't it be better to have fewer apps, (although I reject the premise that it would happen) but higher quality apps?
If you need to get to market, then it could well be a win for both. If you then have significant traction and resources and still think 90% is good enough, well then, that's your risk to take as a business. Personally I feel that 90% is only good enough to get you started and there is a tipping point where user experience necessitates quality over business optimisations (shortcuts).
I don't think the tools we use impact the user experience that much, certainly not as much as the designs we use or the UX choices we make. If a hybrid app has a bad user experience it'd probably still be a bad experience if it'd have been built as a native app instead.
The article calls out scrollbar hijacking. That is a very example of the tools screwing up the user experience.
You generally don't have those problems in native. Apple in particular designs their APIs to steer you in the right direction and make it painful for you to do something that goes against their UX guidelines.
Developing for native does not always take twice as long. I would write a desktop C++ app faster than attempting to write a web app and wrap it in desktop runtime capability.
If you're not used to writing desktops apps, yes it will take longer.
I recently needed to build an internal GUI app - after seeing how much time it will take me to get a HTML client/server set up I looked around for a GUI framework in Python and I was thrilled when I found : https://python-gtk-3-tutorial.readthedocs.org/en/latest/
With Glade + Python 3 I was chucking out GUI code faster than the Visual Studio + Win Forms because there was no compile step. No over engineered MVVM ala C#/WPF for a simple app - load a glade layout file, hook up callbacks - bam everything works together. The MVC is already there because the content pipeline (model) is already separated and views are defined in glade files. I had a prototype functional by the end of the day - it would take me that much just to choose which tools to use if I went Javascript client/Python server.
Seriously - couldn't believe how fast you could get stuff done with it - everything works as expected, you get all the controls you need - no need to learn random stuff like that qtscript, no build process (this is actually huge !), insanely fast iteration (faster than web-dev). I always thought of GTK like some obscure C gui lib but the Python wrapper makes it very usable.
My only complaint so far is that Glade seems to be getting progressively slower as you remove/add stuff so you need to restart it from time to time (eg. once per hour) but it starts instantly so it's not really an issue.
Note : I haven't yet tried to get it running on Windows or OSX since we all use Linux internally.
Anyone that has ever used RAD tooling for GUI applications can easily see how the HTML/CSS/JavaScript combo tooling is still miles behind from a 90's desktop developer experience.
I'm using React Native as a web developer who wants to create a native app. Native performance with the familiarity and simplicity of web devlopment. I don't know why anyone would build a Cordova app anymore.
About 4 months away now I think. But you could conceivably use something like Reapp until React Native supports Android. That's what I'll likely end up doing. Not ideal but React Native has already saved me so much time I'm not worried about the Android problem really.
Thanks for mentioning Reapp, I hadn't heard about it. I'm facing the same problem as you as I'm starting to build an app for Android and iOS and I can't really see myself building it the 'old way' after having tried React Native. Have you tried Reapp?
That's kind of old world thinking, it's been bugging me. In traditional programming and processor architectures that statement would be true. But if it were true today then Google wouldn't have built the Dalvik and then ART layer into the OS. They'd be compiling them on the developers PC and you'd end up with a fully static App.
The VM approach allows the VM to synchronise application wake-ups which can increase battery life.
Google chrome on Android is acting much like a VM to developers and I'm willing to bet the Android Chrome team are spending a much time as the Java runtime team are on optimising.
> Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app
People always go on about Cordova etc, but I've never used one of these that wasn't a clunky, slow non-native looking mess. Do you have any examples of Cordova apps which aren't noticeably more crap than, say, an average-quality iOS app?
Installing this on Android, it's pretty obvious this isn't native:
* the very first animation (a slide transition to the left) was janky
* The app was unable to get my GPS location (it's being shared properly, and I have intermittent GPS signal, but if it was using the native fused location provider this would work perfectly)
* Buttons have no touch feedback.
* It's not the platform standard navigation drawer
* It's not the platform standard action bar
* The touch drag on the navigation drawer lags behind the finger position more than it should
* Non-native map has really bad pinch-zoom-pan gestures
As an Android developer I'm sure I'm consciously noticing things that lots of other users might not, but if this is the best Cordova still has to offer... :/
> As an Android developer I'm sure I'm consciously noticing things that lots of other users might not
Having talked to a lot of users, they do notice. They may not be able to articulate it, but all the things you mentioned give them the feeling that the app is not as good as some other app.
Great hybrid app but I can definitely tell it is not native. The animations stutter quite a bit on my nexus 6. I'd imagine it would be much worse on low to mid level android devices. Then there is that slight delay on all tap actions. Perhaps your average user wouldn't pick up on these things, but as a developer I definitely can spot a html app immediately and find them unpleasant to use in most cases.
> Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app
Companies like Famo.us have proven this is incorrect mathematically over 2 years ago. That is precisely why Famo.us built its own rendering engine that subverts the DOM and renderings content similar to a gaming engine (Unreal Engine). The DOM can't render as many surfaces as a native app in one view smoothly.
You can still make a very performant cross platform DOM based application (http://hn.premii.com is an excellent example), but in order to get that performance you need to limit your interface to very basic UI elements.
Define your criteria for "winning". If I'm truly building a user experience, then I don't know a single hybrid app that has "won" (my definition of winning here is an app I use daily, and I don't know of a single app I use daily that is hybrid)
> 90% is easily good enough for most applications
The problem is most applications (80%) don't really even need a native app to begin with.
"Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app, with about 1/2 of the development time because it's all built with web technology."
This is true only if you're working with people without experience. Someone who is experienced with the mobile toolkits is going to be able to develop the app just as fast, with more functionality.
> Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable.
But what if the browser is the OS?
I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be stuffing them full of JavaScript. I think the Google IO 2015 web app [1] is a good example of what can be done on the web right now with minimal overhead.
Then the user has chosen, for whatever good reasons, to run a pretty limited OS, and in doing so has chosen not to be able to take advantage of all the things that having a much less limited OS would offer.
This is only true right now and only if browsers were not working to make more low level stuff available. There is very little limiting about being in a browser these days. Drivers, perhaps. Kernel stuff, perhaps.
But as far as a game is concerned? Or an email application? Or anything in the context of this discussion? Not too much limiting them.
It will always be true forever, or at least for as long as a web browser is a program run within an actual operating system.
It's not a competition. Pick the right tools for the job. If the job is getting your eMail or playing a relatively simple game, and a web browser abstracting as an OS can support your needs, knock yourself out.
If the job is something a bit bigger than that, use a more powerful OS.
Take a look at what's currently available in desktop web browsers: maps, document and spreadsheet editing, highly interactive charts, video conferencing etc. (things previously thought impossible/impractical for a web browser to do) If you need huge amounts of data to even run your application, the argument to go native makes some sense, but the browser (even on mobile) isn't as inherently limited as the article describes.
Lets not try to limit the web, but try to make it better and then let the users decide which they would prefer to use.
I'm not limiting the web. You're not limiting the web. The web has limits. Actual, hard physical limitations (along with confidentiality and privacy limits); limits that something running entirely locally, directly with your actual operating system simply suffers, and will always suffer, to a much, much, much lower degree. Your opinion (and my opinion) is meaningless when confronted with actual, physical reality.
Besides having to transfer data to run the application in the browser, what limitations are inherit in a web-based application? (I acknowledged the data transfer limitation in my previous comment).
Browsers (especially mobile browsers) are unnecessarily limiting what can be done on the web. Adding additional permissions could enable browsers access to more system resources and components, especially on mobile.
Could you provide some examples of applications that don't require a lot of data that couldn't be run in a web-based environment, because of physical (and not current browser or software) limitations?
Doesn't even necessarily have to transfer data with web workers, service workers, caching, etc.
Google IO 2015, I believe, stores it's data so that when you load it up it loads from a cache that it's service worker will reload once you have it open. Allowing it to work offline and removing the cost of transfer at the beginning.
This is clearly just my laptop (or maybe firefox) but that google site took about 30 seconds to load up. Every time I click on the tab that has it open - my computer fan whirs up to near full speed and it locks up firefox's graphic rendering until it finishes the page. Once loaded there is an unusable level of lag on the browser and CPU usage is levelling at 55 odd percent.
a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app.
b) "Emulating native leads to bad UX": this section is absolutely right. Stop hijacking scrolling and building in cruft.
c) "Hassle-free web": absolutely right. You don't need an app for that. Just give us the information and let us have the basic interaction we want. No, you shouldn't present your menu as a PDF either.
d) News: this is where I disagree. Users don't go to news sites so much; they go to aggregators which link them to individual articles (reddit, facebook). It's hard to deep-link into an app. This is a case of the app existing to further the commercial needs of the content provider (increase lockin, ads and tracking) in direct opposition to the wants of the user.
People keep trying to make the "magazine app" happen, and I've seen very little evidence of it working.
Disclosure: I work on the website of a blue-chip dead-tree newspaper. But I agree. As someone else said in another comment, the basic requirements of a news site is, let's be honest, Web 0.5 stuff. Look, some text about stuff that happened! A picture of stuff happening! These are, shall we say, solved problems.
If there's anything where you wouldn't expect significant value-add from the native or pseudo-native experience, it would be news. Certainly as a consumer I have no news apps installed - I go to the website.
>> If there's anything where you wouldn't expect significant
>> value-add from the native or pseudo-native experience, it would
>> be news
I strongly disagree. I see "the news" is a perfect counter example because technology has changed what news is. Its not daily static content anymore, its now real-time, multi-media, interactive and interconnected.
The types of media on a news page include: recorded video, live feeds, audio, pictures and embedded digital content from other services like twitter created by both journalists and amateur eye-witnesses. These are not just value-less decoration like cute animations on landing pages but real content from the event being reported.
When news is data like election results, tax changes etc. interactive data visualiations are essential for digesting it. Interactivity lets us understand the impact of the news to us personally instead of single homogeneous national agenda. We expect all this and for it to be real-time and provide ways for us to be notified about changes, to share it and discuss it with friends and strangers.
I'm arguing against the parent that claims Web 0.5 (vanilla hyperlinked documents) is enough for the news. This is only sufficient to duplicate a newspaper and present prose\pictures of what happened yesterday. I claim that technology has dramatically changed the fabric of news itself which now requires the modern Web with its document/app blurring to include dynamic behaviour, interactivity and multi-media.
/s/ steam for news://home or news://business/26-05-2015-oil-prices
The content could (and definitely should) still be html, obviously not everybody you link to is going to want to install the news app and it should fall back to opening in a browser, but if you want to wrap a fancy interface around what should just be text there's your solution.
Which newspaper's app would the newspaper:// URL link to? It's certainly possible to do this, but it's often done badly. And if the app doesn't display its URLs, and they're not made available nicely in its "share" functionality, then the user isn't going to be able to work out how to refer to the article.
Also from that link: "Security considerations: Unknown, use with care." Great!
(news:// is already taken by Usenet NNTP to refer to articles by ID)
They didn't say it was impossible, they said it was hard. And it is. Deep linking into an app requires a link handling implementation and knowledge of the operating system's procedures for registering that you can handle certain protocols. The web gives it to you for free.
I think it is possible that a news app done well could provide a slightly better mobile UX than a browser (better navigation and pagination), I would want the content to be mirrored on the web, and it should be easy to get at and share the web links.
So, the OP is adverse to the JavaScript single page app fad, because in his opinion it is overly complicated to try to get a web app to behave like a native app, and instead should embrace its "weby-ness"? Is he just thinking about developers who have to use the tools he does not like, or the consumer experience side of it too?
The web works best as a document platform. All the UI tricks that web developers work on all end up managing something related to just browsing/reading a document. It's amazing that modern browsers/HTML just don't have this basic user experience down.
Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-form articles, for example, when the basic purpose of the web is designed for reading documents? Why weren't multi-page transitions built in by default?
The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles? Why are there a million JQuery photo gallery plugins?
In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text? (proper fonts & spacings, limiting column widths to 8-15 words max, etc..)
The reader-mode that web browsers are building in, that should be the default standard UX for HTML, and CSS should build upon that. But instead, it's a non-standard option.
Likely this hasn't been done because it would require many very difficult, "subjective" decisions to be made i.e. which font, line-spacing, photo-viewer UI, etc.? Better to make no decision at all than to spawn a few dozen endless committee debates.
By contrast, corporations can more easily make these sort of decisions – by fiat – which is why native app frameworks are more "opinionated" / make more design decisions for you out of the box.
This topic is as much the story of two historical forms: the operating system GUI and the World Wide Web hypertext project as it is about two organizational forms: hierarchical corporations and decentralized design-by-committee non-profits / multiple competing corporations.
Don't forget that you can specify related pages as <link rel="next/prev" /> and let the browser handle pagination.
I recall when I used Opera, you could scroll down, hit space, and it would go to the next page as long as the website provided that information (forum softwares often do.)
I also mentioned the column width because this site has the obvious problem of long horizontal text, which is a no-no. People naturally read in chunks of 10-15 words scanning vertically. Long, horizontal text is easy to lose track of location.
How much have browsers invested in their pagination solution, though? If I specify that tag on my pages, does that mean users who visit my site will have an awesome experience when it comes to pagination?
Strong disagree on both of these points. I view most webpages (including that one) at around 66% zoom these days, because the text is so goddamn big. And anyone advocating for less contrast needs a shovel to the head.
> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles
Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.
> photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?
Because there's no one size fits all solution. Look into magazines, newspapers, etc. After a few centuries there is still no standard. Grouped, with captions, position, size, etc.
> why do we need to write CSS to create a basic readable document in the first place
You don't. Browsers can display semantic markup just fine without any CSS. The fact that you even ask this question is why you write CSS, because different people in different times expect different styling, and they don't think the default style is pretty. I agree that the default styles could be improved though after 20 years, but that could lead to breakage of current CSS styles, and why risk that if everybody uses CSS anyway?
And the fact that I wrote this comment is just another reason why you have to write CSS: because not everybody agrees on how the web should look.
> Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.
Actually yes this is the use-case I was referring to.
HTML has semantics to define sections, headers, etc.. but it doesn't manage them in any way.
If you write HTML that define sections, for example, it's no different than if you write HTML without sections.
What is your opinion of the section-structured HTML documentation itself? http://www.w3.org/TR/html/ It's all neatly sectioned with anchor links and so on.
Section and header tags were standardized last year, it's definitely too early to tell how browsers will handle them, but with the ubiquity of CSS and for the reasons I already mentioned I doubt they will ever get any styling, unless maybe for when no CSS was defined at all.
Ultimately, I don't think of the web as a page-based medium, it's document-based. Electronic documents that want to mimic pages are a relic from the past, imo. What you seem to want should probably be implemented as browser plugins.
> Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays.
What I read was that it's not for "more ad displays", although closely related. It's because news sites keep (and market themselves based on) a "pageviews" metric, so they try to get as many pageviews as possible out of each piece of content.
Have you tried to disable pagination in reading apps like iBooks or Instapaper?
Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.
Using pages to display text is fine. I regularly use space to scroll a page down when reading a long text in the browser because it is more pleasant than constantly scrolling. But fixed pages should not be part of the document markup in most cases. Reading a PDF on my phone is not a pleasure just because I can't just flow the text to fit my device.
I do most of my long-form reading on devices that don't have a space key.
I am not talking about fixed pages or clickbait websites where you have to scroll anyway and then click a "Next" button, but about having a flexible way to enable pagination of content.
That pagination is one of the reasons why for me the best way to read something like the stories in http://longreads.com/ is on Instapaper (or a similar tool).
Yes. I gave pagination in Instapaper a try, and turned it off after about an hour. I tried to turn it off in iBooks, but there doesn't seem to be any such option in the iOS version.
Not only do I disagree, I would argue its subjective. I much prefer one long article instead of paginated articles and will regularly refuse to continue past the first page on principal.
You may like pagination but I do not, and I would argue its better suited as an option, not dictated by the author.
It looks like you've brought up the most important point: the design of a page is altered based on advertising revenue.
90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light.
If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.
> If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.
I would flip that: we need to explore ways to generate revenue which don't rely on practices like trackers, structuring content to inflate page-views, etc. which don't benefit the user.
The most obvious example I'd use is ArsTechnica's approach of disabling ads for subscribers – I notice this any time I use a new browser and pages take twice as long to load because web performance just isn't a priority in the ad world.
>>> If we focused less on revenue generation we'd have a much much smoother web experience
But then rather than poor content, there would be next to no content (for the masses) because business have expenses ;)
Speaking seriously, yeah I see what you mean. Maybe reducing ads and improving speed would result in better UX, which would lead to better user retention, which would leave to more ad clicks. But that's a lot of maybes. Why risk that if people are used to ads? Ads often come when subscription is not an option.
You can explore other revenue sources (e.g. affiliate) but they are usually not widely applicable. And other than that, there's not much to do. I don't really think there exists a business model which could replace ads (when, again, subscription is not an option).
On a related note, I think depending on ad revenues is not such a sustainable practice. Its a feast or famine strategy and eventually a lot of businesses are going to realize that. Targeted marketing improves this, but the greater the noise, the more our brains learn to ignore it. Subscription or sponsorship models are a tougher sell but provide more loyalty and consistency for free content.
This is only true if you constrain the "web" to mean the Tim Berners-Lee document-centric HTML and its http hyperlinks.
The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a interconnected electricity and have done other things with it.
Do some "native" apps do nothing more than what a 100% static HTML could do? Yes, abuse of a Javascript widget framework does happen. However, the bad examples don't mean the "web" should be held back by the original visions of HTML or Hypercard. The Google maps app is not traditional HTML+CSS.
EDIT: The replies misunderstand my position. I'm not trying to redefine the traditional technical meaning of "web" and make you like it. I'm attempting to explain that "the web" has evolved and what it now means to the world out there. (E.g. see non-document usages like Dropbox, google maps, online Sudoku games, etc.)
Those were the historical and technical divisions.
Because http & https is ubiquitous and they have a defacto pass through most firewalls, the modern "web" is the "internet" as far as application interfaces are concerned.
The idea of a pure separation of concepts such that http is "documents" and some other protocol on some other port is "apps" is not going to happen. All those IT departments' security teams and Cisco admins at Fortune 1000 companies are not going to adjust their firewall rules to open new ports and protocols. The "http port 80" has become the "internet" on top of the old definition of "internet". It's not ideal but that's where we are today.
I don't see how willfully blending these two things is helpful for anyone.
In this context, it can be safe to assume that everyone knows this technical distinction (even for those of us who are not web programmers). In other contexts with less computer-technical people, I don't think being annoying and correcting every "technically incorrect" mention of "The Internet" when they mean The Web is helpful. But I think it is helpful to remind them of the distinction if you are actually talking about the subject (as opposed to just saying things like "look at your internet, I just sent you a facebook message"). Computers are magical enough as it is; it doesn't help anyone to make it even more so when they are even slightly interested in discussing some part of computing or IT.
Explaining that The Internet is the infrastructure and the Web is just one the things that uses this infrastructure seems simple enough to grasp, and isn't an oversimplification at all. People understand that the electricity grid has to exist in order for them to make toast.
I think we need another rule of thumb here: All standards will be modified by public cluelessness, and exist as uglier de facto distortions of themselves.
So, is a HTTP (Hypertext Transfer...) REST API used by a native mobile app "web" or not?
How about a native app based on a "web view" that uses HTML, CSS, JS, etc. (the whole W3C stack) and doesn't even talk to HTTP/S but uses some other port and transport mechanism?
I thought I was clear that I'm not using the traditional definition of "web" but to explain what "the web" has become.
It's about the evolution of how society sees the web and not about what its original purpose is.
Dropbox uses html and http. Drew Houston and his team are not going to submit an RFC so that the internet has a new protocol and port "dropbox://myaddressoffiles:8675". No, Dropbox the application will just use "http://". It's because they did not pursue conceptual purity of having "dropbox://" that allowed everyone inside and outside of corporate networks to use the service and share files.
That is "the web" we have today and in that scenario, the non-technical use of "web" includes the underlying internet stack to make web apps possible.
What's the alternative? Tell millions of Dropbox users that such a service is outlawed because "the web is best as a document platform?"
The "web" as in Tim Berners-Lee(TBL) "world wide web" is http+html which is "documents".
Saying TBL-web is "best as a document platform" makes perfect sense. It was defined that way therefore, use it that way. It's tautology.
Back in 1993, if we want to say "X is best though of as a network app platform" we'd have to use the word "internet" instead of "web" for "X" to be conceptually pure and technically correct (the best kind of correct.).
But now we have things like Dropbox (and thousands of other "web apps"). Dropbox runs on "http".
Dropbox "syncs". Syncing is an app. Dropbox is an app. Dropbox runs on http. Http is "the web". Apps run on the web. The web is platform for apps. That's the reality of where we are today.
Dropbox without using http_port_80 would only work in a laboratory. One big reason Dropbox is valued at $1+ billion dollars is that it uses http so everyone can use it easily. Web browsers didn't require radical changes. Corporate firewall rules didn't have to change. That's how they got quick adoption and millions of users.
My experience is it's the other way around. I am the Technology Director at a school, and when a teacher tells me "the Internet is not working," he is saying that when he clicks on the Internet Explorer or Chrome icon, he's not getting what he expects. Rather than the web becoming the Internet, to them, them Internet is only what they see through the browser. The fact that Dropbox or Facetime also uses the Internet does not occur to many people.
This is only true if you constrain the "car" to mean the Henry Ford, transport-centric engine-and-chassis.
The "car" also means the whole transportation stack: pavement, asphalt, road signaling, etc. In that case, the car is a foundation tool for anything that transports people or inanimate objects. To say the "car works best as a transportation device" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a horseless carriage and have done other things with it.
I'm not saying I like for "the web" to be interchangeable with "the internet".
Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on. The "web" has become the "internet" for both documents and applications.
It's descriptive, not prescriptive. (See my other replies to illustrate how usage of http has evolved to coexist with corporate firewalls that lock down ports.)
> Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on.
The world has not moved on. Part of the world has dug itself into a technological hole. Most of the people who work in it have never seen what's outside it, so they think the solution to all their problems is to keep digging.
Edit: crap, I sounded so snarky and aggressive. Sorry about that. It's not something personal -- I obviously got the point that you don't think everything about that is a good idea.
The point I'm trying to make is that not ever technological move is necessarily a "good" evolution. Every narrow street in technology was once thought to be a superhighway that everyone flocked to.
I remember everyone being so bloody enthusiastic about this whole Web 2.0 thing back then (and I was one of them). Then all this data crumbled as people paid less and less attention to information structure and semantics and focused on the flashy stuff. Then it turned out a lot of problems were intractable if you clung tightly to JS, CSS and the web browser.
Yet for some reason, people thought those problems happen just because we don't cling tightly enough to JS, CSS and web browsers.
Oh -- and twenty years after operating systems that aren't full of memory leaks, security problems (eh...) and performance clunks became reasonably accessible to people everywhere, people are trying to promote ditching those for web browsers. Which, I would estimate, will need another twenty years or so to stop having memory leaks, dubious security and privacy practices, and embarrassing performance clunks.
To clarify, I'm not saying "moved on" as an objective measure of superior technical progress.
The "moved on" is referencing a descriptive (not prescriptive) state of affairs with how the world now defines "the web". The existence of sliding around map tiles in maps.google.com, syncing folders in Dropbox, etc is evidence that the world does not think of "web" the way Tim Berners-Lee thought of hyperlinked documents in 1993.
Yes, but whatever that is should not be called "web", just like we call "cars"... "cars", not "carriages", though they may look like it.
"The web" is defined by a set of traits (hyperlinks etc.). When whatever we're doing stops having those traits, it's no longer the web. Continuing to call it "the web" is not some form of philosophical awareness, it's just ignorance.
But "computer" used to mean a "person who calculates" and not a "machine that calculates". All of us call modern day devices with CPUs a "computer" even though it lost the essence of "human". The usage of words evolve.
I 100% agree that ""The web" is defined by a set of traits (hyperlinks etc.)".
I'm also adding that "web" also now includes expanded perceptions by everyone else beyond "hyperlinks+http" and that enlarged perception is unavoidable. We could ask the world at large to *not" call it "web" but that's like asking us to quit calling "machine calculator" a "computer". Sometimes we invent a new word, but many times we don't.
Yes, a person uses a "web" browser to read a "document" on New York Times. But they can also use that same browser to play a Sudoku game that's not a document at all. To the layman, both actions are "surfing the web".
By the time electronic computers became widespread, very few non-electronic computers remained -- and few of them were human. The term was easy to repurpose.
But the World Wide Web is very much here and very present.
> To the layman, both actions are "surfing the web".
To the layman, a server and a computer are the same thing, and yet calling Apache a computer is incorrect.
>The term was easy to repurpose.
But the World Wide Web is very much here and very present.
And educated programmers call various text styles, "fonts" even though technically, a font is actually a specific size, and specific weight of a "typeface". The "font" is a subset of "typeface". Even though typefaces still exist, almost everyone uses the word "font."
And programmers will also call SQL (without CTE) a "programming language" even though it's not Turing Complete.
Even binary black-&-white-thinking programmers will exercise a lot of leeway with how words are used.
I want to emphasize that this all started with my response to the "web is best as a document platform."
I think most of us can substitute "web" to say "http+html is best as a document platform." That's what TBL meant.
Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as reality, what does "web" in "web app" really mean? The "http+html" has become a universal transport mechanism (with some apps even tunneling through http to do interesting things.). As the years progress, there are more examples of http becoming a "dumb and dumber" generic transport pipe for things that are not documents.
Let's say a startup company wants to create a website to crowdsource music promotions. They want the service to offer programmable access so people can write open source clients. The presentation slide / whitepaper will not use the phrase "internet api". Instead it will use "web api". If every corporate firewall and user' homes computers with Microsoft Firewall had wide open UDP ports, it's possible for the phrase "internet api" to have more currency than "web api". But that's not how history has played out.
> Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as reality, what does "web" in "web app" really mean? The "http+html" has become a universal transport mechanism (with some apps even tunneling through http to do interesting things.).
HTTP + HTML does not include "the whole Internet stack, TCP/IP, DNS routing etc.", as you mentioned above.
You're right. 1000x I agree that TBL's http specification and the html specification is not TCPIP and DNS.
However, that wasn't the level of conversation I was trying to have.
There is another viewpoint of http+html that is not the specification. That viewpoint is the usage of http/html/TheWeb.
For example, the White House is building made of stone. It is not a human. So how can newspapers say "the White House has signed the Internet Freedom Act into law." Well, we're not getting anywhere going round and round in circles insisting that stone buildings have no agency to pick up a pen and sign a document and that only a human like President Obama can do it. There are multiple meanings of "White House" and we seem to get along fine with it.
There are also multiple meanings of "web." It's possible for the industry to invent a totally separate word besides "web" for the abuse/reuse of http+html as a transport for apps but that didn't happen. If a startup in Silicon Valley has a goal to release an app that makes use of TCPIP+DNS with the best chance for wide adoption, they can entertain the idea of using a custom UDP+port scheme... or they can just piggyback on http. They didn't use http as Tim Berner-Lee's specified in 1989. It's the out-of-spec usage that's adding new color to what modern "web" means.
I'm not saying I approve of it or it's technically superior. They didn't ask TBL's permission for it to evolve that way. Is it anyone's fault?! Too late to assign blame now. It is what it is. The phenomena I described above exists no matter what label we give it. It would be awesome if another word besides "web" described it but it doesn't exist (yet).
If the "White House" can act as a synonym for "human", it's not impossible for "web" to act as synonym for "whole internet stack." (Again, the synonym mapping is using the other evolving definition of "web" instead of the official RFC specifications.)
> The "web" also means the whole internet stack, TCPIP, DNS routing, etc.
I'm pretty sure there are different protocols for email, torrent, etc. And I don't see how that is a bad thing, or why The Web has to be a frontend to everything that comes from The Internet (desktop email application for instance).
>The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a interconnected electricity and have done other things with it.
No, absolutely not. The "web" refers only to what you mentioned above. It's only a recent bastardization that we started referring to the "Internet" as the "web", because of the dominant nature of HTTP. You're right though that the Internet is important, but the GP's point stands that HTTP was really only intended as a document protocol (Hypertext, yeah?) and it has seems a somewhat strange perversion that we've bent it to doing so much more.
Someone not in the know may call the transmission in a car "an engine", or call the differential a transmission. Just because someone outside of the industry does silly things like that doesn't mean all of a sudden obfuscate the usefulness of terminology at all, as it really helps no one.
> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles
As far as I am concerned those things only exist to inflate ad views, they have negative usability impact.
I don't really see why a long document should be broken up in pages to be readable.
> The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?
There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.
> In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text?
I find plain un-styled HTML to be much more readable than the tiny light gray webfont on white background that designers usually settle for these days.
> There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.
Except when people nest the images as deep as posible and overlay other elements in front of the images so you can't simply right click the image, you have to inspect source and hunt for that image URL (or check resources tab in developer mode, or whatever).
That usually happens because someone has decided they need some special javascript "gallery" for the user.
Twitter's default user timeline is the worst example of this that I know.
> Is it the web’s purpose to emulate native by inserting yet more features?
Certainly not. In my opinion, the problem with the web is that it has become too complicated. In an effort to make the web simpler for the ordinary user, the web has actually become a more complicated place for the (advanced) developer.
HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility. For instance, a developer has no choice of programming language, but has to resort to javascript; we are stuck with the cooperative multitasking of the 80s (webworkers support only message-passing, no shared state); also, the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet). And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
I'm hoping that in the future, we can make the web more simple and elegant for the developer. We need simpler primitives, not the complicated and restrictive building blocks that we have seen thus far.
Lack of support for shared state is no disadvantage! When you write multithreaded programs in a language such as C++ or C#, you try to impose on yourself the same restriction, in the interests of making your life easier...
(I haven't used web workers, so maybe they're in fact awful to use. But from what I've read, it looks like the right decisions were made, pretty much.)
Why be so protective? Perhaps somebody invents some programming tool that makes it easy to reason about shared state. This is exactly the kind of mind-set that makes it difficult to develop for the web.
Also, shared immutable state is a useful (often perhaps even essential) property for building efficient code in a multithreaded environment, even when using the message-passing style.
> HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility.
Verifiable security? You can't statically verify a program is secure.
Flexibility? The complexity has given it greater flexibility.
> For instance, a developer has no choice of programming language, but has to resort to javascript
Just like on native platforms, where the developer has no choice of programming language, but has to resort to machine code!
Unless you use a compiler. Which you can do, and it works very well.
I thought you thought complexity was a problem? Introducing "native" other-language support would only increase it.
> also, the developer has no choice of render engine
I thought complexity was an issue?
But this is also not true. You can use your own if you really want to.
Although why you need your own rendering engine is a good question. Almost all native apps use the OS's GUI framework.
> the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet)
Who said they did? They can choose to write code that doesn't work well on other platforms. Though that's largely a UI thing, the code will run on any without changes.
> And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
What? From a code perspective, if it runs on one, it runs on the others. The API is the same. The only difference is UI: screen sizes and input methods.
> We need simpler primitives
We have those. If you want to run a 50MB C++ GUI framework in the browser, you can! It's just a terrible idea.
Native apps are by definition less portable than web based ones.
As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.
> Native apps are by definition less portable than web based ones.
I don't believe it is that clear cut. I think you are ignoring the fact that native developers have frameworks of their own. Using Boost, GTK+, or Qt gives various layers-of-thickness over the OS so the native code is portable. Some, like Qt, also cover mobile operating systems as well as desktop ones. These frameworks are not young either; so while websites had browser-specific-detection-code (thanks to IE), native apps were already running cross-platform by leveraging frameworks of their own.
>As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.
This is because you are using tools and paterns to avoid having to think about the differences. Those tools are also on native platforms, and those differences apply to the web.
I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.
This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both.
Users don't want mobile apps that are simply a website packaged up behind the "icon on the homescreen". Those apps lack the essential benefits of native: fast and seamless access, smart use of local data, integration with device services like notifications...
There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up because it first loads a browser engine, then makes a hundred HTTP requests to fill up that embedded browser with content. (And if the 3G network happens to be clogged, the app may end up showing nothing after 20 seconds.)
For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance, browser differences between devices (even Android devices with the same base OS can have very different web view browser engines), etc. With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in.
Shameless plug: my startup Neonto makes a UI design tool that creates usable iOS and Android code from visual layouts. It's a great way to remove the friction in creating real native apps:
http://neonto.com
"With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in."
To be fair, that could be said about most software projects. "80% done, now the last 80% remains."
Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games) I have tried. They are only suitable for basic stuff where the native feel isn't critical.
To be fair, that could be said about most software projects.
Yes, absolutely true. The difference here is between "known unknowns" and "unknown unknowns", to paraphrase a certain renowned military strategist...
With Cordova/PhoneGap, it's easy to get the initial impression that you're dealing with "known unknowns", just the typical web development project pitfalls -- "This is HTML, I know this stuff".
When the "unknown unknowns" hit the fan, it's often pretty late in the development cycle, and so things blow past original estimates even though they were competently planned. It's just that the plan was for web development, not the shifting art of websites-in-drag-pretending-to-be-apps-development.
I agree with that. With an abstraction layer on top of a native layer, inevitably you have to go below the surface unless you fit the intended use case perfectly. I learned this lesson with the Objective C-Python bridge. Spent needless time mapping differences between the two to the point where I had to learn Objective C anyway.
I agree, but one minor nit: when major problems crop up "pretty late in the development cycle", this typically means a waterfall development cycle.
Waterfall approaches are really only appropriate when there's nothing particularly risky. I plead with the HN audience: never let a manager choose the waterfall model by default. They often happen because they make contract negotiation easy. But that's only because they save all the trouble for later.
I tend to think it's good when running in a browser but not when it's made mobile web app capable and running full screen without native controls. Unless it's a super simple single page app.
At the other end there are things like Instagram where you basically can't do anything on the website (can't sign-up, can't upload photos). Everything requires the app.
I absolutely hate jquerymobile, you should just make your website responsive with CSS media queries then pepper in a little bit of javascript to handle things like slide out navigations.
Unless that platform has changed completely in the last year or so then they are wrong. Appcelerator (and things like it) generally make "Hello World" super easy and even the first week or two will be awesome. Then the cracks will start to show. You will add a listener on a button and the app starts crashing with a cryptic error, you start having to litter your code with `if(isAndroid)`/`if(isIOS)`, or for some reason a view will be really show to render to lag between clicking and doing something. When you get down to it you'd be better off learning native or just accepting a mobile website instead. Normally (IMHO) the only apps worth using appcelerator for are simple websites and at that point you'd be better off just doing a mobile website.
I'm excited to play with React Native but I fear it will suffer from the same issues.
And play with it. Download top 5 native HN apps, and launch those, and tell me which one takes 10 seconds on which device.
No doubt that you will have to deal with different version of webkit browsers (webview) on android. As long as you follow standards and not use latest CSS rules, you will be fine. And with Android 5.0+, its much much better.
---
Now try this page on your mobile, and tell me how bad it is. This is few hours of work (Flipboard style animation), and works on iOS/Android Chrome/WP8: http://reddit.premii.com/#/r/news
There are issues with browsers, but performance is not one of the issue.
----
It takes time on Cordova not because of HTML, but because how each platform works natively. I am not a native developer.
I don't see the point of comparing HN apps. HN is a website and doesn't do anything meaningful as an app.
Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices. It's going to take a while until you can build hybrid apps exclusively for Lollipop.
If you don't think mobile browsers have performance issues, you must use high-end devices exclusively.
Twitter is list of stories with notifications. For me its more like HN app. HN has list of stories, Twitter has 140 characters tweet. When you click on the HN story, you get list of comments or article. When you click on the tweet, you get replies and retweets and so on.
I didn't start with Android 5.x. I started my app with Android 4.x. I don't think you use low end Android device. Even native apps on Android has lot of issues related to performance.
On my Nexus 5.0/Android 5.x, Facebook scroll is not smooth when there are pictures. I only get non-important notifications from my twitter app.
I test my app in first generation of iPad 2 (My iphone 4s broke) and galaxy s3.
---
Now show me 5 meaningful 100% native apps (Non-game) that are not developed my a startup with a huge capital or big company, available on iOS and Android, and has 4.x star ratings.
Well, lets see, I use Droidlight but that's by Motorola LLC, so maybe ColorLights. ConnectBot (ssh client). Barcode Scanner (I'm not actually sure if this qualifies as 100% native -- but I think it does). Open Camera. K9 (email - there are others, with different strength/use cases). ChatSecure.
Now, these are all Android apps, and few (if any) have iOS versions. But they all have iOS equivalents -- and I don't think most of them would've been as good, as non-native apps.
Note the absence of stuff that works well as a website, like facebook or twitter. For games, I think the choice between native/html should probably be governed by the answer to:"Is it as much fun as html/webview?". This is a good yardstick for other "apps" as well.
For eg hn, there's no need for an app, but of course hn is a pretty terrible web page. There are a number of easy fixes that would make it more usable, especially on small screens, but the maintainers don't care. And that's fine -- it's not accidentally bad, it's intentionally bad.
One could make a similar site that didn't break voting, threading, screenlayout on small screens quite easily. And it should probably be a web site.
One can make a "web app" to schedule meetings (see doodle.com) -- and one could augment that with something native[1]. Or one could make native apps like the ones mentioned above.
Could one make a web-rtc proxy for ssh and allow logging in to edit firewall rules via web browser? Absolutely. I'm not sure I'd want that though. Not as long as web browser security refuses to learn from office macros: unsigned js code, all or nothing execution etc.
There is some middleground, as google docs demonstrates. Personally I prefer content creation/editing to be local, possible to do off-line (with sync) -- and I'd like competing apps to be able to easily share data (via eg: the file system).
Now, that twitter can't be bothered to make a decent web-site isn't really an argument against web-sites. It's an argument against poor web-sites.
> Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices.
Folks were saying the same exact thing about 2.x when 4.x came out. By the time 6.x comes out, everyone will be yammering on about how 5.x marketshare is still strong and "seems quite resilient in low-end devices", blissfully ignoring the point in time when 4.x - like 2.x - fades out of view as it's increasingly ignored by app developers.
Meanwhile, in the actual low-end space, you have things like FirefoxOS where there's zero difference between "web" and "native" because "native" apps are just web apps with special hooks for things like cameras and sensors, or you have things like "feature" phones where the closest thing to a standardized platform you have is Java ME.
In the real world, Firefox OS has zero marketshare at the low-end. Mozilla announced just a day or two ago that they're abandoning the low-end strategy.
Featurephones are largely gone. Microsoft bought Nokia's featurephone business, shut down further development and has been converting it to low-end Lumias as fast as they can, but Android is nibbling away most of that market.
Mozilla only announced that they're abandoning efforts to build the lowest-end stuff. IIRC, most FirefoxOS handsets are still pretty low-end, and have been doing reasonably well.
And feature phones are still dominant in places like Africa and South America, particularly due to their lower cost and power consumption (smartphones are still unable to reach the battery lives of even dumbphones from a decade ago, which is an important consideration in environments with limited/inconsistent electricity). Even in "developed" countries, feature phones are popular with the elderly and disabled, since they usually feature physical buttons that are easier to work with (better tactile feedback, easier to find with poor vision, etc.) and have simpler interfaces.
As a user of Android HN apps, premii seems to beat them in all aspects. The major aspect being them actually working properly.
It seems like apps are less maintainable. Right now pretty much all of the Android HN apps are broken in some way, or missing a core feature of the desktop experience.
Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. I've found that usually the easiest way to prototype an interface is just to build it for real - it's faster than Photoshop, even.
The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expectations are different on each platform. So your client generally has to be ground-up development by an experienced expert in the platform, you can't just take the same layout and make it run on both.
Both Android Studio and XCode will give you usable iOS and Android code from visual layouts.
Well, for some definitions of "usable" and "visual layouts"!
Our goal is to make a designer's tool that can output complete, store-ready projects for simple apps and for both platforms. That includes three things that neither Xcode nor Android Studio does:
1) Interface Builder and Android Studio's layout editor are not meant for designers. (Seriously, try giving them to a Photoshop-educated designer.)
2) Xcode and Android Studio let you define views, but neither of them produces the controller-level code from visual designs. (We do that and also produce model-level code for simple apps; there's a plugin API for more complex situations, or you can of course do that in handwritten code.)
3) Cross-platform. Anything you do in Xcode or Android Studio needs to be rebuilt from scratch on the other platform.
...the idioms, best practices, device capabilities, and user expectations are different on each platform.
I feel that this doesn't hold true anymore. iOS 7+ and Android 4+ have largely converged on a flat style where a 3rd party app can define its own style that is easily compatible with both.
With Windows 10, even Microsoft is coming into this "common mobile" UI fold. They're giving up on the idiosyncratic (and interesting) Windows Phone concepts, and instead adopting a generic look that makes it easier to port Android/iOS apps directly. They're also offering new APIs and runtimes for that.
(Edit: To clarify, you can customize layouts separately for iOS and Android in Neonto Studio.)
I'm sorry, after reading you say "they are now the same because they are flat", I sincerely hope you fail. You are clearly not a designer, yet attempt to market a development tool as such.
It's just an observation: for real-world apps, iOS and Android visual styles and conventions are growing closer rather than diverging (and Windows 10 is trying hard to fit into the same mold).
Your observation about iOS vs Android is very narrow-minded, either deliberate or inadvertent. There are profound design language differences between iOS and Android material design. Claiming "flatness" is very shortsighted indeed.
A word on Windows 10, mobile or otherwise. It is indeed a mess, with almost no coherent design language, something that Phone 7, Phone 8 and Windows 8 actually had, for better or worse. Windows 10 throws many of the good design choices for a faux Android look, and a very bad one at that due to complete lack of consistency. Android also lacks consistency throughout, but at least a somewhat coherent design language exists now.
I do not wish to argue here. Do not take my wishes personally. As someone who wishes to only see good technology succeed, and I do not see this as good technology. I do not wish personal failure to anyone individual, and wish you personally all the best.
That's missing the point of what makes a good app. It like you say about Cordova apps: the last 20% takes 80% of the time.
Notifications are completely different on iOS and Android. Sharing data between apps is completely different. Wearables are different. Communicating with a server is different. Accessing contacts is different, as is accessing the camera. Sensors are different, and often differ between Android models.
Most of the big mobile success stories we've seen in the past 5 years have come from people utilizing the unique features of the phone, not treating it like a 5-inch dumb terminal.
> For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance.
That is a thing of the past. At the current rate of smartphone/phablet specs growth the differences with desktop are laughable (you can currently get 64bit octacore@1.7Ghz mobile devices with 3Gb of RAM for around $100) [0]. And this will only continue to grow. 16core and 32cores will be here in 2-3 years [1].
IMO, hybrid apps are already the present. The difficult times when we didn't have the required performance in our pockets are long gone... and frameworks like Ionic are really convenient for certain use cases.
> browser differences between devices (even Android devices with the same base OS can have very different web view browser engines)
That has been already solved with xwalk [2]... but again, this will be irrelevant in a couple of years.
the amount of cores makes no difference when javascript is single threaded. Infact its often detrimental especially on mobile because each individual core is significantly weaker.
Plenty of websites doing advanced html5 gunk bring top of the line systems to their knees.
Ok, valid point... But still the Ghz's per core are also increasing, and with that the overall performance. If you've used webapps like Popcorn-time or Slack you'll understand what I'm trying to say.
Are they native? No, they're JS apps
Do the users care? No, cos they do the "job" pretty well
We're reaching that computing power with mobile devices. In fact current mobiles are like desktops of 3/4 years ago. For certain kind of apps it won't matter if they're built with web technologies. (I'm not saying that you should bet on WebGL vs OpenGLES)
Perhaps what we really should be thinking is that 90% of applications can, in theory, be made using either web standards, native or a mix of both.
Unfortunately lots of websites and web apps are not very well developed. They serve bloated HTML that hasn't been minified, let alone compressed. The page is unresponsive or blank until a dozen JavaScript files have been loaded. Hardly anything is cached. jQuery is loaded to do select a single element and animate it when CSS would have done.
Most well written, architectured and developed web[site|app]s will not be too different in UX for end users than a native app. Sure, you can't write a great 60 fps first person shooter game for the web, but there's nothing saying you shouldn't be able to create an RSS reader or photo sharing app or social network or anything else with either the web or native.
I doubt you'd get a very good, highly detailed game running at 60fps with WebGL and asm.js today. Nothing comparable to what you'd get running well on a console. Maybe in another couple of years, but not today, and by then we might have non-web platforms doing 4K 60fps with ease.
But a lot of games do run quite well using WebGL. Just not the jaw-droppingly realistic ones.
Web APIs are in essence becoming an abstraction layer between OS and applications. It's not just about browser anymore. Browser is just one of the host for these APIs. In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have - even for heavy duty 3D gaming and offline video editing scenarios. Web APIs will and should become the standard way of developing apps across platforms. There is neither a theoretical reason that this is impossible or any other viable alternative agreeable among OS providers.
There is nothing to concede or regret about. It's just how things evolve. Get over it.
> In next decade or so, we should have all the power built in to standards that eliminates pretty much any advantage that native application can possibly have
> Web APIs will and should become the standard way of
> developing apps across platforms
God forbid. There are few lamer things than those Web APIs. Why do you think the gazzilion of frameworks exists, if not to work around all the things broken?
And take a look at the web in 2005 and now, see what real progress was made. Yep, we got a bunch of half-baked APIs, which will never mature, because all the crowd already run forwrad to tick another checkbox.
> Web APIs are in essence becoming an abstraction layer between OS and applications.
Terrible ones at that. In native applications you can bypass abstraction layers when you need it. In a browser you are restricted to a almost comically crippled version of what any native APIs provide.
Look at the <canvas> API. It's fairly modern, and yet I can't even turn off premultiplied colors, which I would need for doing even semi-decent image processing.
server sockets? udp? no dice.
even the most primitive file management? with the file API i can open individal files now. But can I grant a website access to some cordoned-off subtree of the filesystem? No. Which in turn gives rise to "store everything in the cloud" mentality, because there are no alternatives.
What are those? If you're talking about alpha, that can be bypassed.
> server sockets? udp? no dice.
The web platform doesn't allow protocols which bypass its security model, sure. But you do have other ways to communicate, WebSocket (over TCP) and WebRTC (over UDP).
> But can I grant a website access to some cordoned-off subtree of the filesystem?
It does not matter what platform you choose (web or mobile), bad developers develop bad software. For every horribly designed, slow, bloated website you find, you can likely find a similar horribly designed, slow, bloated native app. I'm sure you've heard of garbage in garbage out. I view development as a craft and like most crafts, not everyone has the same level of skill. This does not reflect on the platform people choose. It reflects on the people themselves, their time investment, work ethic, priorities, approach, methodologies, etc. Like with most crafts, there is usually more than one way to accomplish something; some more eloquent than others. At a very basic level, both web and native apps share many commonalities; some sort of UI being rendered and interactions with data via API calls. As long as you can reach your goal, does it really matter how you got there? How about this; the debate is ridiculous. They both rock (or suck depending on your perspective).
I whish this phrase would die and be replaced by bad "teams" produce bad software. I have worked on some projects with fantastic developers, but awful or no UX, or a misguided vision, rushed to market etc etc.
I have also worked on projects with awful awful code base but the end product is actually alright (so long as it doesn’t need any maintenance).
Perhaps we should flip it on it's head and say, "good technology doesn't guarantee good software".
Many companies and teams had a "web hammer" and went looking for things to nail even when that made no sense. At the peak of the web frenzy, web apps were going to kill desktop apps, and one could feel the pity when web devs were talking about desktop and mobile apps. And now... someone finally stops and thinks that maybe it's not such a great idea to turn everything into a web app.
When a group of individuals takes such a strong position and they are proven to be wrong, I personally think some crow eating is due :-)
Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won.
Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now.
It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.
Youtube is an interesting choice of example, since in a way it's "just documents" - those documents happen to be video, and are surrounded by hyperlinks to other video's pages. The real achievement here was cutting through the intellectual property thicket so that everyone could have an in-browser video player in HTML5.
The first site I ever saw that used Javascript to produce a useful application rather than annoying frippery was Google Maps.
(Rhetorical question: why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces)
>why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces
Two reasons: Bandwidth and Speed. Google has contracts with most major ISP's for caching Youtube videos. This gives them access to the best CDN money can buy! No matter how awesome or powerful your current datacenter/CDN is, it still wouldn't be able to match the fetch-straight-from-the-ISP performance. Interestingly this also creates a hidden monopoly since the barrier to entry is costly.
It's more than that. There's also legal liability (very few people would be comfortable hosting the amount of pirated content that appears on YouTube, nor would they have personal bandwidth for DMCA takedown requests), discoverability (YouTube recommends content you've never seen before, intelligently...by definition a personal site can't do this), and search (which only works when you have enough content to be worthwhile to search over). All of the algorithms used for the latter two points require a good amount of data, so Google gets large economies of scale there.
>Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible.
Flash DRM replaced with another closed source DRM. No progress whatsoever. And now it has embedded in the browser itself, greatly increasing its vulnerability.
>Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible.
What exactly is incredible about YouTube today (apart from it being a huge repository of videos, of course)?
That it almost works like a 2000 era video player, only slower and clunkier? The new fangled DRM? That it can bring a decent computer to its knees with the fans blaring playing HD video? The automatic non-skippable ads?
Discoverability, and elimination of the downloading friction.
YouTube is about as proven as you can get. The fact is that it didn't just edge past 2000-era video players in popularity, it totally trounced them. I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.
>The fact is that it didn't just edge past 2000-era video players in popularity, it totally trounced them.
How many people watch movies on YouTube? Because that's what video players are used for, not for small videos, music clips and curios.
>I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.
We were talking about it's performance compared to native, not it's viability.
YouTube rules as a huge video repository. Other "web" apps that don't have that stronghold, don't fare so well compared to their native counterparts, especially on mobile.
> That it almost works like a 2000 era video player, only slower and clunkier?
What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound. If you have a Chromecast, you can display the video on your TV instead.
Nothing in 2000 had a remotely similar feature set.
>What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet.
Nothing about this is "web" specific. That's just "streaming over the internet" as you said. Lots of native apps do it too (for both music and video, internet radio, iTunes video rentals, etc.). The reason we didn't have this as widespread before was limited bandwidth connections (a limitation of internet, not of being native).
>You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound. If you have a Chromecast, you can display the video on your TV instead. Nothing in 2000 had a remotely similar feature set
Again, nothing about what you describe is web specific. Native can do it all and do it better and with less battery crippling cpu usage.
And nothing described -instant seek, pitch shifting with retime, etc- was impossible in native video players in 2000 (or even 1995), while all of it was impossible for the web in 2000.
Which also means things possible for native apps now are impossible for web apps now, which makes sense since native is a superset of what functionality is available in a web sandbox, and with faster potential speed. (And of course being web is not a requirement for accessing internet resources).
> You were saying that YouTube is a slower and clunkier version of a 2000 native app.
You said: "Nothing in 2000 had a remotely similar feature set."
Not that Winamp 3 (released in 2002) was a svelte piece of software[0], but it could do realtime pitch/speed shifting and stream audio and video from the Internet. With a sufficiently fast connection, three seconds from link click to video stream start would be quite doable.
Streaming and decoding audio and video isn't anything new. The two new things that The Web brings us are "zero-install" and a the benefits of the large amount of sandboxing work that's been put into the major browsers.
[0] WA3 was slow because of the UI code, not because of the media stream and decode code. :)
And yet any media player beats it at its core functionality: video playback.
Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer.
There even are addons to export YT playlists to VLC and stream them.
pdfjs is great. but every 3rd scientific paper I read tends to be somewhat broken (missing diagrams/images) or sometimes fails to render completely. native readers provide a better experience and better render times.
>And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try.
Maybe sometimes it would be better to provide better integration with native applications?
Native applications and browsers really don't like talking to each other.
web and native will eventually merge to the point that for most intents and purposes the user can't distinguish between them. It'll never be perfect, but it'll be "good enough", that whether an app comes from the web or from the HD, the user won't really notice except perhaps in the initial startup time, and probably not even then (everyone expects to "install" an app).
shhhhssss there is no such thing as youtube-dl! I believe that the tool should be like Fight Club or it gets noticed and gets shut down through a drawn out war of changing code and apis.
I think media playback is only part of the core functionality. The other key piece is discoverability, and on that front, YouTube is far, far better than a native media player. It also benefits hugely from urls, which allow users to share what they've found. So, arguably, YouTube's success is more about what the web does well than about it's media playback -- it just has to be "good enough" on that front.
Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a superior platform for monetizing things, not necessarily a superior platform as far as user-experience goes.
> The other key piece is discoverability, and on that front, YouTube is far, far better
I'll give you that one.
But then again there are dedicated media-discovery-sites (imdb, last.fm) that do not have playback as their core functionality, even though they may offer some playback.
I would like to complement that native youtube(the one used on mobile) is far better at playback while keeping nearly every other advantage that it has on the web.
> that native youtube(the one used on mobile) is far better at playback.
No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite.
I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible. Much lesser control on ad-blocking too, and really the ads on YT are sometimes seriously irritating.
That is irrelevant. I prefer to not have ads and Google is generally kind of to comply and suggest developers respect ad-blockers as well, even though the vast majority of Google's revenue comes from ads. To suggest going native to provide revenue over UX only benefits the provider, not the user.
That's certainly not what I want to share. One of the things that good video sites provide is context. E.g.: Who made this? What else have they done? How can I find them? Has this been widely seen? What do people say about it?
Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to is often much more complex than a single raw file.
You could easily address those concerns without turning what should be a simple video into a clusterfsck of Javascript. For example:
https://mytube.com/$username/my_first_video.ogg
With such a scheme, you immediately know who made it - $username - and (if this hypothetical mytube.com built a proper website) navigating to mytube.com/$username would return a list of videos (maybe with some additional routes for playlists or categories).
Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).
This isn't much different from, say, reddit, where URLs are actually part of normal discussion; a redditor will talk about a subreddit called "/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly referencing paths (to https:/reddit.com/r/mylittlepony and https://reddit.com/u/Unidan, respectively). Granted, reddit's userbase is somewhat more tech-savvy on average than, say, Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to typical users, and it's certainly not hard to even manually demonstrate such things to new users.
This also isn't much different from many (most?) news sites, which provide URLs that resemble the name of the article (with some adjustment to make everything lowercase, turn spaces into underscores, strip or substitute special characters, etc.).
More like any application that interfaces with a JSON-based API. Those API calls work by talking to a server over HTTP(S) and requesting something from a URL.
There's no reason why a native app can't do this - in fact, many native apps for things like YouTube and Pandora and such already do this.
But how would that serve ads to the eyeballs? You forget that most of modern webcontent is just packaging fluff for eyeballs to more easily digest the real content payload - the advertisments.
That's not my problem. If it were, I'd solve it by embedding ads in the video stream itself, which is how traditional video broadcasters have done it for more than half a century. In the audio realm, Pandora already does this with third-party clients perfectly fine.
When most people ask, "Who made this" they aren't looking for a character string that matches /[a-zA-Z_0-9]{3,12}/.
They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.
If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.
Do you feel you made a point by listing services that exist only by breaking the law to exist as somehow related to business reality? Making your money by trampling the rights of others isn't exactly sustainable. The only way you have a point is to be rampantly intellectually dishonest, or ignorant of reality. Neither option is great, so charitably, it's best to assume you know this stuff and you're just trolling. Also not great. Do you have a 4th option?
I think grandparent just wished to say that "direct, free, downloadable videos" are technologically possible at large scale via p2p. Mentioning copyright is a bit off topic. It's possible to create a paid p2p service for video, and have tons of viewers without spending millions on infrastructure. Hence the bit about "business fictions".
The violation of IP is a similar problem for torrents and YouTube alike.
The "4th option" is that you've got the causality completely backwards in your head: it just happens to be the case that the cultures where distributed tooling became important were the ones where it was necessary to promote an "all information is free" mindset, not that it's necessarily a part of distributed tooling that you take that mindset.
If we start with a centralized metadata server/peer tracker, a set of "base seeds" to keep videos alive, and a commenting system, we can still revoke access to individual videos (our app will simply not support peer discovery except through our tracker, we take down the seeds, comments, and tracker entry on a revocation) while distributing bandwidth for the viral videos that need it.
> The violation of IP is a similar problem for torrents and YouTube alike.
Not at all, YT solved it many years ago with ContentID.
Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.
>imagine having to install a plethora of apps on everydevice...
Well, I don't have to imagine this because Youtube and Netflix both make you install apps. Flash and silverlight. You can opt-into the html5 streaming on yt, but that's still a change you have to make.
> Not at all, YT solved it many years ago with ContentID.
Sorry, there is some ambiguity in English about this. I am regarding a "solved problem" as a "problem" (i.e. classification) whereas you are regarding it as "no longer a problem" (i.e. interface). Yes, right now YouTube's interaction with the problem is highly limited (though not nonexistent), but if one is, say, trying to disrupt YouTube or talk about YouTube's history, one still classifies it as a problem in general that exists within YouTube's problem domain.
> Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.
I mean, I agree that it helps that particular problem somewhat to have a cross-platform virtual machine (the browser) and to distribute an executable (your JS app) on that machine rather than (or sometimes alongside) your content. This also creates its own problems, of course, like simpler browsers (spiders, text-only browsers) not being compatible with your website, as well as some new buggy issues when, say, the JS doesn't load properly. But HTML+CSS+JS is not new in this town and the cemetery has some gravestones -- like the fact that there aren't many desktop Java applications, the complete failure of the Java browser plugin, and the waning of the Flash plugin. It is peculiar among these only because its dreams are less lofty: not "write once run everywhere" but "write once, then write a (hopefully graceful) downgrade path if they do not support the features that I want to use."
>> The violation of IP is a similar problem for torrents and YouTube alike.
>
> Not at all, YT solved it many years ago with ContentID.
I'm not sure I understand. AFAIK youtube currently makes money (from ads) and much of what people view is copyrighted music that isn't properly licensed, and which yt doesn't pay for.
Sure, some, music is taken off yt, and some content is properly licensed -- but are you seriously claiming that yt isn't (any more) making money from copyright infringement?
There's some digital content distributed via p2p legally -- and it'd not be a stretch that yt owes it's current market dominance to "flaunting copyright law" as the copyright lobby might put it.
If one relegated content (video, meta-data, comments) to torrents/magnet-links (there is an issue of loops in the links in content-addressed systems -- but with a pretty modest central server (cluster) serving up a few lists of magnet-links should be affordable)) -- I think it would be quite feasible to distribute digital media in way which the consumers shared in the meagre cost of distribution through mostly donating bandwidth.
>Making your money by trampling the rights of others isn't exactly sustainable
Well said, you should tell this to Disney, MPAA, and MAFIAA so they'll stop trampling the rights of the commons by extending the length of copyrights everytime something profitable to them is about to expire. https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act
Well, if I click on the first link, a video doesn't play (that would be the case even if the link were to an actual MKV video). The second URL isn't even a hyperlink on news.ycombinator.com. But if I click on a valid YouTube link, a video plays nearly immediately.
the point is allowing independent applications to talk to each other (IPC) not to tightly integrate one application into another, that's a big difference.
Some (most?) browsers still do this when presented with a media file. Firefox in particular will use VLC on my machine for that purpose (or, if it's not installed, some HTML5 barebones media player, or some other media player that can be embedded if one is installed).
Before flash could play video, links that open in the media player of your choice were very common.
It was a nightmare. Each media player would try to hijack every link type it knew about each time it ran. But there wasn't full compatibility. So you'd click a link, RealPlayer would try to open it, and the player would crash.
The major players actively fought open standards, because they each had dreams of controlling a DRM & patent gated empire.
Flash brought some sanity to web video. Although initially it had performance issues (it had issues with hardware overlays on some video hardware).
I wouldn't say "initially"; Flash is still notorious for severe performance issues. That said, so are most native media players nowadays.
With that said, I'd be more optimistic of a kind of "media plugin renaissance" like what's being discussed in this day and age than I would be back in the 90's, what with all the insistence on standards-compliance and all that jazz. Eventually, with platforms like the .NET CLR / Mono catching on and becoming increasingly popular for cross-platform "native" (not quite native, but much more native than web-based) development, the chance of successfully reaching the goal that Java tried (and - arguably - failed) to reach back in the 90's is much higher nowadays.
I'm a bit less optimistic. Having different programs for each content type would restrict the developers' control into how they can interact with the users.
Simple playback of video? Not so bad. But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'? YouTube-like annotations? Show suggested videos after? Developers aren't going to want to support all environment configurations, so you'd likely end up with a separate supported player for each website.. which doesn't sound better than visiting a webapp tested against the popular web browsers.
Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
> But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'?
This sounds like something that should be a feature of the protocol used for streaming (in fact, I'd be surprised if most streaming protocols didn't support such functionality). Even without, this should be possible to do even with a native media player, and many streaming providers offer streams with different bitrates and encodings and such (for an example, check out soma.fm).
> YouTube-like annotations?
Most video players have subtitle and even captioning support; it shouldn't be hard to extend this to arbitrary annotations, be it as part of the streaming protocol, part of the media encoding, or even as a separate stream or file.
> Show suggested videos after?
Could be hypothetically done with an API call on the player's part to the video source (or some other source that indexes videos), which then provides the list. The player could then display said suggestions.
All three of these things could be worked around with a standard "metadata" path that such a video player would access and fetch an HTML page or JSON/XML document or somesuch.
> Developers aren't going to want to support all environment configurations
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0. I don't use separate web browsers for different websites, after all.
> Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
Part of the issue is that operating-system-level sandboxing has historically been insufficient. Bringing some modern server-grade sandboxing techniques (containers, VMs, chroots, etc.) to the desktop and mobile realms in an easy-to-use manner would alleviate the need for browsers to try and implement this themselves.
I agree that those are all methods of solving each issue -- but I think expecting each player to implement them (and correctly!) is the real problem. And when the standards don't support the feature they want, many developers would fall back to the web. It's hard to compete with a full-featured layout, style, and scripting implementation when it comes to customization.
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0.
There are web standards now, but, in practice, when you're supporting multiple environments, you're also testing against them. For webapps, fortunately, this usually just entails testing the top 5 browsers for a few versions, and mobile devices if you support them.
If the user comes to support saying something is broken with the video on their native app, trying to troubleshoot their native environment can be difficult, and telling them that their environment might be configured wrong often doesn't solve their problem. Which is why I suspect each site would support specific players.. not being a real improvement over the Gecko or WebKit <video>, <audio> in my mind..
Netscape could do this back in 1995. One of its preference settings let you associate external applications with certain MIME types; when you clicked on a link pointing to a resource of that type, it would automatically open the external program to view the file, as if you had double-clicked on it.
Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can register for this Intent and the user will be prompted for what program they wish to handle the link in. This is how the official YouTube/Google Maps/G+ apps work.
It turns out that for certain types of content, users really, really don't like to wait for external programs to load. It's not a technology issue; the technology has long existed to use rich clients, consumers just don't prefer it.
> It turns out that for certain types of content, users really, really don't like to wait for external programs to load.
And yet they click through full page ads, wait for "loading showcase" animations, scroll past parallax scrolling banner images and also wait for the ads on youtube videos and for the video to switch from 360p to HD.
Users are strange creatures.
I think if some effort were put into streamlining the native <-> web boundary then users would be quite happy with it.
> This is how the official YouTube/Google Maps/G+ apps work.
The question is, could this be standardized further? Basically a web standard that browsers agree to when it comes to talking to native apps that might offer specific services.
At the risk of getting stoned to death for this: WebD-Bus?
Although I think anything like that isn't going to happen. Browser vendors put security over everything else. Talking to native apps which already have access to the system would probably be construed as some sort of security risk, even if the user had to opt-in.
Ads exist in Native apps as well. At least in the web I have the option of browser extensions to provide a more customizable UX. With adBlock I don't get Youtube ads on Chrome so that point is null.
As for the last point, Spotify has some version of this. My native (mobile) Spotify app knows when I'm playing on my computer and vice-versa.
>It turns out that for certain types of content, users really, really don't like to wait for external programs to load.
I'm not sure how that's a valid point. My native media player loads in literally less than a second. (I timed it at 0.59s from when I double-click a file and it starts playback.) This is faster than any webpage can ever dream of loading. And unlike Flash or HTML5 video it gives me completely hitch free playback, whereas browser integrated player tend to drop frames quite frequently.
I would much rather use it than any player integrated into a web browser.
It wouldn't be hard to make that work on other sites that have a flash player. But we aren't quite sure if it improved the performance or anything, it just felt right.
This is an issue with the service not providing direct links to the video.
If you open an .mp4 file in Firefox you can set it to open in an application through your "Applications" settings. By default it prompts "Open with..." or "Save as..." in a dialogue.
If you open a direct link to a video you can open it to play in VLC (or player of your choice).
Does anyone remember Google Video Player? I remember installing this to try and play videos and being disappointed that it was basically VLC with a rename and much functionality removed.
You mean, being able to set media type handlers for your web browser?
I seem to remember being able to do that two decades ago. I imagine you still can (assuming you're up-to-speed with the configuration UI of the week for your browser), but it's not something people seem to do a lot.
I would compare and contrast the experience you are describing with a podcast player like pocketcast.
Synchronized play state and playlists on all the devices. Offline handling of the media files with streaming as an option. Feed subscription but also podcast repository and ranking/trending screens.
All media files are by definition in independant feeds, and sharing a file URL is supported.
It brings a hugely better experience than youtube pr any online video service I've seen. I actually switched to my podcast player all the youtube channels that also have a separate feed.
I think youtube is on your side, as it's heavily biased toward random one offs video watching.
I'm always baffled by the suggestions when watching videos from some common series. There would be mostly accurate suggestions, and consistently two or three videos completely unrelated taken from my viewing history. For instance there would be 'Howto repair your dishwasher' in the middle of all the videos of a math channel.
I tend to massively subscribe to channels and watch in batches, so I have (and want to have) a very good idea of what's coming next in my queue.
But having URLs or discovery or social features is orthogonal to using web tech, especially in the front end. Eg. Spotify had all of those in a tight little native client, before they rewrote it with web stack with controversial results.
HD-DVD was cheaper and required less immediate infrastructure changes, but rather allowed a staged switch from DVD.
Blu-Ray is the one that was better.
Actually this is exact reverse of a Betamax story - better and more expensive long term improvement won over short term and cheaper one.
You seem to be under the misunderstanding that video playback is YouTube's core function. No, the core functionality is to drive traffic to Google-owned sites, to be monetized as they see fit.
Youtube's HTML5 video playback on my 3Ghz i7 is so bad that I rarely watch videos in browser. Now it's even worse as all videos play in low quality unless you use DRM enabled "tech".
This is what I use instead: mplayer -fixed-vo $( youtube-dl -gf mp4 $* "$link" )
> And yet any media player beats it at its core functionality: video playback.
That isn't its core functionally, it's a social video sharing site, not a video playback site. It's core functionality is social sharing and all that goes with that, comments, related videos, channels, etc.
>And yet any media player beats it at its core functionality: video playback.
I would argue YouTube's core functionality is "making it easy to share videos with family, friends, and the world". Allowing playback of the videos on the page makes this functionality easier.
>Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer.
I do this too - although only because an addon I have causes Firefox to memleak if I leave a YouTube tab open too long. Rather than finding the problem and fixing it - I download a video I want to watch and close the YouTube tab. Honestly my video player of choice (MPC-HC) does exactly what the YouTube player does. It plays the video. Not a whole lot of bells and whistles needed to do that.
Youtube used to be better before at video playback, not as good as VLC but much better than what it is today. I think they have to deliberately hamper the user experience in order to save bandwidth, just imagine how much bandwidth youtube must cost with the amounts of users they have. Even their native android app isn't exactly the greatest which makes the web vs native comparison a bit easier.
Examples of this hampering is that they only stream 20sec ahead instead of the whole clip in one shot. There are many other annoyances like this, like not giving you the HD version even though it says the video is HD and you've selected HD, or when it re-streams the movie when you switch from windowed to fullscreen, probably because the windowed version was too low quality.
YouTube's video playback problems might have nothing to do with the web. Despite having an iPad app that is otherwise mostly great, their iPad video player itself is abysmal. It's just flat-out broken, and they're presumably not going to fix it. If you start playing a video, the timeline at the bottom will start turning grey from left to right to indicate the part of the video that is buffered. But if you scrub to a position in the timeline that is buffered, the video player will spin for a rather long time, and sometimes just spin forever until you scrub to a new spot or manually change the video quality. Bizarrely, if you scrub to a position in the timeline beyond the buffer, the video will load nearly instantly like one would expect. Somehow the buffered video loads slowly, while unbuffered video loads quickly. It's a huge bug, it's been in the iPad app for as long as I can remember.
That happens frequently on the desktop website YouTube too. It also happens on my Android phone using the native app.
Related to that, if you try to scrub to a position BEFORE what you are watching right now (say, 1 minute before), which is obviously buffered since you have just watched it, it goes full loading-retard again. It's like it just throws away the data it buffered and showed you. It is insanely infuriating.
Yes, that is my workaround as well. I also sometimes use the jailbreak utility VideoPane to extract the iOS-native video from the YouTube app and play it in a popup. You get the native video player and controls, and funny enough, it works wonderfully.
> And yet any media player beats it at its core functionality: video playback.
But can you build a democratic 24/7 music/video feed with a native video playback app? Maybe, but it is much easier with the web. And it has already been done:
The problem is two-fold: it sucks for web developers who end up having to learn a new shitty framework every day, dogshit tools to even work with CSS and JS, endless preprocessor and transpilers, perverted markup and tag hell to support said shitty frameworks and having to deploy massive fuuckton heavy sites for a simple blog post.
It also sucks hard for the end users : they can see their whole months mobile data allowance get pissed away on a couple of bling websites. It can takes ages now for modern site to finally work as it downloads so much shite. Some big name sites used to render quicker five or ten years ago.
At least in the past, you could turn off scripting, images and styling and get to the basic content, but not even that works now due to crap developers.
It all sucks. Diseased turtles all the way down.
Sure. And you're also made out of meat and will die soon. And we're living on a planet that is in the long term doomed even if we half-evolved, tool-using monkeys get our shit together. (Did you know that we're half-way through the lifespan of forests? [1] That one day the conditions just won't be right for them anymore? That never fails to sadden me.)
But the interesting thing to me is what happens when we move past the existential despair that comes when we first recognize the true nature of things. Sure, things are fucked, but they always have been. What's next?
When I was as bitter as you sound here, I took a break. Burnout sucks. But eventually I found myself coming back to technology because it's my best chance to make the world suck slightly less. Or, put more accurately, to shift it in the direction of my irrationally high ideals.
So maybe take a break? Go hike the Pacific Crest Trail or work on a goat farm or something. You're not going to help anybody, yourself included, by soaking in something you hate indiscriminately. At least rest until you can come back and focus your hate in a laser-like beam on one particularly awful thing.
He didn't say all technology is diseased. He was talking about the web. Writing native applications is still as fun as it has always been. Not that there isn't disease there too, but it isn't scripted and marked up to hell like the technostew that is the current web, which is what the parent was describing.
I keep hearing this argument touted, but if you view source on the HN home page it uses tables and a <center> tag.
You do not have to learn a new framework to do things on the web. The browsers all seem to support stuff that's worked for years.
The problem is that web developers feel the need to learn new things because they fear getting out of date. "oh, dude, I learned React this weekend. It's hot stuff! You need to learn this."
No, you really don't. You have a plethera of choices, and one of those choices is to rock it like it's 1999.
You don't need to know the new hot stuff if (a) you currently have a job and (b) that job is with an employer where people carefully think about their user needs, product goals, and then pick tech and write code with those needs in mind (much like the article recommends).
Otherwise, there's an extent to which you have to accommodate the absolutely rampant fetishization of current fashion for How We Do Things Now Because It's Better(TM) so you can sell yourself properly.
In more concrete terms: right now if you're looking for a gig as a front-end dev, you're going to have a much easier time finding a job if you can put Angular and React on your resume. The fact that this isn't particularly rational (or fair) as a hiring filter doesn't really matter.
If you're good at web development... that means you understand HTML, CSS, and JavaScript and you understand them at the level you should if you want to call yourself a web developer, then learning whatever framework a hiring manager wants you to know this week is trivial because you understand how the web works.
The problem is a lot of people just learn Angular for a gig. Then they leave 12-18 months later and go learn something else. It's never enough time to actually get good at anything.
And let me tell you... the hiring managers are taking instructions from development teams looking for talent. Those teams often inform management what is the hot new tech that needs to be used. But none of these things that people think they need to know have been so battle-tested yet that they are for sure the "next big thing."
I think experimenting is great. I don't think developers should worry themselves to death over having to keep up with whatever's new this week. I think devs would be better off investing that time in getting really great at the web. Really learn what semantic markup is. Really understand floats, clears, various display types. Really understand the fact that the web, without any JS or CSS, works great on mobile, because when it started, screens were 640px wide, and as a gang of developers, we've layered on boatloads of code to make it not responsive, only to make it responsive again. :)
And then, I believe everyone will be in a much better position to make informed decisions on whether or not "hot new thing this week" is really worth learning.
I'm a little puzzled about the "I disagree" part -- it sounds like you and I have some similar ideas about how things should be for front-end development!
Perhaps where we part ways is on the question of whether the industry leans towards sensible agreement. My impression is that it doesn't.
I can't help but feel like a lot of this has to do with "business realities", but maybe more importantly, it is also due to a whole generation of "developers" who have simply failed to learn CS fundamentals or did not start out with more traditional languages. The bad practices of the web are far easier to spread
The framework problem is a real interesting one... I'm a hobbyist--I am not employed as a web developer, but I like too experiment and see what I can create, so for me, learning a new framework is always a fun little project to embark on.
At the same time, i can't imagine how hellish it would be to work for a company that always wants to use the latest technology -- the framework market seems saturated to me, and I would wager it's probably better for a company to find a few technologies and stick to them, tackling problems/weak points as they arise and brewing custom solutions for those if necessary. Having to stop and shift over to a new framework every now and then seems like it would be a massive productivity hit.
I also don't like it when a framework becomes a crutch. Though I don't think that happens too often for most people.
I've also run into the heavy weight problem -- there have been a few instance where I've wanted to create something simple, and in most cases using a framework in that situation becomes the very definition of over kill. So instead I'll usually just write a simple php script or something to do whatever I need to get done, but even that feels a bit unnecessary. While I'm not sure if javascript should be elevated to all the use cases it has been recently, I do think it should be a language that enables a developer to natively(that is to say, w/o a framework) handle any simple functionality that might be expected for a site that is just a little bit fancier than a static site, so handling very simple data such as bare-bones blog or a simple mailing system. While it is getting there you still can't do something like write a simple form based mailer in pure js as far as I know, you can only open the client's native mailing app. You'd have to write a single php file or some other mechanism for that simple purpose.
But yeah, it seems like bloat is a tricky thing to avoid these days, especially since frameworks are the easiest, usually most error proof, and quickest way to get your website full of some modern bells and whistles, when in reality you may only be putting half of the technologies features to use.
> It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.
The article says exactly that! It just says we shouldn't shoehorn native stuff into the web (e.g look at Synology's UI mimicking a nested desktop and windows).
> We shouldn’t try to compete with native apps in terms set by the native apps. Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.
Youtube example perfectly fits that bill.
Yet there is also a critical difference to be made between "the web" and "web technology": while the former is operated in a browser, platforms such as Electron leading to apps such as Atom or Slack that totally don't try to mimic the native platform they're running on, powering cross-platform applications that nonetheless do try hard to respect† the platform they're running on, achieving something Java's cross-platform WORA GUI toolkit thoroughly failed to††.
† there's a clear, visible boundary between the native system and the webtech app, but that boundary is easily crossed, whereas historically we've been trying to erase the boundary and pretend it doesn't exist, only to veer straight into an uncanny valley.
†† dare I say Firefox sits right there too, forever battling the tide of mimicking native components with each OS release, from UI elements appearance (vanishing scrollbar, input fields...) to behaviour (non-"sheet" modal windows on OS X), in subtle but aggravating ways, if only because it erodes the product's image and detracts development resources from other efforts.
It's interesting that you mention YouTube, because the thing that finally convinced me that a 'web app' could be indistinguishable from a native app was YouTube's Leanback interface (YouTube TV). Check it out:
Is it only for mobile? I didn't see any "mob" or something in the URL. Anyway, with regards to being indistinguishable from native, I guess there is nothing quite like being reminded that you are "native" than an app complaining that you are on the wrong native device. :-)
In Firefox (my default br.) the message is: "Youtube on TV is not supported on this device, for more info go to: www.youtube.com/devicepartners" which is unclickable and unselectable. Modern web...
Youtube is the first thing I point to apps on my mobile devices... Why would you ask your phone to dl megs of crap everytime instead of having instant video load?
Over the chain of ownership of any website I would say starting out trying to mimic a native experience will inevitably lead to a bad UX. Maybe not at first but it will. Part of the reason I use HN as a web site on my phone/tab is because it doesn't try to get fancy and just gives me a great web experience. Shocker.
You can spin this either way. Clearly, the web is just another UI for "your data." It's going to have a different set of tradeoffs than native or mobile. Why not just use tools for what they are the best at?
MPlayer can kick the pants off of YouTube in some contexts. Likewise, MPlayer wouldn't be viable for a vast number of YouTube use cases.
I can benefit tremendously from using both Audacity and SoundCloud. Why does one have to "win?"
Maybe I'm misunderstanding something here, but I don't think the argument is to cede the web to documents, but I also don't think the idea is to cede all functionality to apps.
I think the problem is the hype about native apps and everyone wanting an app without understanding their purposes, utility, and unique characteristics. There are situations where a web app / site is the exceedingly more appropriate solution, but there are other uses where a native app is equally exceedingly more appropriate. The problem is that people are having a difficult time discerning the two and the appropriateness of each.
I don't agree with this article and the sentiment about the critical question being whether people want your icon on their homescreen as being the differentiating characteristic. What is not discussed is the possibility for putting the icon on the home screen as a link to a web view that can function the way a native app can function. It even addresses a question regarding distribution if you simply ask your user whether they want to "install" or add an icon to their homescreen to install your "app" / web app / site. It can be designed in such a fashion that it is indistinguishable from a native app of a certain type that has rather narrow requirements.
I'm not sure we'd be missing out; the abandonment of the document model has cost the web much of its democratic, decentralized usefulness, and it still isn't a very good application platform no matter how hard people try to make it act like one.
It's HTML and CSS holding 'web apps' back. It's like we're all trying to sharpen our pencils with spoons.
I think the future of remote web-like apps lies in something like QML[0]. A completely native UI with full access to the desktop widget suite can be downloaded in QML in a few kilobytes. Stick a browser like loader on the front of it, and provide a decent (seamless) asynchronous RPC, and you've got yourself a replacement.
Spawn off a rdesktop or VNC session back to a cloud based server. Skip all the intermediate interference that just slows down and complicates things, and turn the web into a dumb graphics terminal. You can either intentionally use the correct tool for the job, or painfully slowly buggily reinvent it if NIH is a requirement.
Similar, but the key difference is that Apple can kick the worst abusers out of the walled garden.
The Free Web can't do that (and I strongly prefer it to remain Free with low barrier to entry), so it needs a better approach, or needs to give up on having dangerous features available.
Indeed, that's why I think it's a mistake to copy native with problems plaguing it (when we don't know how to add these features without the downsides).
I'd prefer the Web to stay safe and hassle-free, and use native apps—with the risk of letting malware in—only when I really need more powerful features.
Let data be data. Let features be features. And let user interfaces be user interface.
So many websites mess this up in order to deliver a quick working site that only works on the desktop and sometimes only Windows. And now we have sites making seperate ghetto mobile versions or mobile apps missing features. We still have data that can't be accessed through URL with text that can't be selected or shown without JavaScript loaded.
Unless you are doing something more complicated than content devilery (ie games or utility apps) there is no reason to override fundamental features of the web.
It's clear that the web has outgrown its original intent. Instead of just being a simple substrate for linked documents, many (if not most) websites are now trying to emulate applications, platforms, and services using the poor, ill-suited DOM.
But I don't think the solution is to give up. Native apps are great, but there's a vast gulf between the binary running on your device and the server you got it from. Downloading and updating take forever. Connecting to other apps is barely possible. Everything is horribly siloed. The brilliance of the web is that it allows people to quickly connect to computers anywhere in the world and get at whatever stuff they might want to serve; native apps will never have that level of flexibility, barring some horrible proprietary ecosystem.
Unfortunately, the web was designed primarily with content in mind, not presentation. The only way servers can provide interesting and slick user experiences is to hack up the content presentation system, which is as silly as using spreadsheet scripting to build enterprise software.
So I think the best approach would be to revisit the design of the web. Instead of having the web be strictly document-centric, I think there should be a higher level above that, through which HTML, CSS, the DOM, and everything else are implemented. A sandboxed, scriptable, low-level canvas that only gives you the bare essentials, allowing you to create native-quality experiences without having to piggyback on the DOM or reinvent the universe via canvas or WebGL. A "Vulkan" equivalent for web software. Not making a document? Feel free to not use HTML — or only embed it in the parts of your web-app that actually present content.
It should be possible for a user to go to facebook.com and immediately retrieve an equivalent to the Facebook app in their browser — smooth scrolling, gestures, and everything. (Or whatever the future equivalent of a browser might be.) But if a user navigates to a simple blog, it should still appear as it does in the web today, because this new web would be a superset of today's web.
We've been interacting with other computers through a seriously constrained pipeline this past decade. Instead of bowing our heads and conceding defeat, why not blow it wide open?
What layer can you realistically have below the DOM? If you get rid of it, how can you realistically avoid reimplementing everything? I don't think this makes sense.
I think UIKit (and possibly Android, which I haven't worked with) has the right idea: nested, texture-backed views that can render their own content.
You might argue that canvas and WebGL nodes in the DOM already serve this role, but I disagree. In their current form, these nodes exist inside the document-based world of the web rather than containing it, an inversion of what I see as the proper hierarchy. This arrangement poses a number of problems for designing rich apps, including very poor performance related to content reflow. Some companies[1] are trying to fix this by manually doing all their rendering inside canvas and re-implementing HTML and CSS along the way. Unfortunately, this is a ton of work and results in a web experience that is non-standard in many ways, including for things like accessibility and text selection. The fact that this actually does work to significantly improve the user experience, however, points to the fact that something needs to drastically change for the web to remain healthy, useful, and relevant.
My understanding is that the DOM is already implemented as a series of texture-backed views in many browsers. That would still remain the same — nobody would have to reimplement this functionality. I just think it would be a great idea for us to be able to use those same texture-backed views for custom UI unrelated to HTML and CSS, and to separate the rendering concerns of text and document flow from the design of user interfaces.
In my experience, HTML-style layout is just horrible for app UI. It's really much better suited for text. On iOS, you can either use autolayout (constraint-based layout) or alternatively perform layout manually, in code, for that purpose.
I think it should be a subset of DOM / CSS designed for speed and flexibility. A normal browser could render the page correctly but an optimized browser for apps would be able to make some assumptions to render everything much faster. Something like asm.js but for DOM/CSS.
This article feels dated. If he wrote it in 2011, I would agree with him.
Web apps don't try to recreate the native UI anymore - something that used to be the case some years ago in the iOS1-6 era. Nowadays the UI of Android 5+, iOS 7+ and WinPhone7+ look very simple and Web-alike.
Simply avoid bloated outdated big JS libraries and use a minifier to shrink the JS and CSS files.
I thought the trend reversed as many little commerce switched from offering a Android/iOS app to a mobile-friendly website. This may not be a global trend.
quirksmode.org used to be great resource in the IE6 era. Nowadays http://caniuse.com and Mozilla's MDN have replaced it completely for me as it offers up-to-date information.
Don't just use a minifier: use something that can eliminate dead code, like Google's Closure Compiler in advanced mode. Don't ship 10MB to the client if you only need 1MB!
Sure it's just me anecdotally, but I don't care about native apps versus web apps. I care about where the ship takes me not the arrangement of its deck chairs. I'll use the command line...or the address/search box...if it gets me what I want. Good user interaction and great functionality subsume widget chrome and when it comes to native versus web experience please feel free to do something else on my behalf whenever it means doing more of the things I care about and less time bikeshedding.
Yes, of course and too many lifeboats might scare the passengers. That's why one can find work in the deck chair arranging industry, attend deck chair arranging conferences, and engage in debates over whether it is best to arrange deck chairs using tabs or spaces.
Yet somehow, users manage to navigate the web despite Apple's app store gatekeepers not setting policy. And really the debate about emulating native exists because of app store policy, not because the native standards are inherently better than what someone might invent left to their own devices...or even that they are necessarily better than the command line.
514 comments
[ 3.7 ms ] story [ 318 ms ] thread> Our working assumption has been that all web sites should be app-like, and therefore tooled up to the hilt.
I don't think that's true. Some people create horrible scroll jacking functionality for whatever reason - maybe they thought it was more 'native app like', maybe they just thought it was clever. But many other web developers already consider that bad perf is bad perf and aren't willing to put up with it.
In the future I envision, noone in their right mind would ever think native is the way to go.
I get the impression that the huge diversity of linux distros is enabled primarily by the fact that more and more development these days is web and not native.
And I don't think we'd have to fear the OS will become a "glorified browser shell" if it wasn't the primary "app development platform".
Right now native app development is feasible. You have pretty much 3 platforms you really need to worry about developing for in order to have access to the largest amount of market share for the least amount of effort. Imagine even one more player enters the market and gains any respectable amount of market share.
Instantly every mobile app development team's efforts need to grow or every developer on each team's responsibilities grow linearly with the total number of platforms they need to develop for. From an operational standpoint it's not sound economics to make business decisions based on approaches that don't scale well.
But we haven't even considered BSD-flavor. Perhaps if we expanded to include BSD-based operating systems. To name a few: FreeBSD, DragonFly BSD, PcBSD, NetBSD, OpenBSD.
All of the BSDs mentioned above have a very unique mission.
It's easier for me (as consumer) to choose any one of those to run my desktop / laptop knowing that I'm going to pretty much get all the same access to apps that I would if I were to run Windows or OS X.
Without any reassurance that I'm going to be able to do what I need to do on a BSD or Linux machine, I'm probably going to be stuck choosing something created and maintained by Microsoft or Apple.
No offense, but I'd trust PPK's beliefs about the mobile ecosystem more than any random HN user.
This can only lead to one result which is for developers to want a unifying platform on which to develop. I would argue that this exists, and is improving. It's called the web and web browsers enable this unifying platform.
Diversity is good, but too much diversity can be detrimental. A one-mobile-OS world is a terrible thing, since there's no need to push forward and improve. A two-mobile-OS world is better, as long as it's easy for users to switch to whatever is better at the current time. Once you get beyond three, you end up with a situation where it takes more and more development time to cover less and less of the market, and it becomes more likely that a single winner emerges (for example, the DOS-to-GUI transition in the 1980s-1990s).
One of the reasons this would be possible is because the responsibility of app development theoretically wouldn't be aligned vertically with the company that developed the OS, or with some platform that company is responsible for developing.
I recently had to help somebody with their public library and a particularly magazine publisher for digital issues. They require a web app to read the issues. They were trying to use their Mac, but the site refused to load. The public library staff had no clue why it didn't work ("well, it works for us", and their attempts to contact the publisher was your stereotypical tech support horror story.) Long story short, their website doesn't work on all browsers. They implicitly know that it doesn't work in Safari because they apparently wrote a native app just for iOS. However, they have no native app for Mac and never bothered to fix their website.
You generally don't have those problems in native. Apple in particular designs their APIs to steer you in the right direction and make it painful for you to do something that goes against their UX guidelines.
If you're not used to writing desktops apps, yes it will take longer.
With Glade + Python 3 I was chucking out GUI code faster than the Visual Studio + Win Forms because there was no compile step. No over engineered MVVM ala C#/WPF for a simple app - load a glade layout file, hook up callbacks - bam everything works together. The MVC is already there because the content pipeline (model) is already separated and views are defined in glade files. I had a prototype functional by the end of the day - it would take me that much just to choose which tools to use if I went Javascript client/Python server.
Seriously - couldn't believe how fast you could get stuff done with it - everything works as expected, you get all the controls you need - no need to learn random stuff like that qtscript, no build process (this is actually huge !), insanely fast iteration (faster than web-dev). I always thought of GTK like some obscure C gui lib but the Python wrapper makes it very usable.
My only complaint so far is that Glade seems to be getting progressively slower as you remove/add stuff so you need to restart it from time to time (eg. once per hour) but it starts instantly so it's not really an issue.
Note : I haven't yet tried to get it running on Windows or OSX since we all use Linux internally.
Anyone that has ever used RAD tooling for GUI applications can easily see how the HTML/CSS/JavaScript combo tooling is still miles behind from a 90's desktop developer experience.
One thing that is more and more important is batterylife. The more layers involved, the more energy they suck.
The VM approach allows the VM to synchronise application wake-ups which can increase battery life.
Google chrome on Android is acting much like a VM to developers and I'm willing to bet the Android Chrome team are spending a much time as the Java runtime team are on optimising.
People always go on about Cordova etc, but I've never used one of these that wasn't a clunky, slow non-native looking mess. Do you have any examples of Cordova apps which aren't noticeably more crap than, say, an average-quality iOS app?
* the very first animation (a slide transition to the left) was janky
* The app was unable to get my GPS location (it's being shared properly, and I have intermittent GPS signal, but if it was using the native fused location provider this would work perfectly)
* Buttons have no touch feedback.
* It's not the platform standard navigation drawer
* It's not the platform standard action bar
* The touch drag on the navigation drawer lags behind the finger position more than it should
* Non-native map has really bad pinch-zoom-pan gestures
As an Android developer I'm sure I'm consciously noticing things that lots of other users might not, but if this is the best Cordova still has to offer... :/
Having talked to a lot of users, they do notice. They may not be able to articulate it, but all the things you mentioned give them the feeling that the app is not as good as some other app.
Companies like Famo.us have proven this is incorrect mathematically over 2 years ago. That is precisely why Famo.us built its own rendering engine that subverts the DOM and renderings content similar to a gaming engine (Unreal Engine). The DOM can't render as many surfaces as a native app in one view smoothly.
You can still make a very performant cross platform DOM based application (http://hn.premii.com is an excellent example), but in order to get that performance you need to limit your interface to very basic UI elements.
Define your criteria for "winning". If I'm truly building a user experience, then I don't know a single hybrid app that has "won" (my definition of winning here is an app I use daily, and I don't know of a single app I use daily that is hybrid)
> 90% is easily good enough for most applications
The problem is most applications (80%) don't really even need a native app to begin with.
This is true only if you're working with people without experience. Someone who is experienced with the mobile toolkits is going to be able to develop the app just as fast, with more functionality.
But what if the browser is the OS?
I agree with the point though that we shouldn't be trying to emulate native to the T with web applications, that we shouldn't be stuffing them full of JavaScript. I think the Google IO 2015 web app [1] is a good example of what can be done on the web right now with minimal overhead.
1: https://events.google.com/io2015/
Then the user has chosen, for whatever good reasons, to run a pretty limited OS, and in doing so has chosen not to be able to take advantage of all the things that having a much less limited OS would offer.
This is only true right now and only if browsers were not working to make more low level stuff available. There is very little limiting about being in a browser these days. Drivers, perhaps. Kernel stuff, perhaps.
But as far as a game is concerned? Or an email application? Or anything in the context of this discussion? Not too much limiting them.
It will always be true forever, or at least for as long as a web browser is a program run within an actual operating system.
It's not a competition. Pick the right tools for the job. If the job is getting your eMail or playing a relatively simple game, and a web browser abstracting as an OS can support your needs, knock yourself out.
If the job is something a bit bigger than that, use a more powerful OS.
Lets not try to limit the web, but try to make it better and then let the users decide which they would prefer to use.
Right tool for the job. That's all.
Browsers (especially mobile browsers) are unnecessarily limiting what can be done on the web. Adding additional permissions could enable browsers access to more system resources and components, especially on mobile.
Could you provide some examples of applications that don't require a lot of data that couldn't be run in a web-based environment, because of physical (and not current browser or software) limitations?
Google IO 2015, I believe, stores it's data so that when you load it up it loads from a cache that it's service worker will reload once you have it open. Allowing it to work offline and removing the cost of transfer at the beginning.
I believe, not 100% on that.
There's still an extra layer, because the browser's API is far more complex and higher level than that of an OS.
Recreating the glory days of whole-page Flash sites, or those old Macromedia multimedia CDs?
a) Tooling: yes, it's still much easier to debug a native app than a pseudo-native app.
b) "Emulating native leads to bad UX": this section is absolutely right. Stop hijacking scrolling and building in cruft.
c) "Hassle-free web": absolutely right. You don't need an app for that. Just give us the information and let us have the basic interaction we want. No, you shouldn't present your menu as a PDF either.
d) News: this is where I disagree. Users don't go to news sites so much; they go to aggregators which link them to individual articles (reddit, facebook). It's hard to deep-link into an app. This is a case of the app existing to further the commercial needs of the content provider (increase lockin, ads and tracking) in direct opposition to the wants of the user.
People keep trying to make the "magazine app" happen, and I've seen very little evidence of it working.
If there's anything where you wouldn't expect significant value-add from the native or pseudo-native experience, it would be news. Certainly as a consumer I have no news apps installed - I go to the website.
I strongly disagree. I see "the news" is a perfect counter example because technology has changed what news is. Its not daily static content anymore, its now real-time, multi-media, interactive and interconnected.
The types of media on a news page include: recorded video, live feeds, audio, pictures and embedded digital content from other services like twitter created by both journalists and amateur eye-witnesses. These are not just value-less decoration like cute animations on landing pages but real content from the event being reported.
When news is data like election results, tax changes etc. interactive data visualiations are essential for digesting it. Interactivity lets us understand the impact of the news to us personally instead of single homogeneous national agenda. We expect all this and for it to be real-time and provide ways for us to be notified about changes, to share it and discuss it with friends and strangers.
I'm arguing against the parent that claims Web 0.5 (vanilla hyperlinked documents) is enough for the news. This is only sufficient to duplicate a newspaper and present prose\pictures of what happened yesterday. I claim that technology has dramatically changed the fabric of news itself which now requires the modern Web with its document/app blurring to include dynamic behaviour, interactivity and multi-media.
Disagree. Case in point: steam://friends https://www.iana.org/assignments/uri-schemes/prov/steam
/s/ steam for news://home or news://business/26-05-2015-oil-prices
The content could (and definitely should) still be html, obviously not everybody you link to is going to want to install the news app and it should fall back to opening in a browser, but if you want to wrap a fancy interface around what should just be text there's your solution.
Also from that link: "Security considerations: Unknown, use with care." Great!
(news:// is already taken by Usenet NNTP to refer to articles by ID)
The few successful native apps with linking (iTunes, Spotify) go via the web.
It's not much easier to debug multiple versions of multiple native apps than it is to debug one web site.
They may look good, but they tend to break things like back/forwards have text that can't be copied and pasted.
Some have embedded video, which eats everything.
That's not a requirement for building a single page app, there have been ways of emulating history in spas for a while now.
> have text that can't be copied and pasted
What do you mean? SI'm not aware of any sites whose text 'can't' be copied unless they disabled right clicking.
Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-form articles, for example, when the basic purpose of the web is designed for reading documents? Why weren't multi-page transitions built in by default?
The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles? Why are there a million JQuery photo gallery plugins?
In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text? (proper fonts & spacings, limiting column widths to 8-15 words max, etc..)
The reader-mode that web browsers are building in, that should be the default standard UX for HTML, and CSS should build upon that. But instead, it's a non-standard option.
By contrast, corporations can more easily make these sort of decisions – by fiat – which is why native app frameworks are more "opinionated" / make more design decisions for you out of the box.
This topic is as much the story of two historical forms: the operating system GUI and the World Wide Web hypertext project as it is about two organizational forms: hierarchical corporations and decentralized design-by-committee non-profits / multiple competing corporations.
I recall when I used Opera, you could scroll down, hit space, and it would go to the next page as long as the website provided that information (forum softwares often do.)
I also mentioned the column width because this site has the obvious problem of long horizontal text, which is a no-no. People naturally read in chunks of 10-15 words scanning vertically. Long, horizontal text is easy to lose track of location.
> Size Matters
Strong disagree on both of these points. I view most webpages (including that one) at around 66% zoom these days, because the text is so goddamn big. And anyone advocating for less contrast needs a shovel to the head.
Or they have the thing where high contrast makes the letters jiggle and therefore difficult to read. I get that when tired.
Maximum contrast does not make for good general usability, even if you happen to like it.
While grey on white may look better, actually reading text is easier as black on white.
Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.
> photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?
Because there's no one size fits all solution. Look into magazines, newspapers, etc. After a few centuries there is still no standard. Grouped, with captions, position, size, etc.
> why do we need to write CSS to create a basic readable document in the first place
You don't. Browsers can display semantic markup just fine without any CSS. The fact that you even ask this question is why you write CSS, because different people in different times expect different styling, and they don't think the default style is pretty. I agree that the default styles could be improved though after 20 years, but that could lead to breakage of current CSS styles, and why risk that if everybody uses CSS anyway?
And the fact that I wrote this comment is just another reason why you have to write CSS: because not everybody agrees on how the web should look.
Actually yes this is the use-case I was referring to.
HTML has semantics to define sections, headers, etc.. but it doesn't manage them in any way.
If you write HTML that define sections, for example, it's no different than if you write HTML without sections.
Ultimately, I don't think of the web as a page-based medium, it's document-based. Electronic documents that want to mimic pages are a relic from the past, imo. What you seem to want should probably be implemented as browser plugins.
What I read was that it's not for "more ad displays", although closely related. It's because news sites keep (and market themselves based on) a "pageviews" metric, so they try to get as many pageviews as possible out of each piece of content.
Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.
I am not talking about fixed pages or clickbait websites where you have to scroll anyway and then click a "Next" button, but about having a flexible way to enable pagination of content.
That pagination is one of the reasons why for me the best way to read something like the stories in http://longreads.com/ is on Instapaper (or a similar tool).
You may like pagination but I do not, and I would argue its better suited as an option, not dictated by the author.
90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light.
If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.
I would flip that: we need to explore ways to generate revenue which don't rely on practices like trackers, structuring content to inflate page-views, etc. which don't benefit the user.
The most obvious example I'd use is ArsTechnica's approach of disabling ads for subscribers – I notice this any time I use a new browser and pages take twice as long to load because web performance just isn't a priority in the ad world.
But then rather than poor content, there would be next to no content (for the masses) because business have expenses ;)
Speaking seriously, yeah I see what you mean. Maybe reducing ads and improving speed would result in better UX, which would lead to better user retention, which would leave to more ad clicks. But that's a lot of maybes. Why risk that if people are used to ads? Ads often come when subscription is not an option.
You can explore other revenue sources (e.g. affiliate) but they are usually not widely applicable. And other than that, there's not much to do. I don't really think there exists a business model which could replace ads (when, again, subscription is not an option).
Yeah. That sucks. But that's the reality.
This is only true if you constrain the "web" to mean the Tim Berners-Lee document-centric HTML and its http hyperlinks.
The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a interconnected electricity and have done other things with it.
Do some "native" apps do nothing more than what a 100% static HTML could do? Yes, abuse of a Javascript widget framework does happen. However, the bad examples don't mean the "web" should be held back by the original visions of HTML or Hypercard. The Google maps app is not traditional HTML+CSS.
EDIT: The replies misunderstand my position. I'm not trying to redefine the traditional technical meaning of "web" and make you like it. I'm attempting to explain that "the web" has evolved and what it now means to the world out there. (E.g. see non-document usages like Dropbox, google maps, online Sudoku games, etc.)
Because http & https is ubiquitous and they have a defacto pass through most firewalls, the modern "web" is the "internet" as far as application interfaces are concerned.
The idea of a pure separation of concepts such that http is "documents" and some other protocol on some other port is "apps" is not going to happen. All those IT departments' security teams and Cisco admins at Fortune 1000 companies are not going to adjust their firewall rules to open new ports and protocols. The "http port 80" has become the "internet" on top of the old definition of "internet". It's not ideal but that's where we are today.
Maybe things will be different in the IPv6 world.
In this context, it can be safe to assume that everyone knows this technical distinction (even for those of us who are not web programmers). In other contexts with less computer-technical people, I don't think being annoying and correcting every "technically incorrect" mention of "The Internet" when they mean The Web is helpful. But I think it is helpful to remind them of the distinction if you are actually talking about the subject (as opposed to just saying things like "look at your internet, I just sent you a facebook message"). Computers are magical enough as it is; it doesn't help anyone to make it even more so when they are even slightly interested in discussing some part of computing or IT.
Explaining that The Internet is the infrastructure and the Web is just one the things that uses this infrastructure seems simple enough to grasp, and isn't an oversimplification at all. People understand that the electricity grid has to exist in order for them to make toast.
How about a native app based on a "web view" that uses HTML, CSS, JS, etc. (the whole W3C stack) and doesn't even talk to HTTP/S but uses some other port and transport mechanism?
Also known as Ethernet protocols, nothing to do with "The Web".
It's about the evolution of how society sees the web and not about what its original purpose is.
Dropbox uses html and http. Drew Houston and his team are not going to submit an RFC so that the internet has a new protocol and port "dropbox://myaddressoffiles:8675". No, Dropbox the application will just use "http://". It's because they did not pursue conceptual purity of having "dropbox://" that allowed everyone inside and outside of corporate networks to use the service and share files.
That is "the web" we have today and in that scenario, the non-technical use of "web" includes the underlying internet stack to make web apps possible.
What's the alternative? Tell millions of Dropbox users that such a service is outlawed because "the web is best as a document platform?"
The "web" as in Tim Berners-Lee(TBL) "world wide web" is http+html which is "documents".
Saying TBL-web is "best as a document platform" makes perfect sense. It was defined that way therefore, use it that way. It's tautology.
Back in 1993, if we want to say "X is best though of as a network app platform" we'd have to use the word "internet" instead of "web" for "X" to be conceptually pure and technically correct (the best kind of correct.).
But now we have things like Dropbox (and thousands of other "web apps"). Dropbox runs on "http".
Dropbox "syncs". Syncing is an app. Dropbox is an app. Dropbox runs on http. Http is "the web". Apps run on the web. The web is platform for apps. That's the reality of where we are today.
This is they beauty of the network communication protocols.
It is is just a consequence of what network protocols happen to be open by default.
This is only true if you constrain the "car" to mean the Henry Ford, transport-centric engine-and-chassis.
The "car" also means the whole transportation stack: pavement, asphalt, road signaling, etc. In that case, the car is a foundation tool for anything that transports people or inanimate objects. To say the "car works best as a transportation device" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a horseless carriage and have done other things with it.
Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on. The "web" has become the "internet" for both documents and applications.
It's descriptive, not prescriptive. (See my other replies to illustrate how usage of http has evolved to coexist with corporate firewalls that lock down ports.)
The world has not moved on. Part of the world has dug itself into a technological hole. Most of the people who work in it have never seen what's outside it, so they think the solution to all their problems is to keep digging.
Edit: crap, I sounded so snarky and aggressive. Sorry about that. It's not something personal -- I obviously got the point that you don't think everything about that is a good idea.
The point I'm trying to make is that not ever technological move is necessarily a "good" evolution. Every narrow street in technology was once thought to be a superhighway that everyone flocked to.
I remember everyone being so bloody enthusiastic about this whole Web 2.0 thing back then (and I was one of them). Then all this data crumbled as people paid less and less attention to information structure and semantics and focused on the flashy stuff. Then it turned out a lot of problems were intractable if you clung tightly to JS, CSS and the web browser.
Yet for some reason, people thought those problems happen just because we don't cling tightly enough to JS, CSS and web browsers.
Oh -- and twenty years after operating systems that aren't full of memory leaks, security problems (eh...) and performance clunks became reasonably accessible to people everywhere, people are trying to promote ditching those for web browsers. Which, I would estimate, will need another twenty years or so to stop having memory leaks, dubious security and privacy practices, and embarrassing performance clunks.
To clarify, I'm not saying "moved on" as an objective measure of superior technical progress.
The "moved on" is referencing a descriptive (not prescriptive) state of affairs with how the world now defines "the web". The existence of sliding around map tiles in maps.google.com, syncing folders in Dropbox, etc is evidence that the world does not think of "web" the way Tim Berners-Lee thought of hyperlinked documents in 1993.
"The web" is defined by a set of traits (hyperlinks etc.). When whatever we're doing stops having those traits, it's no longer the web. Continuing to call it "the web" is not some form of philosophical awareness, it's just ignorance.
I 100% agree that ""The web" is defined by a set of traits (hyperlinks etc.)".
I'm also adding that "web" also now includes expanded perceptions by everyone else beyond "hyperlinks+http" and that enlarged perception is unavoidable. We could ask the world at large to *not" call it "web" but that's like asking us to quit calling "machine calculator" a "computer". Sometimes we invent a new word, but many times we don't.
Yes, a person uses a "web" browser to read a "document" on New York Times. But they can also use that same browser to play a Sudoku game that's not a document at all. To the layman, both actions are "surfing the web".
But the World Wide Web is very much here and very present.
> To the layman, both actions are "surfing the web".
To the layman, a server and a computer are the same thing, and yet calling Apache a computer is incorrect.
And educated programmers call various text styles, "fonts" even though technically, a font is actually a specific size, and specific weight of a "typeface". The "font" is a subset of "typeface". Even though typefaces still exist, almost everyone uses the word "font."
And programmers will also call SQL (without CTE) a "programming language" even though it's not Turing Complete.
Even binary black-&-white-thinking programmers will exercise a lot of leeway with how words are used.
I want to emphasize that this all started with my response to the "web is best as a document platform."
I think most of us can substitute "web" to say "http+html is best as a document platform." That's what TBL meant.
Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as reality, what does "web" in "web app" really mean? The "http+html" has become a universal transport mechanism (with some apps even tunneling through http to do interesting things.). As the years progress, there are more examples of http becoming a "dumb and dumber" generic transport pipe for things that are not documents.
Let's say a startup company wants to create a website to crowdsource music promotions. They want the service to offer programmable access so people can write open source clients. The presentation slide / whitepaper will not use the phrase "internet api". Instead it will use "web api". If every corporate firewall and user' homes computers with Microsoft Firewall had wide open UDP ports, it's possible for the phrase "internet api" to have more currency than "web api". But that's not how history has played out.
HTTP + HTML does not include "the whole Internet stack, TCP/IP, DNS routing etc.", as you mentioned above.
However, that wasn't the level of conversation I was trying to have.
There is another viewpoint of http+html that is not the specification. That viewpoint is the usage of http/html/TheWeb.
For example, the White House is building made of stone. It is not a human. So how can newspapers say "the White House has signed the Internet Freedom Act into law." Well, we're not getting anywhere going round and round in circles insisting that stone buildings have no agency to pick up a pen and sign a document and that only a human like President Obama can do it. There are multiple meanings of "White House" and we seem to get along fine with it.
There are also multiple meanings of "web." It's possible for the industry to invent a totally separate word besides "web" for the abuse/reuse of http+html as a transport for apps but that didn't happen. If a startup in Silicon Valley has a goal to release an app that makes use of TCPIP+DNS with the best chance for wide adoption, they can entertain the idea of using a custom UDP+port scheme... or they can just piggyback on http. They didn't use http as Tim Berner-Lee's specified in 1989. It's the out-of-spec usage that's adding new color to what modern "web" means.
I'm not saying I approve of it or it's technically superior. They didn't ask TBL's permission for it to evolve that way. Is it anyone's fault?! Too late to assign blame now. It is what it is. The phenomena I described above exists no matter what label we give it. It would be awesome if another word besides "web" described it but it doesn't exist (yet).
If the "White House" can act as a synonym for "human", it's not impossible for "web" to act as synonym for "whole internet stack." (Again, the synonym mapping is using the other evolving definition of "web" instead of the official RFC specifications.)
I'm pretty sure there are different protocols for email, torrent, etc. And I don't see how that is a bad thing, or why The Web has to be a frontend to everything that comes from The Internet (desktop email application for instance).
No, absolutely not. The "web" refers only to what you mentioned above. It's only a recent bastardization that we started referring to the "Internet" as the "web", because of the dominant nature of HTTP. You're right though that the Internet is important, but the GP's point stands that HTTP was really only intended as a document protocol (Hypertext, yeah?) and it has seems a somewhat strange perversion that we've bent it to doing so much more.
Someone not in the know may call the transmission in a car "an engine", or call the differential a transmission. Just because someone outside of the industry does silly things like that doesn't mean all of a sudden obfuscate the usefulness of terminology at all, as it really helps no one.
As far as I am concerned those things only exist to inflate ad views, they have negative usability impact. I don't really see why a long document should be broken up in pages to be readable.
> The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?
There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.
> In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text?
I find plain un-styled HTML to be much more readable than the tiny light gray webfont on white background that designers usually settle for these days.
Except when people nest the images as deep as posible and overlay other elements in front of the images so you can't simply right click the image, you have to inspect source and hunt for that image URL (or check resources tab in developer mode, or whatever).
/rant
Certainly not. In my opinion, the problem with the web is that it has become too complicated. In an effort to make the web simpler for the ordinary user, the web has actually become a more complicated place for the (advanced) developer.
HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility. For instance, a developer has no choice of programming language, but has to resort to javascript; we are stuck with the cooperative multitasking of the 80s (webworkers support only message-passing, no shared state); also, the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet). And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
I'm hoping that in the future, we can make the web more simple and elegant for the developer. We need simpler primitives, not the complicated and restrictive building blocks that we have seen thus far.
(I haven't used web workers, so maybe they're in fact awful to use. But from what I've read, it looks like the right decisions were made, pretty much.)
Also, shared immutable state is a useful (often perhaps even essential) property for building efficient code in a multithreaded environment, even when using the message-passing style.
Verifiable security? You can't statically verify a program is secure.
Flexibility? The complexity has given it greater flexibility.
> For instance, a developer has no choice of programming language, but has to resort to javascript
Just like on native platforms, where the developer has no choice of programming language, but has to resort to machine code!
Unless you use a compiler. Which you can do, and it works very well.
I thought you thought complexity was a problem? Introducing "native" other-language support would only increase it.
> also, the developer has no choice of render engine
I thought complexity was an issue?
But this is also not true. You can use your own if you really want to.
Although why you need your own rendering engine is a good question. Almost all native apps use the OS's GUI framework.
> the developer has no choice of render engine, and to make matters worse, the developer has to write code that is compatible with about five different platforms (desktop/phone/tablet)
Who said they did? They can choose to write code that doesn't work well on other platforms. Though that's largely a UI thing, the code will run on any without changes.
> And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.
What? From a code perspective, if it runs on one, it runs on the others. The API is the same. The only difference is UI: screen sizes and input methods.
> We need simpler primitives
We have those. If you want to run a 50MB C++ GUI framework in the browser, you can! It's just a terrible idea.
As a developper I look at native app development the same way I saw the web in the early 00's. Different platforms, screen sizes, versions, programming languages, paradigms ...etc.
I don't believe it is that clear cut. I think you are ignoring the fact that native developers have frameworks of their own. Using Boost, GTK+, or Qt gives various layers-of-thickness over the OS so the native code is portable. Some, like Qt, also cover mobile operating systems as well as desktop ones. These frameworks are not young either; so while websites had browser-specific-detection-code (thanks to IE), native apps were already running cross-platform by leveraging frameworks of their own.
"Practical Cross-Platform Mobile C++ Development"
https://www.youtube.com/watch?v=ZcBtF-JWJhM
MuseScore
http://showroom.qt.io/musescore/
Qt show room has many others - http://showroom.qt.io/
This is because you are using tools and paterns to avoid having to think about the differences. Those tools are also on native platforms, and those differences apply to the web.
This, a million times. Mobile websites and mobile apps have completely different strengths. The current trend is to develop them both with the same HTML-based toolchains and make them as similar as possible, which ends up being to the detriment of both.
Users don't want mobile apps that are simply a website packaged up behind the "icon on the homescreen". Those apps lack the essential benefits of native: fast and seamless access, smart use of local data, integration with device services like notifications...
There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up because it first loads a browser engine, then makes a hundred HTTP requests to fill up that embedded browser with content. (And if the 3G network happens to be clogged, the app may end up showing nothing after 20 seconds.)
For developers, Cordova/PhoneGap-style tools are not a panacea either. It's easy to get an 80% solution done, but then you run into problems with mobile browser performance, browser differences between devices (even Android devices with the same base OS can have very different web view browser engines), etc. With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in.
Shameless plug: my startup Neonto makes a UI design tool that creates usable iOS and Android code from visual layouts. It's a great way to remove the friction in creating real native apps: http://neonto.com
To be fair, that could be said about most software projects. "80% done, now the last 80% remains."
Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games) I have tried. They are only suitable for basic stuff where the native feel isn't critical.
Yes, absolutely true. The difference here is between "known unknowns" and "unknown unknowns", to paraphrase a certain renowned military strategist...
With Cordova/PhoneGap, it's easy to get the initial impression that you're dealing with "known unknowns", just the typical web development project pitfalls -- "This is HTML, I know this stuff".
When the "unknown unknowns" hit the fan, it's often pretty late in the development cycle, and so things blow past original estimates even though they were competently planned. It's just that the plan was for web development, not the shifting art of websites-in-drag-pretending-to-be-apps-development.
Waterfall approaches are really only appropriate when there's nothing particularly risky. I plead with the HN audience: never let a manager choose the waterfall model by default. They often happen because they make contract negotiation easy. But that's only because they save all the trouble for later.
I tend to think it's good when running in a browser but not when it's made mobile web app capable and running full screen without native controls. Unless it's a super simple single page app.
At the other end there are things like Instagram where you basically can't do anything on the website (can't sign-up, can't upload photos). Everything requires the app.
You can use much of your JavaScript skills and still get to go native.
I'm excited to play with React Native but I fear it will suffer from the same issues.
you start having to litter your code with `if(isAndroid)`/`if(isIOS)`
That's an inevitable drawback of a cross-platform framework like this. XCode and Android Studio only work with one OS, so they sidestep it.
You're joking right? ;)
> There's nothing more annoying to a mobile user than an "app" that takes 10 seconds to start up
Try this on your mobile browser http://hn.premii.com/
Now download this. Android : https://play.google.com/store/apps/details?id=com.premii.hn Or iOS: https://itunes.apple.com/us/app/hacker-news-yc/id713733435
And play with it. Download top 5 native HN apps, and launch those, and tell me which one takes 10 seconds on which device.
No doubt that you will have to deal with different version of webkit browsers (webview) on android. As long as you follow standards and not use latest CSS rules, you will be fine. And with Android 5.0+, its much much better.
---
Now try this page on your mobile, and tell me how bad it is. This is few hours of work (Flipboard style animation), and works on iOS/Android Chrome/WP8: http://reddit.premii.com/#/r/news
There are issues with browsers, but performance is not one of the issue.
----
It takes time on Cordova not because of HTML, but because how each platform works natively. I am not a native developer.
Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices. It's going to take a while until you can build hybrid apps exclusively for Lollipop.
If you don't think mobile browsers have performance issues, you must use high-end devices exclusively.
Twitter is list of stories with notifications. For me its more like HN app. HN has list of stories, Twitter has 140 characters tweet. When you click on the HN story, you get list of comments or article. When you click on the tweet, you get replies and retweets and so on.
Facebook is a same thing with pictures and videos. Try this http://reddit.premii.com/#/r/pics - enable pictures view from top right dropdown and http://reddit.premii.com/#/r/gifs to try gify/video
---
I didn't start with Android 5.x. I started my app with Android 4.x. I don't think you use low end Android device. Even native apps on Android has lot of issues related to performance.
On my Nexus 5.0/Android 5.x, Facebook scroll is not smooth when there are pictures. I only get non-important notifications from my twitter app.
I test my app in first generation of iPad 2 (My iphone 4s broke) and galaxy s3.
---
Now show me 5 meaningful 100% native apps (Non-game) that are not developed my a startup with a huge capital or big company, available on iOS and Android, and has 4.x star ratings.
Now, these are all Android apps, and few (if any) have iOS versions. But they all have iOS equivalents -- and I don't think most of them would've been as good, as non-native apps.
Note the absence of stuff that works well as a website, like facebook or twitter. For games, I think the choice between native/html should probably be governed by the answer to:"Is it as much fun as html/webview?". This is a good yardstick for other "apps" as well.
For eg hn, there's no need for an app, but of course hn is a pretty terrible web page. There are a number of easy fixes that would make it more usable, especially on small screens, but the maintainers don't care. And that's fine -- it's not accidentally bad, it's intentionally bad.
One could make a similar site that didn't break voting, threading, screenlayout on small screens quite easily. And it should probably be a web site.
One can make a "web app" to schedule meetings (see doodle.com) -- and one could augment that with something native[1]. Or one could make native apps like the ones mentioned above.
Could one make a web-rtc proxy for ssh and allow logging in to edit firewall rules via web browser? Absolutely. I'm not sure I'd want that though. Not as long as web browser security refuses to learn from office macros: unsigned js code, all or nothing execution etc.
There is some middleground, as google docs demonstrates. Personally I prefer content creation/editing to be local, possible to do off-line (with sync) -- and I'd like competing apps to be able to easily share data (via eg: the file system).
Now, that twitter can't be bothered to make a decent web-site isn't really an argument against web-sites. It's an argument against poor web-sites.
[1] http://9to5mac.com/2015/05/14/sunrise-meet-keyboard/
Folks were saying the same exact thing about 2.x when 4.x came out. By the time 6.x comes out, everyone will be yammering on about how 5.x marketshare is still strong and "seems quite resilient in low-end devices", blissfully ignoring the point in time when 4.x - like 2.x - fades out of view as it's increasingly ignored by app developers.
Meanwhile, in the actual low-end space, you have things like FirefoxOS where there's zero difference between "web" and "native" because "native" apps are just web apps with special hooks for things like cameras and sensors, or you have things like "feature" phones where the closest thing to a standardized platform you have is Java ME.
Featurephones are largely gone. Microsoft bought Nokia's featurephone business, shut down further development and has been converting it to low-end Lumias as fast as they can, but Android is nibbling away most of that market.
And feature phones are still dominant in places like Africa and South America, particularly due to their lower cost and power consumption (smartphones are still unable to reach the battery lives of even dumbphones from a decade ago, which is an important consideration in environments with limited/inconsistent electricity). Even in "developed" countries, feature phones are popular with the elderly and disabled, since they usually feature physical buttons that are easier to work with (better tactile feedback, easier to find with poor vision, etc.) and have simpler interfaces.
It seems like apps are less maintainable. Right now pretty much all of the Android HN apps are broken in some way, or missing a core feature of the desktop experience.
I have not updated my downloaded app in long time.
For HN, official APIs are very limited.
The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expectations are different on each platform. So your client generally has to be ground-up development by an experienced expert in the platform, you can't just take the same layout and make it run on both.
Well, for some definitions of "usable" and "visual layouts"!
Our goal is to make a designer's tool that can output complete, store-ready projects for simple apps and for both platforms. That includes three things that neither Xcode nor Android Studio does:
1) Interface Builder and Android Studio's layout editor are not meant for designers. (Seriously, try giving them to a Photoshop-educated designer.)
2) Xcode and Android Studio let you define views, but neither of them produces the controller-level code from visual designs. (We do that and also produce model-level code for simple apps; there's a plugin API for more complex situations, or you can of course do that in handwritten code.)
3) Cross-platform. Anything you do in Xcode or Android Studio needs to be rebuilt from scratch on the other platform.
...the idioms, best practices, device capabilities, and user expectations are different on each platform.
I feel that this doesn't hold true anymore. iOS 7+ and Android 4+ have largely converged on a flat style where a 3rd party app can define its own style that is easily compatible with both.
With Windows 10, even Microsoft is coming into this "common mobile" UI fold. They're giving up on the idiosyncratic (and interesting) Windows Phone concepts, and instead adopting a generic look that makes it easier to port Android/iOS apps directly. They're also offering new APIs and runtimes for that.
(Edit: To clarify, you can customize layouts separately for iOS and Android in Neonto Studio.)
For a random example, look at Periscope's new Android version -- the differences from the iOS version are minor, yet it fits in nicely on Lollipop: http://www.theverge.com/2015/5/26/8657349/periscope-android-...
As for the "I sincerely hope you fail" part: we're a startup, so we're likely going to fail anyway. Thanks for the honest sentiment, I guess.
A word on Windows 10, mobile or otherwise. It is indeed a mess, with almost no coherent design language, something that Phone 7, Phone 8 and Windows 8 actually had, for better or worse. Windows 10 throws many of the good design choices for a faux Android look, and a very bad one at that due to complete lack of consistency. Android also lacks consistency throughout, but at least a somewhat coherent design language exists now.
I do not wish to argue here. Do not take my wishes personally. As someone who wishes to only see good technology succeed, and I do not see this as good technology. I do not wish personal failure to anyone individual, and wish you personally all the best.
Notifications are completely different on iOS and Android. Sharing data between apps is completely different. Wearables are different. Communicating with a server is different. Accessing contacts is different, as is accessing the camera. Sensors are different, and often differ between Android models.
Most of the big mobile success stories we've seen in the past 5 years have come from people utilizing the unique features of the phone, not treating it like a 5-inch dumb terminal.
That is a thing of the past. At the current rate of smartphone/phablet specs growth the differences with desktop are laughable (you can currently get 64bit octacore@1.7Ghz mobile devices with 3Gb of RAM for around $100) [0]. And this will only continue to grow. 16core and 32cores will be here in 2-3 years [1].
IMO, hybrid apps are already the present. The difficult times when we didn't have the required performance in our pockets are long gone... and frameworks like Ionic are really convenient for certain use cases.
> browser differences between devices (even Android devices with the same base OS can have very different web view browser engines)
That has been already solved with xwalk [2]... but again, this will be irrelevant in a couple of years.
[0] http://www.gearbest.com/cell-phones/pp_152602.html
[1] http://www.xbitlabs.com/news/cpu/display/20130304235830_Pres...
[2] https://crosswalk-project.org/
Plenty of websites doing advanced html5 gunk bring top of the line systems to their knees.
Are they native? No, they're JS apps
Do the users care? No, cos they do the "job" pretty well
We're reaching that computing power with mobile devices. In fact current mobiles are like desktops of 3/4 years ago. For certain kind of apps it won't matter if they're built with web technologies. (I'm not saying that you should bet on WebGL vs OpenGLES)
It's all about the use case.
Unfortunately lots of websites and web apps are not very well developed. They serve bloated HTML that hasn't been minified, let alone compressed. The page is unresponsive or blank until a dozen JavaScript files have been loaded. Hardly anything is cached. jQuery is loaded to do select a single element and animate it when CSS would have done.
Most well written, architectured and developed web[site|app]s will not be too different in UX for end users than a native app. Sure, you can't write a great 60 fps first person shooter game for the web, but there's nothing saying you shouldn't be able to create an RSS reader or photo sharing app or social network or anything else with either the web or native.
you can, you know WebGL is hardware accelerated and there is Asm.js - even the Unreal game engine runs in Firefox and Chrome.
But a lot of games do run quite well using WebGL. Just not the jaw-droppingly realistic ones.
Thanks! <3
There is nothing to concede or regret about. It's just how things evolve. Get over it.
Agreed. I was just watching this talk the other day called 'Making web apps appy' froom Chrome Dev Summit: https://www.youtube.com/watch?v=QbuLq4f6DGQ
It talks about a lot of new incoming features, like push notifications from the browser, adding icons to home screen directly, offline access, etc.
As someone has written on his tweeter account "Web APIs are hipster RPCs".
Actually, most frameworks don't work around anything.
Terrible ones at that. In native applications you can bypass abstraction layers when you need it. In a browser you are restricted to a almost comically crippled version of what any native APIs provide.
Look at the <canvas> API. It's fairly modern, and yet I can't even turn off premultiplied colors, which I would need for doing even semi-decent image processing.
server sockets? udp? no dice.
even the most primitive file management? with the file API i can open individal files now. But can I grant a website access to some cordoned-off subtree of the filesystem? No. Which in turn gives rise to "store everything in the cloud" mentality, because there are no alternatives.
What are those? If you're talking about alpha, that can be bypassed.
> server sockets? udp? no dice.
The web platform doesn't allow protocols which bypass its security model, sure. But you do have other ways to communicate, WebSocket (over TCP) and WebRTC (over UDP).
> But can I grant a website access to some cordoned-off subtree of the filesystem?
Not yet, but you do have your own filesystem.
which brings us back to the crippled versions of the native APIs.
I whish this phrase would die and be replaced by bad "teams" produce bad software. I have worked on some projects with fantastic developers, but awful or no UX, or a misguided vision, rushed to market etc etc.
I have also worked on projects with awful awful code base but the end product is actually alright (so long as it doesn’t need any maintenance).
Perhaps we should flip it on it's head and say, "good technology doesn't guarantee good software".
When a group of individuals takes such a strong position and they are proven to be wrong, I personally think some crow eating is due :-)
Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now.
It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.
The first site I ever saw that used Javascript to produce a useful application rather than annoying frippery was Google Maps.
(Rhetorical question: why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces)
Two reasons: Bandwidth and Speed. Google has contracts with most major ISP's for caching Youtube videos. This gives them access to the best CDN money can buy! No matter how awesome or powerful your current datacenter/CDN is, it still wouldn't be able to match the fetch-straight-from-the-ISP performance. Interestingly this also creates a hidden monopoly since the barrier to entry is costly.
Flash DRM replaced with another closed source DRM. No progress whatsoever. And now it has embedded in the browser itself, greatly increasing its vulnerability.
What exactly is incredible about YouTube today (apart from it being a huge repository of videos, of course)?
That it almost works like a 2000 era video player, only slower and clunkier? The new fangled DRM? That it can bring a decent computer to its knees with the fans blaring playing HD video? The automatic non-skippable ads?
YouTube is about as proven as you can get. The fact is that it didn't just edge past 2000-era video players in popularity, it totally trounced them. I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.
How many people watch movies on YouTube? Because that's what video players are used for, not for small videos, music clips and curios.
>I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.
We were talking about it's performance compared to native, not it's viability.
YouTube rules as a huge video repository. Other "web" apps that don't have that stronghold, don't fare so well compared to their native counterparts, especially on mobile.
What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound. If you have a Chromecast, you can display the video on your TV instead.
Nothing in 2000 had a remotely similar feature set.
Nothing about this is "web" specific. That's just "streaming over the internet" as you said. Lots of native apps do it too (for both music and video, internet radio, iTunes video rentals, etc.). The reason we didn't have this as widespread before was limited bandwidth connections (a limitation of internet, not of being native).
>You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound. If you have a Chromecast, you can display the video on your TV instead. Nothing in 2000 had a remotely similar feature set
Again, nothing about what you describe is web specific. Native can do it all and do it better and with less battery crippling cpu usage.
And nothing described -instant seek, pitch shifting with retime, etc- was impossible in native video players in 2000 (or even 1995), while all of it was impossible for the web in 2000.
Which also means things possible for native apps now are impossible for web apps now, which makes sense since native is a superset of what functionality is available in a web sandbox, and with faster potential speed. (And of course being web is not a requirement for accessing internet resources).
Moving the goalposts. You were saying that YouTube is a slower and clunkier version of a 2000 native app. Now you're comparing 2015 native vs web.
> native is a superset of what functionality is available in a web sandbox
Web sandboxes have a killer advantage over native: no install.
And if we're talking about native desktop, there's another killer advantage of the web: you don't have to trust the app.
You said: "Nothing in 2000 had a remotely similar feature set."
Not that Winamp 3 (released in 2002) was a svelte piece of software[0], but it could do realtime pitch/speed shifting and stream audio and video from the Internet. With a sufficiently fast connection, three seconds from link click to video stream start would be quite doable.
Streaming and decoding audio and video isn't anything new. The two new things that The Web brings us are "zero-install" and a the benefits of the large amount of sandboxing work that's been put into the major browsers.
[0] WA3 was slow because of the UI code, not because of the media stream and decode code. :)
Fans blaring haha
And yet any media player beats it at its core functionality: video playback.
Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer. There even are addons to export YT playlists to VLC and stream them.
pdfjs is great. but every 3rd scientific paper I read tends to be somewhat broken (missing diagrams/images) or sometimes fails to render completely. native readers provide a better experience and better render times.
>And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try.
Maybe sometimes it would be better to provide better integration with native applications?
Native applications and browsers really don't like talking to each other.
That's it exactly. The author claims it's an unsolved problem, I think it's the inevitable solution (that web and native will merge).
web and native will eventually merge to the point that for most intents and purposes the user can't distinguish between them. It'll never be perfect, but it'll be "good enough", that whether an app comes from the web or from the HD, the user won't really notice except perhaps in the initial startup time, and probably not even then (everyone expects to "install" an app).
how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ?
For sharing that would be sufficient.
Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a superior platform for monetizing things, not necessarily a superior platform as far as user-experience goes.
> The other key piece is discoverability, and on that front, YouTube is far, far better
I'll give you that one.
But then again there are dedicated media-discovery-sites (imdb, last.fm) that do not have playback as their core functionality, even though they may offer some playback.
No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite.
I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible. Much lesser control on ad-blocking too, and really the ads on YT are sometimes seriously irritating.
[1] Evidence: https://twitter.com/marvindanig/status/598701509963083777
Evidence: ^
Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to is often much more complex than a single raw file.
you want to share youtube comments with people? they are a significant value-add to you?
And here I'd concluded the comments section existed to allow pre-teens to practice their ability to make racist remarks.
Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).
And even with the URL alone, that's still significantly less opaque than YouTube's current method of https://youtube.com/$some_random_gibberish. At least someone could see something like https://mytube.com/j_random_hacker/how_to_computer.mp4 and guess that "j_random_hacker" is a username and "how_to_computer.mp4" is a video uploaded by that user.
This isn't much different from, say, reddit, where URLs are actually part of normal discussion; a redditor will talk about a subreddit called "/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly referencing paths (to https:/reddit.com/r/mylittlepony and https://reddit.com/u/Unidan, respectively). Granted, reddit's userbase is somewhat more tech-savvy on average than, say, Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to typical users, and it's certainly not hard to even manually demonstrate such things to new users.
This also isn't much different from many (most?) news sites, which provide URLs that resemble the name of the article (with some adjustment to make everything lowercase, turn spaces into underscores, strip or substitute special characters, etc.).
Like a web browser?
There's no reason why a native app can't do this - in fact, many native apps for things like YouTube and Pandora and such already do this.
They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.
If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.
And yet it's existed for years using p2p/torrents. So they're more like business fictions
The "4th option" is that you've got the causality completely backwards in your head: it just happens to be the case that the cultures where distributed tooling became important were the ones where it was necessary to promote an "all information is free" mindset, not that it's necessarily a part of distributed tooling that you take that mindset.
If we start with a centralized metadata server/peer tracker, a set of "base seeds" to keep videos alive, and a commenting system, we can still revoke access to individual videos (our app will simply not support peer discovery except through our tracker, we take down the seeds, comments, and tracker entry on a revocation) while distributing bandwidth for the viral videos that need it.
The point is germane.
Not at all, YT solved it many years ago with ContentID.
Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.
Sorry, there is some ambiguity in English about this. I am regarding a "solved problem" as a "problem" (i.e. classification) whereas you are regarding it as "no longer a problem" (i.e. interface). Yes, right now YouTube's interaction with the problem is highly limited (though not nonexistent), but if one is, say, trying to disrupt YouTube or talk about YouTube's history, one still classifies it as a problem in general that exists within YouTube's problem domain.
> Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.
I mean, I agree that it helps that particular problem somewhat to have a cross-platform virtual machine (the browser) and to distribute an executable (your JS app) on that machine rather than (or sometimes alongside) your content. This also creates its own problems, of course, like simpler browsers (spiders, text-only browsers) not being compatible with your website, as well as some new buggy issues when, say, the JS doesn't load properly. But HTML+CSS+JS is not new in this town and the cemetery has some gravestones -- like the fact that there aren't many desktop Java applications, the complete failure of the Java browser plugin, and the waning of the Flash plugin. It is peculiar among these only because its dreams are less lofty: not "write once run everywhere" but "write once, then write a (hopefully graceful) downgrade path if they do not support the features that I want to use."
I'm not sure I understand. AFAIK youtube currently makes money (from ads) and much of what people view is copyrighted music that isn't properly licensed, and which yt doesn't pay for.
Sure, some, music is taken off yt, and some content is properly licensed -- but are you seriously claiming that yt isn't (any more) making money from copyright infringement?
There's some digital content distributed via p2p legally -- and it'd not be a stretch that yt owes it's current market dominance to "flaunting copyright law" as the copyright lobby might put it.
If one relegated content (video, meta-data, comments) to torrents/magnet-links (there is an issue of loops in the links in content-addressed systems -- but with a pretty modest central server (cluster) serving up a few lists of magnet-links should be affordable)) -- I think it would be quite feasible to distribute digital media in way which the consumers shared in the meagre cost of distribution through mostly donating bandwidth.
Well said, you should tell this to Disney, MPAA, and MAFIAA so they'll stop trampling the rights of the commons by extending the length of copyrights everytime something profitable to them is about to expire. https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act
Well, if I click on the first link, a video doesn't play (that would be the case even if the link were to an actual MKV video). The second URL isn't even a hyperlink on news.ycombinator.com. But if I click on a valid YouTube link, a video plays nearly immediately.
If I could stream directly to VLC or a player of my choice I'd be happy with that.
It was a nightmare. Each media player would try to hijack every link type it knew about each time it ran. But there wasn't full compatibility. So you'd click a link, RealPlayer would try to open it, and the player would crash.
The major players actively fought open standards, because they each had dreams of controlling a DRM & patent gated empire.
Flash brought some sanity to web video. Although initially it had performance issues (it had issues with hardware overlays on some video hardware).
With that said, I'd be more optimistic of a kind of "media plugin renaissance" like what's being discussed in this day and age than I would be back in the 90's, what with all the insistence on standards-compliance and all that jazz. Eventually, with platforms like the .NET CLR / Mono catching on and becoming increasingly popular for cross-platform "native" (not quite native, but much more native than web-based) development, the chance of successfully reaching the goal that Java tried (and - arguably - failed) to reach back in the 90's is much higher nowadays.
Simple playback of video? Not so bad. But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'? YouTube-like annotations? Show suggested videos after? Developers aren't going to want to support all environment configurations, so you'd likely end up with a separate supported player for each website.. which doesn't sound better than visiting a webapp tested against the popular web browsers.
Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
This sounds like something that should be a feature of the protocol used for streaming (in fact, I'd be surprised if most streaming protocols didn't support such functionality). Even without, this should be possible to do even with a native media player, and many streaming providers offer streams with different bitrates and encodings and such (for an example, check out soma.fm).
> YouTube-like annotations?
Most video players have subtitle and even captioning support; it shouldn't be hard to extend this to arbitrary annotations, be it as part of the streaming protocol, part of the media encoding, or even as a separate stream or file.
> Show suggested videos after?
Could be hypothetically done with an API call on the player's part to the video source (or some other source that indexes videos), which then provides the list. The player could then display said suggestions.
All three of these things could be worked around with a standard "metadata" path that such a video player would access and fetch an HTML page or JSON/XML document or somesuch.
> Developers aren't going to want to support all environment configurations
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0. I don't use separate web browsers for different websites, after all.
> Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
Part of the issue is that operating-system-level sandboxing has historically been insufficient. Bringing some modern server-grade sandboxing techniques (containers, VMs, chroots, etc.) to the desktop and mobile realms in an easy-to-use manner would alleviate the need for browsers to try and implement this themselves.
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0.
There are web standards now, but, in practice, when you're supporting multiple environments, you're also testing against them. For webapps, fortunately, this usually just entails testing the top 5 browsers for a few versions, and mobile devices if you support them.
If the user comes to support saying something is broken with the video on their native app, trying to troubleshoot their native environment can be difficult, and telling them that their environment might be configured wrong often doesn't solve their problem. Which is why I suspect each site would support specific players.. not being a real improvement over the Gecko or WebKit <video>, <audio> in my mind..
Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can register for this Intent and the user will be prompted for what program they wish to handle the link in. This is how the official YouTube/Google Maps/G+ apps work.
It turns out that for certain types of content, users really, really don't like to wait for external programs to load. It's not a technology issue; the technology has long existed to use rich clients, consumers just don't prefer it.
And yet they click through full page ads, wait for "loading showcase" animations, scroll past parallax scrolling banner images and also wait for the ads on youtube videos and for the video to switch from 360p to HD.
Users are strange creatures.
I think if some effort were put into streamlining the native <-> web boundary then users would be quite happy with it.
> This is how the official YouTube/Google Maps/G+ apps work.
The question is, could this be standardized further? Basically a web standard that browsers agree to when it comes to talking to native apps that might offer specific services.
At the risk of getting stoned to death for this: WebD-Bus?
Although I think anything like that isn't going to happen. Browser vendors put security over everything else. Talking to native apps which already have access to the system would probably be construed as some sort of security risk, even if the user had to opt-in.
As for the last point, Spotify has some version of this. My native (mobile) Spotify app knows when I'm playing on my computer and vice-versa.
I'm not sure how that's a valid point. My native media player loads in literally less than a second. (I timed it at 0.59s from when I double-click a file and it starts playback.) This is faster than any webpage can ever dream of loading. And unlike Flash or HTML5 video it gives me completely hitch free playback, whereas browser integrated player tend to drop frames quite frequently.
I would much rather use it than any player integrated into a web browser.
https://www.reddit.com/r/WatchPeopleCode/comments/3273es/pro...
It wouldn't be hard to make that work on other sites that have a flash player. But we aren't quite sure if it improved the performance or anything, it just felt right.
If you open an .mp4 file in Firefox you can set it to open in an application through your "Applications" settings. By default it prompts "Open with..." or "Save as..." in a dialogue.
If you open a direct link to a video you can open it to play in VLC (or player of your choice).
http://en.wikipedia.org/wiki/Google_Videos#Google_Video_Play...
The same disappointment hit me with the early releases of Chrome browser - just Firefox with stuff removed.
I seem to remember being able to do that two decades ago. I imagine you still can (assuming you're up-to-speed with the configuration UI of the week for your browser), but it's not something people seem to do a lot.
What about URLs mean that a native player can't use them?
Synchronized play state and playlists on all the devices. Offline handling of the media files with streaming as an option. Feed subscription but also podcast repository and ranking/trending screens.
All media files are by definition in independant feeds, and sharing a file URL is supported.
It brings a hugely better experience than youtube pr any online video service I've seen. I actually switched to my podcast player all the youtube channels that also have a separate feed.
I'm always baffled by the suggestions when watching videos from some common series. There would be mostly accurate suggestions, and consistently two or three videos completely unrelated taken from my viewing history. For instance there would be 'Howto repair your dishwasher' in the middle of all the videos of a math channel.
I tend to massively subscribe to channels and watch in batches, so I have (and want to have) a very good idea of what's coming next in my queue.
The only reason youtube is better on that front is because google.
And at it's core, BetMax is better than VHS. HD-DVD is better than Blu-Ray.
Often, it's not about what is "better". It's about who has the most moment, is easier, less encumbered by DRM, etc.
Sometimes it's better to download Youtube... more often than not, Youtube "just works".
Actually this is exact reverse of a Betamax story - better and more expensive long term improvement won over short term and cheaper one.
Do you report these? It's been ages since I saw a PDF that pdf.js misrendered.
Remember, on the web, you are the product.
The same goes for many other things:
- Movie theatres in the last few years (commercials before movies)
- Television since the days of black-and-white TVs.
- Radio dramas "sponsored by X" before TVs existed.
How has anything changed?
This is what I use instead: mplayer -fixed-vo $( youtube-dl -gf mp4 $* "$link" )
If you have the HTML player enabled, and if your GPU supports hardware H.264 decoding (most do these days), this plugin may help:
https://github.com/erkserkserks/h264ify
Otherwise Youtube might send VP8, which your CPU has to decode.
That isn't its core functionally, it's a social video sharing site, not a video playback site. It's core functionality is social sharing and all that goes with that, comments, related videos, channels, etc.
I would argue YouTube's core functionality is "making it easy to share videos with family, friends, and the world". Allowing playback of the videos on the page makes this functionality easier.
>Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer.
I do this too - although only because an addon I have causes Firefox to memleak if I leave a YouTube tab open too long. Rather than finding the problem and fixing it - I download a video I want to watch and close the YouTube tab. Honestly my video player of choice (MPC-HC) does exactly what the YouTube player does. It plays the video. Not a whole lot of bells and whistles needed to do that.
Examples of this hampering is that they only stream 20sec ahead instead of the whole clip in one shot. There are many other annoyances like this, like not giving you the HD version even though it says the video is HD and you've selected HD, or when it re-streams the movie when you switch from windowed to fullscreen, probably because the windowed version was too low quality.
Related to that, if you try to scrub to a position BEFORE what you are watching right now (say, 1 minute before), which is obviously buffered since you have just watched it, it goes full loading-retard again. It's like it just throws away the data it buffered and showed you. It is insanely infuriating.
https://rpetri.ch/cydia/videopane/
But can you build a democratic 24/7 music/video feed with a native video playback app? Maybe, but it is much easier with the web. And it has already been done:
http://botwillacceptanything.com:3000/video
https://github.com/botwillacceptanything/botwillacceptanythi...
I invite anyone with the time and inclination to submit a pull request that changes the content of the video feed.
But the interesting thing to me is what happens when we move past the existential despair that comes when we first recognize the true nature of things. Sure, things are fucked, but they always have been. What's next?
When I was as bitter as you sound here, I took a break. Burnout sucks. But eventually I found myself coming back to technology because it's my best chance to make the world suck slightly less. Or, put more accurately, to shift it in the direction of my irrationally high ideals.
So maybe take a break? Go hike the Pacific Crest Trail or work on a goat farm or something. You're not going to help anybody, yourself included, by soaking in something you hate indiscriminately. At least rest until you can come back and focus your hate in a laser-like beam on one particularly awful thing.
[1] http://en.wikipedia.org/wiki/Future_of_the_Earth
You do not have to learn a new framework to do things on the web. The browsers all seem to support stuff that's worked for years.
The problem is that web developers feel the need to learn new things because they fear getting out of date. "oh, dude, I learned React this weekend. It's hot stuff! You need to learn this."
No, you really don't. You have a plethera of choices, and one of those choices is to rock it like it's 1999.
Otherwise, there's an extent to which you have to accommodate the absolutely rampant fetishization of current fashion for How We Do Things Now Because It's Better(TM) so you can sell yourself properly.
In more concrete terms: right now if you're looking for a gig as a front-end dev, you're going to have a much easier time finding a job if you can put Angular and React on your resume. The fact that this isn't particularly rational (or fair) as a hiring filter doesn't really matter.
If you're good at web development... that means you understand HTML, CSS, and JavaScript and you understand them at the level you should if you want to call yourself a web developer, then learning whatever framework a hiring manager wants you to know this week is trivial because you understand how the web works.
The problem is a lot of people just learn Angular for a gig. Then they leave 12-18 months later and go learn something else. It's never enough time to actually get good at anything.
And let me tell you... the hiring managers are taking instructions from development teams looking for talent. Those teams often inform management what is the hot new tech that needs to be used. But none of these things that people think they need to know have been so battle-tested yet that they are for sure the "next big thing."
I think experimenting is great. I don't think developers should worry themselves to death over having to keep up with whatever's new this week. I think devs would be better off investing that time in getting really great at the web. Really learn what semantic markup is. Really understand floats, clears, various display types. Really understand the fact that the web, without any JS or CSS, works great on mobile, because when it started, screens were 640px wide, and as a gang of developers, we've layered on boatloads of code to make it not responsive, only to make it responsive again. :)
And then, I believe everyone will be in a much better position to make informed decisions on whether or not "hot new thing this week" is really worth learning.
But what do I know?
Trust me -
Perhaps where we part ways is on the question of whether the industry leans towards sensible agreement. My impression is that it doesn't.
At the same time, i can't imagine how hellish it would be to work for a company that always wants to use the latest technology -- the framework market seems saturated to me, and I would wager it's probably better for a company to find a few technologies and stick to them, tackling problems/weak points as they arise and brewing custom solutions for those if necessary. Having to stop and shift over to a new framework every now and then seems like it would be a massive productivity hit.
I also don't like it when a framework becomes a crutch. Though I don't think that happens too often for most people.
I've also run into the heavy weight problem -- there have been a few instance where I've wanted to create something simple, and in most cases using a framework in that situation becomes the very definition of over kill. So instead I'll usually just write a simple php script or something to do whatever I need to get done, but even that feels a bit unnecessary. While I'm not sure if javascript should be elevated to all the use cases it has been recently, I do think it should be a language that enables a developer to natively(that is to say, w/o a framework) handle any simple functionality that might be expected for a site that is just a little bit fancier than a static site, so handling very simple data such as bare-bones blog or a simple mailing system. While it is getting there you still can't do something like write a simple form based mailer in pure js as far as I know, you can only open the client's native mailing app. You'd have to write a single php file or some other mechanism for that simple purpose.
But yeah, it seems like bloat is a tricky thing to avoid these days, especially since frameworks are the easiest, usually most error proof, and quickest way to get your website full of some modern bells and whistles, when in reality you may only be putting half of the technologies features to use.
The article says exactly that! It just says we shouldn't shoehorn native stuff into the web (e.g look at Synology's UI mimicking a nested desktop and windows).
> We shouldn’t try to compete with native apps in terms set by the native apps. Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.
Youtube example perfectly fits that bill.
Yet there is also a critical difference to be made between "the web" and "web technology": while the former is operated in a browser, platforms such as Electron leading to apps such as Atom or Slack that totally don't try to mimic the native platform they're running on, powering cross-platform applications that nonetheless do try hard to respect† the platform they're running on, achieving something Java's cross-platform WORA GUI toolkit thoroughly failed to††.
† there's a clear, visible boundary between the native system and the webtech app, but that boundary is easily crossed, whereas historically we've been trying to erase the boundary and pretend it doesn't exist, only to veer straight into an uncanny valley.
†† dare I say Firefox sits right there too, forever battling the tide of mimicking native components with each OS release, from UI elements appearance (vanishing scrollbar, input fields...) to behaviour (non-"sheet" modal windows on OS X), in subtle but aggravating ways, if only because it erodes the product's image and detracts development resources from other efforts.
https://www.youtube.com/tv
Video player functionality aside (I understand the complaints), that thing full-screened just feels like a native app.
You mean when they were using silverlight or now when they are using HTML5?
Is it only for mobile? I didn't see any "mob" or something in the URL. Anyway, with regards to being indistinguishable from native, I guess there is nothing quite like being reminded that you are "native" than an app complaining that you are on the wrong native device. :-)
In Firefox (my default br.) the message is: "Youtube on TV is not supported on this device, for more info go to: www.youtube.com/devicepartners" which is unclickable and unselectable. Modern web...
I get full <video> playback capability in FF nightly on windows and linux
Over the chain of ownership of any website I would say starting out trying to mimic a native experience will inevitably lead to a bad UX. Maybe not at first but it will. Part of the reason I use HN as a web site on my phone/tab is because it doesn't try to get fancy and just gives me a great web experience. Shocker.
MPlayer can kick the pants off of YouTube in some contexts. Likewise, MPlayer wouldn't be viable for a vast number of YouTube use cases.
I can benefit tremendously from using both Audacity and SoundCloud. Why does one have to "win?"
I think the problem is the hype about native apps and everyone wanting an app without understanding their purposes, utility, and unique characteristics. There are situations where a web app / site is the exceedingly more appropriate solution, but there are other uses where a native app is equally exceedingly more appropriate. The problem is that people are having a difficult time discerning the two and the appropriateness of each.
I don't agree with this article and the sentiment about the critical question being whether people want your icon on their homescreen as being the differentiating characteristic. What is not discussed is the possibility for putting the icon on the home screen as a link to a web view that can function the way a native app can function. It even addresses a question regarding distribution if you simply ask your user whether they want to "install" or add an icon to their homescreen to install your "app" / web app / site. It can be designed in such a fashion that it is indistinguishable from a native app of a certain type that has rather narrow requirements.
I think the future of remote web-like apps lies in something like QML[0]. A completely native UI with full access to the desktop widget suite can be downloaded in QML in a few kilobytes. Stick a browser like loader on the front of it, and provide a decent (seamless) asynchronous RPC, and you've got yourself a replacement.
[0] http://doc.qt.io/qt-5/qmlapplications.html
The web platform wants to have powerful features that are dangerous and/or easy to abuse, but haven't found a good way to allow them safely.
The "solution" we've settled for is to blame the user for clicking "OK" on permission prompts that have unclear consequences to non-technical users.
The Free Web can't do that (and I strongly prefer it to remain Free with low barrier to entry), so it needs a better approach, or needs to give up on having dangerous features available.
The same problem exists on native.
I'd prefer the Web to stay safe and hassle-free, and use native apps—with the risk of letting malware in—only when I really need more powerful features.
Let data be data. Let features be features. And let user interfaces be user interface. So many websites mess this up in order to deliver a quick working site that only works on the desktop and sometimes only Windows. And now we have sites making seperate ghetto mobile versions or mobile apps missing features. We still have data that can't be accessed through URL with text that can't be selected or shown without JavaScript loaded.
Unless you are doing something more complicated than content devilery (ie games or utility apps) there is no reason to override fundamental features of the web.
But I don't think the solution is to give up. Native apps are great, but there's a vast gulf between the binary running on your device and the server you got it from. Downloading and updating take forever. Connecting to other apps is barely possible. Everything is horribly siloed. The brilliance of the web is that it allows people to quickly connect to computers anywhere in the world and get at whatever stuff they might want to serve; native apps will never have that level of flexibility, barring some horrible proprietary ecosystem.
Unfortunately, the web was designed primarily with content in mind, not presentation. The only way servers can provide interesting and slick user experiences is to hack up the content presentation system, which is as silly as using spreadsheet scripting to build enterprise software.
So I think the best approach would be to revisit the design of the web. Instead of having the web be strictly document-centric, I think there should be a higher level above that, through which HTML, CSS, the DOM, and everything else are implemented. A sandboxed, scriptable, low-level canvas that only gives you the bare essentials, allowing you to create native-quality experiences without having to piggyback on the DOM or reinvent the universe via canvas or WebGL. A "Vulkan" equivalent for web software. Not making a document? Feel free to not use HTML — or only embed it in the parts of your web-app that actually present content.
It should be possible for a user to go to facebook.com and immediately retrieve an equivalent to the Facebook app in their browser — smooth scrolling, gestures, and everything. (Or whatever the future equivalent of a browser might be.) But if a user navigates to a simple blog, it should still appear as it does in the web today, because this new web would be a superset of today's web.
We've been interacting with other computers through a seriously constrained pipeline this past decade. Instead of bowing our heads and conceding defeat, why not blow it wide open?
You might argue that canvas and WebGL nodes in the DOM already serve this role, but I disagree. In their current form, these nodes exist inside the document-based world of the web rather than containing it, an inversion of what I see as the proper hierarchy. This arrangement poses a number of problems for designing rich apps, including very poor performance related to content reflow. Some companies[1] are trying to fix this by manually doing all their rendering inside canvas and re-implementing HTML and CSS along the way. Unfortunately, this is a ton of work and results in a web experience that is non-standard in many ways, including for things like accessibility and text selection. The fact that this actually does work to significantly improve the user experience, however, points to the fact that something needs to drastically change for the web to remain healthy, useful, and relevant.
My understanding is that the DOM is already implemented as a series of texture-backed views in many browsers. That would still remain the same — nobody would have to reimplement this functionality. I just think it would be a great idea for us to be able to use those same texture-backed views for custom UI unrelated to HTML and CSS, and to separate the rendering concerns of text and document flow from the design of user interfaces.
[1]: https://news.ycombinator.com/item?id=9029159
Web apps don't try to recreate the native UI anymore - something that used to be the case some years ago in the iOS1-6 era. Nowadays the UI of Android 5+, iOS 7+ and WinPhone7+ look very simple and Web-alike.
Simply avoid bloated outdated big JS libraries and use a minifier to shrink the JS and CSS files.
I thought the trend reversed as many little commerce switched from offering a Android/iOS app to a mobile-friendly website. This may not be a global trend.
quirksmode.org used to be great resource in the IE6 era. Nowadays http://caniuse.com and Mozilla's MDN have replaced it completely for me as it offers up-to-date information.
Actually I think they're doing pretty good with that.
Additionally how many of those laptops are actually running ChromeOS, instead of being replaced by a proper Linux distribution?
Looking at Germany, which was was I mentioned on my post, the scenario doesn't look like that anyway.
Yet somehow, users manage to navigate the web despite Apple's app store gatekeepers not setting policy. And really the debate about emulating native exists because of app store policy, not because the native standards are inherently better than what someone might invent left to their own devices...or even that they are necessarily better than the command line.