Hacker News new | past | comments | ask | show | jobs | submit login
Stop pushing the web forward (quirksmode.org)
569 points by mmahemoff on July 28, 2015 | hide | past | favorite | 299 comments

We need a break. We need an opportunity to learn to the features we already have responsibly — without tools! Also, we need the time for a fundamental conversation about where we want to push the web forward to.

How about this.. YOU take a break. Stop trying to keep up with every little new thing that comes out. Wait a while.

And you'll get exactly what you want.

The tools that it turns out were a bad idea will die. And those that are good will thrive.

And you'll get more time to learn the actually useful ones... and you'll get to learn from the mistakes others made early on.

Yes, you'll be a bit behind.. but you're apparently already ok with that anyway.

Do you know PPK and his work? He's been at the cutting edge of web-standards and implementations for at least 12 years if my memory serves me correctly.

>And you'll get exactly what you want. //

If he wants to avoid the web being badly negatively effected by short term views of current browser companies and standards bodies then he won't get what he wants by sticking his head in the sand and ignoring the direction he sees things going.

If this were the writing of a small time web-dev (like myself) then I think your comment would work; but I'm assuming PPK is coming from a position of experience that's given him an almost unique overview of the direction of browser and standards development vs. the historic "feel" and integrity of the web.

PPK is doing the equivalent of saying "let's stop and ask for directions [on our car journey]" and you're saying "no, let's just keep driving I'm sure we'll get to where we want to go".

He's up against it as, to my mind, cautious development doesn't serve the needs of corporations and so won't happen.

>"We’re pushing the web forward to emulate native more and more, but we can’t out-native native." (OP) //

I find it funny that web pages are trying to be native apps and many mobile apps are shipping when they're ostensibly just web pages.

tl;dr I think the OP has more to say, and that it's more important, than you're giving credit for.

> PPK is doing the equivalent of saying "let's stop and ask for directions [on our car journey]" and you're saying "no, let's just keep driving I'm sure we'll get to where we want to go".

Just because one person is lost doesn't mean everyone else in the vehicle is. Those who know where they are going don't need to stop and ask for directions. Don't force them to.

You have a valid point, not everyone is lost but obviously everyone seems to be digging in the same ship just for the sake of it. If you try to understand more of what OP is trying to say, then you will know that there are more problems created than solution.

It's getting more difficult for beginners to catch up or even were to start from (see lots of those questions on Quora), perhaps we need to reexamine things rather than building 4million cars a day only to realize we have global warming.

How did we go from Javascript to global warming?

Holding back technology so others can catch up is foolish. Where would we be if we followed that philosophy. We have long passed the ability of the human mind (at least unaugmented) to keep up with technology.

Sure, there are problems for some. But they are insignificant problems for others. I'm generally of the opinion that you should give people the freedom to choose rather than forcing things on them that are against their interest.

The fact that PPK did a lot of good work on web, doesnt mean this article is good. Any genius can create crapwork. So did albert einstein. I once saw a presentation from PPK where he proposed JSON over SMS....(http://quirksmode.org/presentations/Spring2012/bigm.pdf) IMHO that presentation was technically not very strong.

The post is neither good or bad. You just happen to disagree with the author.

I for one have been bitching (my colleagues know all about it) about the state of affairs in web dev for about year, and so far most people tend to agree. And my current project (mostly heavy Javascript) just reinforces that view, it's a total mess for little real gain.

>I once saw a presentation from PPK where he proposed JSON over SMS.

And that's bad because? Given some use cases it could be a very handy and pragmatic re-use of available resources and protocols.

because SMS has inherent costs in some countries, because SMSs are tiny (I'm pretty sure his example json structure was larger than a SMS max size even), there is already a mechanism in place (to see all SMSes), which would have to be hijacked (to not display what would be practically garbage to the end user)

push notifications already existed 3 years as a thing before this talk

Whatsapp, twitter, etc, all existed before this talk as mobile services (and twitter via a SMS interface, which is the far more reasonable way of using SMS uniformly across all phones)

It was a talk 3 years too late, data plans already existed, push services already existed, implementing such a thing via SMS would only lead a company to get ~6 months max use, wouldn't be as easy as other methods (receiving a push / making a web request, vs receiving a possibly fragmented SMS, and then having multiplatform hiding of this message), etc etc etc. I personally have to wonder if the talk was comedic (the part about how app stores make it impossible for people to find your app, makes me wonder this as well)

But the case that he is making in this post is strong.

> I find it funny that web pages are trying to be native apps and many mobile apps are shipping when they're ostensibly just web pages.

Which provides some insight into what's missing from the web. It's almost good enough for most companies. They just need a little something extra so that they can "own the experience." But soon the browsers will catch up and then websites will be able to own your experience, too.

What if I don't want corporations to own my experiences? An information-driven web with a document model is robust and can work with many different user agents. An experience-driven web with an application model is very fragile and will only be available to sighted, hearing, Mac-using people running a big 4 browser.

Funnily, iOS offers much better accessibility support than web. And I'd argue that many more apps use it (also Apple recently promoted apps with good accessibility support) compared to modern "web apps".

Who needs flash when we can have 15 competing application frameworks for the web that all just abuse the canvas as their medium, so we aren't even authoring HTML/CSS anymore?

Honest question: is abusing canvas really becoming prevalent? The only web app I've seen doing this is flipboard.

Prevalent? I don't know. I do think it's just a matter of time before some companies leverage this by providing a super simple web page developer tool a la Frontpage Extensions.

Photography studio webpage that just wants a carousel and music playing? Check.

Small companies that freak out about people stealing their inventory list? Check.

Vendor lock in for the poor souls that fall for this? CHECK.

Hmmm, maybe I'm naive, but I really don't see anything to suggest that things are headed this direction.

yeah I don't think that would be crawlable and we want seo

Then you're SOL, because web-delivered applications that own the experience will happen. Hopefully someone would come up with a better user-respecting user agent by then.

From a tech standpoint, yes. There are some pretty powerful interests that don't want to see the open web on mobile. Google and Apple get handsome cuts of all the revenue on their semi-closed platforms. Consumer demand may shift that, but I'm not holding my breath. The open web was an historical anomaly: historically the large information infrastructures have been nearly monopolized (telegraph, phone lines, cable/broadcast).

The web is an anomaly yes, but it has broader reach than any other platform in the history of mankind. Thinking that native apps will kill the web is to miss the forest for the trees. None of these proprietary platforms have the reach of the web. No computing device maker can release a credible device without web support. It doesn't matter how much money you have, you can't make your proprietary platform cross the chasm the web has crossed. Apple can't do it, even open-source Android can't do it, because Android is runtime, not a standard.

The common narrative of PC app -> Web app -> Mobile app is only superficially accurate in terms of where the tech hype was at different points. But in terms of long-term life cycles, mobile apps are much more like PC apps, and the web is something else completely different, which we've never seen before, and mark my words, it will not disappear or be superseded anytime soon.

the web is something else completely different, which we've never seen before, and mark my words, it will not disappear or be superseded anytime soon

Smalltalk environments?

That's the gist of it. The web is a file server protocol with a pseudo-Smalltalk coating.

We've seen hypertext systems in general many times before the web.

None that crossed the chasm. That's what makes the web special and unique, not the functionality.

The web ten years ago was indeed different when clean markup, separation of concerns, accessibility meant something. Nowadays it is just a mess, cannon fodder in the battle nobody asked for.

It "meant something" for a tiny fraction of web developers. The vast majority of developers in 2005 was probably either using Flash or creating something that only worked in IE (with its 85% usage share).

Yes, I totally miss the good ole' days of bitching about IE getting the CSS box model wrong, despite the fact that it was the better implementation and as soon as the standards gods deigned to bless us with 'border-box' everyone kind of pretended those threads on css-discuss never happened... Or endless bickering over the best unit to declare font-size in, because of course it made absolute sense to leave accessibility to site designers, not browser implementations... Or posturing over why 'float' was actually a valid layout concept for anything besides a block of paragraphs with images interspersed... Or the endless clearfix or image replacement hacks... Ahh yeah, the good ole' days...

Once again, what so special about mobile? Somehow I don't see webtech proponents rallying for wining the desktop or winning the smartwatches. This obsession with winning the mobile is plain stupid. Instead of wasting time implementing half-baked features which will never catch-up the native offerings and stuffing more crap into already multi-megabyte web pages how about doing some spring cleaning?

No they won't, because it would kill the web. That little bit is ownership: branding and control. There's no Adblock for their app. Their app isn't called Firefox it's Company Name. There's no dev tool for the app, so less chance to find out all the insecure ways it siphons my data. They control updates, so their ActiveX-style monstrosities are always going to be displayed the same. Get the idea?

Perhaps the choice lies outside of the actual functionality of the web itself but instead in the OS and browsers.

Consider someone who ships their iOS app that is basically just a web page instead of using a web page. For doing this, they get two benefits that are not really related to the web. One, they get an icon to tab from the home screen to launch their app, instead of going to Safari and then going to their webpage. Two, they get to avoid having to go through Safari, which one could speculate is something Apple was already wanting them to avoid as it allows Apple to create a better walled garden (not to say Apple is the only one who does this, I'm only pointing them out because I used iOS in my example).

How would a change/upgrade in web standards allow for the web app to compete with the iOS app housing a web app on these two fronts?

Just in case you're not aware, you can already make web apps in iOS have a icon on the home screen. See https://developer.apple.com/library/safari/documentation/App...

+1 thanks for that!

Does anyone have a link for something similar for Android phones?

HTM5 appcache to the rescue!


It's rad.

Rad is definitely not my experience.

I've spent A LOT of time trying to get my site's appcache functionality to the point where it's barely usable. Probably more time than all of its users would have spent downloading the resources it was supposed to cache. It has more gotchas than anything else I've ever experienced.

This is incredibly accurate: http://alistapart.com/article/application-cache-is-a-doucheb...

I really don't want them to "own the experience." I want their brochures to stay nicely sandboxed in a browser where they don't invade my computer and try to tell me what I can do with it.

Brochures are documents, nobody has a problem with putting documents on the web. Also, mobile apps are sandboxed already on all major platforms.

Right, I meant it as something of an insult. I'm fine with documents on the web. I'm fine with interactive documents on the web. I'm not fine with "web apps" that try to jump out of the browser, opening windows, redefining control-key sequences, breaking bookmarks, "open in new tab", and the back button, and otherwise interfering with my ability to control my own experience on the web.

I'm very familiar with PPK. I lifted my first 'getElementsByClassName' function directly from his site well over a decade ago. That doesn't mean that he hasn't descended into troll-level talking head status, generating controversy to drum up speaking appearances. Plus, we have MDN and caniuse.com now - he's irrelevant.

This is the part that feels the most misguided to me:

> a fundamental conversation about where we want to push the web forward to.

There's no such thing as a "conversation" between the billions of people with a stake in this. Or even the few million people building websites and web apps. Or even the few thousand people building web browsers. Attempting to have that conversation just means open-ended delay. There will never be a clear consensus on where we want to push the web forward to. And that's OK.

> There's no such thing as a "conversation" between the billions of people with a stake in this.

Well, not exactly. That's how you wind up getting diversity of fields.

People have different interests and different visions of the future. People understand computation differently. People approach the same problem in different ways. Through conversation and code, the web is weaved together.

My thought is this. Put up or shut up. Why waste your time under a forum about a developer who wants more stable, secure software? Surely this view provides some benefit to the community, lest we prefer languages that compute incorrectly with regularity and a proliferation of vulnerabilities across every domain that has been coupled with technology.

"Attempting to have that conversation just means open-ended delay."

Isn't that the point? To slow this down because perhaps the people driving "innovation" are insulated from its disruptive effects?

But people are conversing about it in browser dev groups and in standards meetings (WAI, WHATWG and whatever) and such; they're just doing it with a focus to their own ends rather than the ends of the more general user population of the web.

As it should be, those who do the work get to make the decisions, that's how it works. People work for their own self interest, not for the benefit of the "general user population".

>People work for their own self interest //

Altruism; not exclusively, not always, not all people work only for their own benefit.

Many, I warrant, consider that something as game-changing and all pervading as the web (and internet in general) should be tailored as much as we're able to the greater good of all people. Others want to make it illegal to collect rain for drinking in drought zones so they can get a better financial profit selling bottled water. And there's a whole scale in-between of course.

But the web and the Internet are not things themselves, those are merely abstract words that describe a collection of privately owned computers doing things their owners deem in their self interest. Anyone who talks about what the Web should be doesn't understand what the Web is nor what decentralized means. No one gets to say what it is, it simply is what those who build it make it.

By the way, one of the best websites I know, c2.com (I don't know anything about this consulting company, but these pages constantly come up in search results and offer best advice possible), manages to deliver the best content with HTMLs that mostly can be read in Mosaic and Lynx.

That's the original Wiki, by Ward Cunningham. He invented it. Currently read only, unfortunately, due to a hack last year.


Yeah, and now Ward's killing it in favour of some Web 2.0 thing I can't even begin to understand how to use.

Perhaps the most Web 1.0 place on the Internet, which I mean as a compliment. I don't quite get the revision/comment setup, but it's great.

Another proof that this whole web debate isn't going anywhere useful. Lot's of old places are full of amazing content. Maybe restricted communications channels allows for smarter conversations ? You have to tailor and curate the ideas. Mailing lists for instance are still used by real developers everywhere, IRC. Add a few blogs and old boards and you get 80%.

This works for the latest JavaScript framework, but is a lot more problematic when it comes to jamming fads into the browser: we have to support them, and work around them for a long long time.


Lots more than browser devs get hit by this. Crawler developers, screen-reader devs, browser plugin devs, mobile app devs, etc.

I do this. I don't even really think about anything new until others have put it through a shakedown for at least a year.

Choose your tools and frameworks judiciously, learn them well, and you will be much better off (and less stressed) than the folks who are continually chasing the latest thing.

While it is probably true that we "can't out-native native" the argument is irrelevant if you consider other more important factors.

The approval process is burdensome and discriminatory if you want to release an app that competes with Apple or goes against one of their policies.

For developers that want to create great mobile user interfaces and Apple won't approve the app, where does that leave us? No user experience or a sub-optimal user experience. If we do what PPK is proposing that leaves us with poor user experiences and maybe no user experience if we need a feature that is only available on native.

Having a web platform that can compete with native apps mitigates the problems and abuses common with companies that have monopolies. If they have competition they can't screw over their developers and user.

30% is an onerous tax. It's one thing if that is a marketing or referral fee. But if a developer is creating an app to use with their own platform / service they are most likely going to provide a download link from their site. They don't need any promotion or directory. Apple isn't providing any value. They are creating an artificial barrier and blocking other companies from serving their users just so they can get a cut of the action.

I've been using ES6 functionality like "yield" in my backend node.js code and am loving it. I would love to have that ability in the browser without having to go through a transpiler.

I want the web to keep pushing forward so that I can deliver better user experiences.

The argument that we need time to catch up and learn the technology seems ridiculous to me considering that the alternative is learning 3 platforms (web, iOS, Android) vs just 1 platform (web). A lot of developers don't want to have to develop for 3 different platforms.

If you can't keep up with all the technologies then become a monk and leave the technology world behind.

Nobody has been able to keep up with all the latest technology trends. Deal with it. Those that want to deliver better user experiences will invest the time to learn the new technologies.

Don't hold back progress just because you have a defeatist, why me, it's not fair, slow down guys, I can't keep up attitude.

> The tools that it turns out were a bad idea will die. And those that are good will thrive.

We saw that happen with WebSQL vs IndexedDB. A well-designed API (with a syntax every decent webdev knows) vs a bullshit spec (ohai callback hell FOR DOING A SIMPLE FUCKING SORT AND GROUP), and the bullshit won.

All because Microsoft wouldn't break down and embed SQLite into their browser like everyone else did for WebSQL. It's actually really disappointing.

IndexedDB could be built on top of WebSQL as a shim... you can't really do the reverse so easily. It's really disappointing... WebSQL/SQLite with a template string builder interface would be amazing. (I know it's an ES6 thing).

I will say, that I do want what's on deck for ES6/7 (2015/2016) to make it into the browsers... async/await is such a useful feature.

Because Microsoft and Mozilla wouldn't break down - and Mozilla already shipped SQLite.

Sorry, I had thought Mozilla had WebSQL with SQLite... I know chrome/safari supported it at least.. I thought MS was the main holdout there. It looks like there's a Firefox plugin for it though.

Hmm... would it be possible, using Promises, to create a sorta-shim, you give it a SQL query and a callback function.

The shim does asynchronously all the stuff a DB engine does (most people are going to use "SELECT cola,colb,colc FROM x WHERE foo=bar and baz=quux ORDER BY cola ASC GROUP BY colb" and nothing more complex anyway), then tracks all the stuff it needs to do in its own promise tracker. Once all is done, it assembles the returned row(s), stores them and calls the callback.

The biggest problem I see is locking as all the crap is async so you'd need some sort of locking and query ordering to maintain data consistency.

If you don't really need true locking pessimism it's more possible... There are actual SQL engines in JS though.

Using a single queue to run queries through would be relatively easy to do... a stage 1 analysis of what collections you need to query could then push the query into one of several queues for pipeline requests.

It would be interesting, but I don't mind IndexDB (or localStorage for that matter) enough to really bother with it.

It's not that simple.

1. The spec died, because it didn't get two independent implementations.

Everyone merely wrapped sqlite, which meant sites could rely on being bug-compatible with all the sqlite weirdnesses (e.g. column type "floating point" parses as integer column type), and making any future upgrades or fixes of sqlite a Web-wide version of pain of upgrading IE6 used for an intranet site.

2. IndexedDB API is a pain to use, because it's designed to be used directly. In the spirit of extensible web manifesto, it's a low-level primitive for JS libraries to build convenient higher-level abstractions on top of.

It's like an "assembly" of storage. It's supposed to enable building higher-level databases on top, so you can have SQL or NoSQL with whatever dialect you want, without burdening the platform with it. Use Dexie, localForage, ydn or such.

>How about this.. YOU take a break. Stop trying to keep up with every little new thing that comes out. Wait a while. And you'll get exactly what you want. The tools that it turns out were a bad idea will die. And those that are good will thrive.

Yeah, only hasn't ever happened. We still suffer from BS tools and ideas from late nineties, and we're only mostly piling stuff on top of it (some good and loads of crap).

Imagine that you and your friend are hiking together. After a while your friend says: you know what, I think we are going in the wrong direction. You tell him something similar to your comment. And yes, he waits. And while he waits you get deep into the swamp. The only think you learn is maybe how to hike in a swamp. Yes he left behind. But being left behind while others run deep into the swamp is not the worst that could happen. Alas, everyone lost some time.

This seems like just a bunch of excuses to keep breaking the web.

> But why do web developers want navigation transitions? In order to emulate native apps, of course.

If we're doing unpopular opinion time, I think this is the real issue that no one wants to talk about. I'm all for whatever feature development the community can standardize. Apple, google, mozilla, and etc. all have smart people working for them and when they cooperate things seem to work out fine. The problem is trying to achieve the feel of native applications in a _non_ native application. Browsers should do one thing well, but that one thing has no real business being duplication of mathematica, quake, or visual studio.

It's always interesting to see a Show HN where someone cleverly gets an approximation of one or another of those things running in the browser, but come on. Making the browser the operating system is simply going to push the same old incompatibility problems into the browser. It's not going to solve them.

I'm sorry but how would making browsers the operating system cause the incompatability problems to reappear? I think this is massively ignoring the realities:

- there's almost no native-feeling cross-platform UI library for native apps at the moment

- There's a standard for most things happening in a browser, which means that things look pixel-perfectly the same on a huge amount of browsers. Differences among current browsers are more among performance and experimental features

So currently, if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_.

The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.

>there's almost no native-feeling cross-platform UI library for native apps at the moment

Xamarin.Forms is the closest I can think of. Qt too, kind of.

>The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.

It's true, the browser succeeded as a working everywhere JVM equivalent.

It also succeeded at reimplementing half of your OS features, being another massive source of security issues, being inefficient with resources (chrome memory usage lol), having piss poor perfomance and locking everything to Javascript. Compiling to Javascript is not a solution. A proper bytecode is. Which we may have with WebAssembly as soon as it's implemented and the standard respected by browser builders (which will probably be around 2040). Until Google decides to add a new WA feature that's incompatible with other browsers because that's what Google does. Let's not get started on the fact that HTML is a terrible language for UIs and that any Javascript based solution is not a solution at all (i.e. React is still crap, as is Meteor and javascript.framework.of.the.day.js).

The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page.

> if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_.

1. We've been hoping to get at least TWO browser vendors to fully collaborate for the last 20 years and it has not happened. It won't happen.

2. Performance will still be crap.

3. I'd rather not get locked to Google's piss poor record of updating the stock Android browser. In fact, I'd rather not get locked to Google's piss poor software at all, thank you very much. The same argument applies to Apple and Microsoft. Safari is awful, and so is IE/Edge.

I get where your coming from, and agree with a lot of what you say.

BUT, Fundamentally...

>The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page.

Is just not a true statement. Or rather, the web sucks, but it is the only cross platform UI experiment that has 'worked' on any significant level.

> the only cross platform UI experiment that has 'worked' on any significant level.

Users do not care about cross-platform compatibility, at all. They only care that it works on their platform. As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc.

The only people who should be upset about cross-platform compatibility issues are budget-conscious managers and unfortunate OSS devs.

>As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc.

This is like saying "As construction workers we should be cheering for natural disasters, because there will be more work for construction workers to rebuild destroyed cities."

Job security is great- but at what cost? I'd rather see developers making completely new things than wasting time porting from one native platform to another.

And honestly, whether as a construction worker or a programmer, I, too, would rather be building new things than rebuilding the same goddamn thing over and over again.

What a hyperbolic analogy. No, porting to new platforms is not like recovering from a natural disaster, and rooting for competing platforms is not like cheering for the misery of a disaster.

And for the record, doing a port well (as opposed to a hacky, broken one) frequently requires lots of creativity and technical ingenuity.

> Users do not care about cross-platform compatibility, at all.

I've heard that some users have both a phone and a laptop.

No one has a laptop anymore. We're in the "post PC" era, haven't you heard?

Well, Java has succeeded, too. Look at Minecraft.

Minecraft has no meaningful UI; the entire window is just an OpenGL canvas.

The web has no meaningful UI. The entire window is just styled elements.

UI is not always about respecting the OS's guidelines/theme. Firefox, for example pretty much ignores everything since their Australis UI update and it is fine.

Look at Google Chrome. You can’t even use any <button> or <input> that looks natively in Chrome – it’s just as native as the old Swing styles.

Given that every other version of applications/oses changes the definition of what "native" looks like... I don't know that it's a huge problem...

Beyond that is the fact that Swing was fugly everywhere, and bootstrap looks decent everywhere.

Well, JavaFX’ styles look beautiful everywhere, too. (And it even uses decent XML and JS for styling and interaction).

I just argued against the parent poster, who said Java was different than browsers, because you could not make native UI.

Which you actually can very easily.

That was a fluke, and even Notch knows it.

Chrome has been the standard Android browser since KitKat, and it auto-updates since Lollipop. Ditto the system webview.

It's such a shame that there are still new Android 4.x devices being produced...

isn't 4.x kitkat? It's the 3.x devices that cause issues, and those are preeeeetty old.

4.4 is KitKat. 4.0 is ICS, 4.1-4.3 are Jellybean releases.

For native apps, anything Jellybean or better is reasonably easy to deal with (and ICS isn't that bad). But for webapps, the system webview was the horrible default Android browser up until KitKat, and didn't get auto-update until Lollipop. Android Browser has a number of outright bugs in its spec compliance (when I was developing for Google Search, we thought of it as the new IE6), and you lose any sort of GPU acceleration or fast JS engine that you might want for animations.

> Let's not get started on the fact that HTML is a terrible language for UIs

This is why I'm hoping that future web front-end frameworks will output UI elements to a <canvas> instead of the DOM.

If a DOM-like scene graph is needed, it should be managed entirely by the framework and simply be an intermediate layer between the application code and the <canvas>.

As a blind user and developer I am absolutely terrified by such a prospect. We've just started to get decent accessibility for the plethora of new web features with ARIA and similar. But if you render everything to graphics output directly to a canvas you lose any capability of ever talking to my screen reader. Text is awesome for both people and machines, let's not throw it out.

Hey, at least we'll get a bunch more mostly-pointless JavaScript features to support accessibility on canvases!

There's a standard for most things happening in a browser

There's POSIX, too. In practice, divergences are plentiful.

Differences among current browsers are more among performance and experimental features

The fact that are huge web tables meticulously documenting feature compatibilities across browsers implies differently.

Besides, a lot of web standards are done post-facto. I don't see the situation as being any better than POSIX. It might even be worse.

> There's POSIX

POSIX + a standard library for UI components + containerization + webassembly would be the "correct", cleanroom solution in my opinion.

If you want to build and run "native but untrusted" applications on the user's computer on heterogenous environments and can't anticipate which APIs someone is going to need next. Well then give them access to a walled-off part of the computer.

Same-origin policy? Replace it with a l7 firewall (+ some DNS security manifests?)

No cookies/local storage? That just means spinning up a new container every time the user visits.

No audio playback? Don't map the sound device into the container.


Sounds like you're really poorly reinventing Inferno. I don't even understand why you would need WebAssembly in this hypothetical scheme.

Container namespacing isn't fine-grained enough, and much of this is the result of traditional Unix-likes having large disparities between different ways of naming things that cannot be composed. The Spring solution was to have all of these descend from a name service, and the Plan 9/Inferno solution to have all resources be multiplexed into virtual file systems (i.e. one way of naming things).

Furthermore, the inclusion of containers here gives you a worst-of-both-worlds approach. You're not even detaching resource subsystems from a unit of execution's POV, you're cloning the entire OS namespace modulo disallowed subsystems for every unit of execution. That's a combinatorial explosion of the state space.

It also means complicated solutions to the problem of resource management and communication within and between containers, which is a problem when virtualization occurs at a too high level. In contrast, virtualization at the process/task level with OS-wide capabilities for single-system imaging and a heavily integrated subsystem for naming things (either a one true approach or a prototype-based one) means you can configure a system like it's a whole unit without sacrificing security.

Then it's not like POSIX is even that great. Why should a process be associated with one uid? Why can't I dynamically attach and remove capability tokens from processes while they're running, like the Hurd does it?

I'm not too fixated on posix + containers. It's just what I'm familiar with.

It's more about what the complex web applications are trying to do: Run in an isolated context, run compiled code from whatever language the developer preferred and utilize various low level features in ways that people didn't predict in advance.

Basically, what's irritating is that the web standards committees are trying to hand-craft poor knockoffs of lower level APIs, one at a time in ways that are incompatible / don't interoperate well with existing native software. I mean you can't even pipe data in/out of a tab if you wanted to.

Instead it might be better to look at already existing APIs that have been refined over years + some security namespacing.

I'm sure you can do better than the POSIX APIs, but I think it's hard to argue that POSIX APIs are better than the Web APIs. POSIX is a terrible API with decades of cruft.

web apis are incredibly restrictive, don't interoperate with native code at all and generally are a tiny subset of what native APIs provide.

Personally I prefer to put up with some cruft than not being able to do something at all.

POSIX is actually pretty horrible, if you look at the details. Guess what the "close" function does (hint: you can't use it to close a window or a sale). It requires the use of three-letter paths like /tmp.

(Related fact: While Windows is still as bad in that it gets its own things wrong, at least they weren't tied to POSIX's filesystem layout)

You're right, there's no native-feeling cross-platform UI library for native apps, and the browser isn't poised to be an exception to that. Apps made in the browser don't feel native. The closest to native-feeling app built in a browser that I can think of is Atom, which feels like a more sluggish version of Sublime (a Qt app). Neither of them feel as native as truly native apps do on their native platforms. Not nearly as native as Gedit on GNOME, Kate on KDE, Notepad++ on Windows or TextMate/BBedit on Mac.

And they never will because the native feel comes from paying close attention to the design language and behavior of your app with respect to the host platform. If a cross platform app really paid close enough attention to these things to make a difference, they may as well completely rewrite their UI layer on all platforms.

>there's almost no native-feeling cross-platform UI library for native apps at the moment

wxWidgets is native and it has been working for decades now. May be some people disagree with its use of macros, but it certainly works, runs fast and it's native in Windows, OSX and Linux.

I repeat it again. It's not only native-feeling. It uses the native controls in each platform it supports. It is fully native.

It is more native than toolkits which try to recreate the controls themselves. But I would not call it "fully native", because it does not let you write cross-platform fully native-feeling apps. It fails at that for the simple reason that that is impossible: different platforms have different UI conventions, including icon appearance, controls with no direct equivalents on other platforms, or with equivalents that have subtle differences in usage, idioms and standard layouts, behavior of keyboard shortcuts and gestures, use of platform-specific features, etc. If you do not spend a significant amount of time tuning your UI for each, you may end up with something that's 80% right, but it will never be 100% right.

Also, wxWidgets has had a lot of problems lately on OS X: high-DPI not being supported properly for years, broken focus, other bugs. It's not just the macros that make it an icky framework, which I say from unfortunate first-hand experience.

I'm curious about this. Does something like wxWidgets offer all widgets that are available in an OS?

Does it offer the files listing widget the Mac has in that fourth mode, where flipping between files shows on top an extra area that feels like flipping between music CDs?

I guess the point is, what do you do with widgets available in one OS that aren't available in another? Should UI libraries keep up?

It keeps up in some cases, as some dialog options are only available for one platform and ignored in the rest.

But it is updated slowly, i.e. the platform has a new widget and the corresponding wxWidgets update happens several months later.

You can check for example Audacity in your platform and evaluate if it feels native enough.

> There's a standard for most things happening in a browser, which means that things look pixel-perfectly the same on a huge amount of browsers <snip>he browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.

That's a good theory. My experience as a consumer of web sites across chrome, firefox, chrome on mobile, and firefox on mobile leaves me with a perspective more aligned with reality than theory. The same pages vary widely across these platforms. It's not uncommon for form fields to be illegible on one or more of them, layout is different, readability is different.

Maybe once we get that little problem ironed out (whether it be people building websites badly or things aren't as compatible as they should be, I don't know) we can talk about taking it further...


I feel a little twinge every time I hear someone say that something on The Web should be or is "pixel perfect". That phrase has a particular -and obvious- definition; one that is rarely correct when speaking of a web page that is viewed in more than one browser and/or on more than one machine.

> The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.

I'd say Flash is better than a browser. Flash seems to fall apart when embedded into a browser, but stand-alone it is decent. And it's IDE/tooling is top notch too.

I think this is shortsighted. In 5-10 years browsers will be more Virtual Machine than Web Browser. You can almost argue that they already are.

As browsers and phones get more and more performant, the idea of emulating native apps in the browser won't have the performance stigma attached to it.

This same thing played out with Java et. al. It was dismissed for being non-performant when compared to C/C++(aka native code) because it ran inside a heavy VM but nowadays the performance is just fine for an enormous amount of applications because the virtual machines and hardware got faster.

The JVM itself got faster -- and in many places, relies on native code for particularly expensive functionality -- but it's still unusable for end-user applications because:

1) The long load time / hotspot JIT overhead when starting applications.

2) The large memory overhead of the Sun/Oracle GC's reserved heap.

To some degree, Dalvik solved some of these issues, but has also retained the (very necessary) escape-hatch-to-native JNI.

JavaScript is SO MUCH HARDER to optimize than JVM bytecode. Whereas you can even feasible AOT-compile JVM code, JavaScript's dynamism makes this all but impossible.

On top of that, JS is welded to the DOM and CSS, the combination of which incurs huge rendering pipeline CPU and memory overhead for anyone doing anything as complicated as a "native" UI view hierarchy.

Rather than enumerate all the failures, I'll note that it's not all doom and gloom. We've got a web bytecode in the works that's much saner than JS. Canvas and WebGL exist.

Progress on those fronts may create a situation like you're describing, but -- and this is no great loss in my book -- it won't be the web.

Minecraft alone shows your first two points are not valid. Write a hello world app in Java, the startup time is miliseconds, the memory is not humongous.

(non-casual) Games aren't generally known for fast load time, sharing resources on a multitasking system, or short playing sessions -- all of which plays to the JVM's strengths (or avoids its weaknesses).

As far as fast load time; just launching my (JVM-based) build tool (sbt) takes 7 seconds on my laptop.

Running 'Hello World' from an uncompressed class file takes 0.12s, and most software is quite a bit larger than a couple lines of bytecode in an single uncompressed class file.

The C version, by comparison, completes in 0.005s.

Yes, recently, Java actually became usable for a lot of seemingly native apps.

And it does this a lot better than the browser.

> [The JVM is] still unusable for end-user applications because [it makes application startup slow and uses too much RAM.]

I can't agree.

The poster child for "bloated, overweight, slow-as-shit Java application" is Eclipse. Circa 2013, I found it to be not substantially slower or any less usable than Visual Studio on the exact same hardware.

That's implying that Visual Studio isn't also bloated, overweight, and slow-as-shit - three traits which VS serves as the textbook definition of. It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality.

In other words, "but it's on par with Visual Studio" does absolutely nothing to counter the argument that the JVM is unusable for end-user applications; if anything, it proves it.

After several years of working with both VS and Eclipse, I can say that IDEs are slow because they're doing a lot of work. (Eclipse suffers a bit because the Eclipse Steering Committee[0] won't let go of the dream that is the Eclipse Platform, but that dream primarily damages the ease of writing software for Eclipse, rather than Eclipse's execution speed.[1])

Consider two applications that each solve tasks of comparable complexity:

One of these applications is written in C++. The other is written in Java. Both are written by programmers skilled in their respective languages.

If both of these programs have roughly equivalent performance, what does that say about each underlying language?

[0] Or whatever their official name is.

[1] Source: In a former life, I was tasked to write and maintain bespoke software written on top of the Eclipse Platform. I cannot recommend the Platform for any new development that isn't writing software for Eclipse, itself.

>It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality.

Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss, but it's a very real thing despite those dismissals.

On the other hand, I don't really care much, since I've never had the emacs/vi user disease of insisting that everyone else acknowledge that my opinions are superior.

> Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss

Maybe the vi people do, but I'm not sure about the Emacs people, seeing as SLIME is the modern day free integrated environment for Common Lisp programming.

Regardless, my point was less about the superiority of Emacs and more that Emacs is the oft-cited textbook example of a "bloated" program (as per the "Emacs is an excellent operating system; too bad it's missing a good editor" joke), yet is dwarfed in size by the likes of VS and Eclipse while having parity or near-parity functionality-wise.

The "Emacs is bloated" meme stopped being relevant at least fifteen years ago. ;)

But seriously; some serious questions, seeing as how I've never really used Emacs:

How does Emacs compare to versions of Eclipse CDT or Visual Studio released in the past four years for C++ development? How well does Emacs's autocomplete [0] work for templated types of varying complexity? How about its ability to navigate to method definitions and implementations of non-obvious types? Does its autocomplete database update quickly and automatically, or must one trigger the update oneself?

[0] I figure that C++ development support isn't in mainline Emacs and is provided by extensions. For brevity's sake, I'll continue to improperly attribute this functionality.

In fairness Visual Studio (and most IDEs) are pretty bloated and slow.

As to the grandparent, that is what asm.js was for, was a subset of JS that could be heavily optimized and JITed... I also really prefer .Net method of native invocation over JNI stubs.

After several years of working with VS, Eclipse, and a couple of other developers' IDEs, I can say -with a straight face- that developers' IDEs are slow primarily because they do a lot of work.

Absolutely.. and if you're using one on a system without an SSD, it's outright painful. There's a lot that goes on with IDEs, effectively on-demand compilation, file watching, and there's a lot to that.

Of course, sometimes I find I'm actually more effected when I can just work on a small module in a plain text editor, and keep things organized so its' relatively easy to follow.

Oh, so a dumb terminal. Ok. It's 1980 again.

1. Dumb terminals never really left us. They are in active use all over. 2. The current web trend is using more of the browser CPU, as opposed to the server CPU. Heck, I have entire apps that don't call the server after load at all. I don't remember being able to execute code in a dumb terminal (possibly you could...I just don't remember it).

Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.

If it can do everything the user wants then what is the issue?

Just because it's been done before it's the wrong answer?

My reply was a bit ambiguous and snarky.

I don't believe it's the wrong answer if it works. But people are commenting about moving the web forward to run apps in browsers and all and so there are parallels with what we did in the 80's. That's really what I was getting at. Nothing in computing is ever really new.

We're replacing a very nice custom SCO Unix backend developed at my work from 1980s onward (drops users into custom shell, multiple programs execute in the user context, leverages all the nice features of *nix) with a purchased desktop Windows ERP application and it makes me so sad.

Literally we will move from having 1 to 2 admin who can manage 300 users, decades of automation, and totally instantaneous program execution (in C) with heavy user load on a single server to distributed, client based programs running on separate machines that all have to be patched, updated, troubleshot, etc.--(and the 5 person support team that has to go with it), communicating with a central program server and separate DB servers, etc.,etc., all because the console application is "too old looking".

A web based application could have a very similar backend, and you could run pretty much any modern OS client on the front end...

Though I think the development and training for your new front end will be a bit cumbersome no matter what you use.

You might be interested in the in the works WebAssembly, if you haven't heard of it already.


But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons.

I would rather see something like Ubuntu Touch tries where they write the frontend with QML and you can have backends in C++ for speed.

> But the only languages available are HTML, CSS and JavaScript...

Eh, there is the canvas, and WebAsm. They make for a full blown VM if you don't mind shipping a several MB large interpreter with your page.

Next step should be installing the interpreter on the browser, for everybody to use... Then we can create Flash all over again.

(Now, if somebody gets a way to do that full VM thing in a way that is compatible with the DOM, then we'll have some improvement.)

>"Web ASM [...] installing the interpreter on the browser, for everybody to use... Then we can create Flash all over again."

That's ridiculous. Is Javascript "like flash" because most browsers ship a several MB interpreter for it?

Javascript creating random elements on the canvas? Yep, just like flash.

> But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons.

I would have completely agreed with that a few months ago. HTML/CSS/JS is fine for most websites which are primarily text, images, and a couple buttons. But it breaks down quickly when trying to build an application. Then React was invented. I don't know if React will be the thing people use to build web applications in the future, but I think the concepts it introduced will be. The reason is because React provides a foundation that makes it feel more like building a desktop UI or video game than building a traditional website.

Performance will improve over time with faster hardware, faster networks, and software optimizations. Javascript V8 is already one of the fastest scripting languages especially for string handling.

But that is just fiddeling with the symptoms, not doing anything with the root of the problem. It is the same with webcomponents, they're building on such a shaky ground.

I like the ideas around https://www.youtube.com/watch?v=6UTWAEJlhww instead.

Based on the video, is security the root problem? Sorry, but that is a problem in every programming environment. Security is hard regardless of using C++, JS, Linux, Windows, etc. Therefore it is not terribly relevant to the question: is JS capable of emulating native functionality and should it?

For that question, the root problem was definitely JS itself historically but the language deficiencies have largely been resolved by ES6. In my opinion, the only major language deficiency is handling int64 and larger numbers which will hopefully be resolved by "value types" in ES7. Then use a React-like framework on top and building applications feels "right", at least to me.

I'm not quite sure if you watched the whole video, he says let's get rid of everything (HTTP, HTML, CSS) but JavaScript.

Probably will be more like a URL link aware VNC viewer. That has some interesting implications for the back end WRT emulation.

I think he's wrong in his assumption that navigation transitions are being used just to emulate native apps. They are being used because they provide a usability benefit. A navigation transition can demonstrate a lot to a user about hierarchy and flow [1]

[1] https://www.google.co.uk/design/spec/animation/meaningful-tr...

Back before the PC, didn't IBM and some other mainframe companies try to lease out terminals? This in that you could get a terminal on your home desk, that either via dedicated line or basic dialup would connect to a mainframe where you paid minute or something?

In a sense the web browser, and SaaS, has become a reinvention of that...

Yes: https://en.wikipedia.org/wiki/Time-sharing

A popular (for the time) example of this type of service was CompuServe (https://en.wikipedia.org/wiki/CompuServe). I had my first online experience connecting to CompuServe on my family's home PC, back in 1985.

Still do, big business. Any data dependent system. Reuters / Bloomberg / Datastream. Rented out terminals of a centralized system.

Ah yes, Bloomberg. Recently heard about those terminals in relation to someone using their service as something of a luxury Craigslist...

With data dependent systems, I assume you pay for access to the data, not just for the ability to use a computer.

> But why do web developers want navigation transitions? In order to emulate native apps, of course.

This is just a misunderstanding of good UI. Emulating native apps is NOT inherently "Good". There are terrible native apps and great ones. Navigation transitions would be nice as a another arrow in our quiver. Using it wisely is another can of worms.

Browsers should have one built-in navigation transition. When you click on a link that leaves the page, something should happen immediately. It may take seconds for the new page to load, especially on cell networks. There's no immediate user feedback, resulting in multiple clicking, which restarts the page load. So on page exit, something visible should happen. Dim out the page, zoom it down to a tiny rectangle, swoop it off screen and replace it with a busy icon, or something.

(Unfortunately, you can't implement this with a Firefox add-on, short of patching every link in the DOM, or I would.)

> When you click on a link that leaves the page, something should happen immediately.

On every browser I use, the UI changes immediately after clicking a new link.

Pay attention the next time you click a link that's not in cache. Look for messages in the status bar (which is usually hidden, but typically becomes visible on resource load or when hovering over a link), changes of favicons to spinners in tabs, and the change of the reload graphic to a "stop" graphic.

All of these UI changes are obvious to me.

I get that some people are impatient, but these same impatient people likely know how to and are licensed to operate a motor vehicle. Motor vehicle operation is a task that requires constant attention and much finer attention to detail than is required to notice the current browser UI cues that indicate that a new page is on the way.

Here's Firefox, immediately after entering a site name into the URL window.[1] The only visible effects are that the tab name has changed to "Connecting", and the reload arrow has change to an "x". On Firefox Mobile, you don't get either of those, just a one pixel high progress bar at the top of the screen. It's worse on mobile, where things are slower and there are fewer auxiliary GUI items on screen.

At this point, you've only partially left the page. Some clickable items on the page being exited will still work. It's not entirely clear exactly when event processing for the old page stops.

[1] http://s3.postimg.org/53784icoj/afterlink.png

Those are things that happen to the UI immediately after asking it to navigate to a site that you typed in.

Now that you've demonstrated the UI changes that happen immediately after you type in a URL and press Enter, what UI changes happen when you click a link that leaves the page?

That's the complaint of yours that I was addressing in my comment. :)

I don't associate "navigation transitions" with native apps. What native apps have navigation transitions? I think the iPod really popularized sliding screens and the like, and they spread to mobile.

The feature for web browsers makes sense as progressive enhancement. Instead of using a "tool" (library), you just say "use this transition" and if the browser supports it, it does.

If you read further they link to a previous post that covers just that: http://www.quirksmode.org/blog/archives/2015/05/web_vs_nativ...

I think this is the key:

> The moratorium would hit Chrome much harder than it would the other browsers, since it’s Google that is proposing most of the new features nowadays. That may not be entirely fair, but it’s an unavoidable consequence of Chrome’s current position as the top browser — not only in market share, but also in supported features. Also, the fact that Google’s documentation ranges from lousy to non-existent doesn’t help its case.

I think the title and a lot of the rhetoric is misleading, really. It's not so much "stop pushing the web forward" as it is "stop letting Google decide where forward is and leaving everyone else to either ratify it or be irrelevant." And, uh, good luck with that. I mean it. I would love to see that happen, but I don't see how to get there.

I wouldn't categorize Google as the leader anymore. Mozilla and Microsoft have caught up and are as much leading the charge as Google is. Four years ago I would have agreed but four years ago we needed Google to push the browser forward.

The stats seem to disagree (1): Chrome has risen from a global usage share of 20% in 2011 to almost 50% today. Compare that to Firefox (2011: 28%, now: 16%) and IE (2011: 44%, now: 18%).

(1): http://gs.statcounter.com/#browser-ww-monthly-201106-201506

I'm pretty sure he's talking about W3C/WHATWG activity, not market share.

Do you have any growth statistics as reference?

IE used to be the top browser, but look at how many other browsers implemented DirectShow filters. (Even on non-Windows platforms they should be emulateable)

I've seen this sentiment a few times: "don't try to replicate native apps in the browser." Which makes sense from the standpoint that the browser is just getting ridiculous, like a mini-OS unto itself.

However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen. It's the same reason that desktop Java was in vogue for a little while: you only have to write one UI, and you can run it from a HTTP connection with almost no local permissions. Of course, this was (and still is) a security nightmare, but browsers now do a pretty good job of sandboxing individual code blobs, and also do a pretty good job of abstracting away the native UI. Web apps also provide low or zero installation overhead (low friction to getting a user onboarded/working/monetized/whatever).

It would be nice to see some progressive enhancement folks address how to resolve these pain points on the native side, rather than just saying web shouldn't be like native.

The cross platform experience will never match the native experience. Think about on the desktop. The only cross platform apps that behave natively on Mac, Windows, GNOME (and derivatives) and KDE are apps tha have completely separate front-ends for every platform. Firefox is an ok example of this, although it in a way forms its own platform rather than integrating with its host, still it pulls it off better than other cross-platform apps. The Transmission bittorrent client is perhaps a better example, it has at least 4 mature front ends: gtk, qt, cli and os x. This is only feasible for a little free software project like Transmission because its UI is fairly simple, it has a list of torrents, a settings dialog and a properties panel.

Most apps that try to be cross platform just use a UI toolkit that acts as a cross platform compatability layer. Qt, GTK, Swing, WxWidgets and Tk all fit the bill. The result is that the app doesn't look good or integrate especially deeply into any platform, except sometimes with the platform the the developers personally use.

There are few exceptions to this rule. One is Sublime Text 2+ which is built on Qt. Without any customization, its theme looks OK, but doesn't match the design language of any platform, and its integration with its host platform is non-existant, everything happens within the sublime text window (no notifications or system tray/menubar widgets, no quick-view previews in Finder or Nautilus, etc). It's possible to improve integration by intstalling a custom theme which lets the user override a lot of the UI design, including the margins and padding, and plugins are written in python and can access a lot of host platform features.

If you want a native experience, you have to write a native app. You can share your business logic by linking to the same C++ code or in the future maybe by using react native and sharing the same non-view code. But your UI-layer has to be tailored specifically to the host platform in order to look good.

We have the same philosophy. Most of my experience here is with iOS and Android, but also a bit of Windows/Linux/Mac. If it's going to feel polished, then it's going to need a separate UI front-end for each platform.

It's not that there's not yet a sufficiently good cross-platform library; it's that an Android app and an iOS app are different! They're structured differently! And if you try to use an x-platform library, you're going to end up with an iOS-app-that-runs-on-Android, or an Android-app-that-runs-on-iOS, or a this-app-doesn't-feel-right-anywhere.

My approach varies based on the application, but in general one of two things end up happening: either the majority of the processing gets pushed onto a server with a well-defined REST API, or the processing gets put in a C++ library that gets linked everywhere (with JNI shims, ctypes shims, whatever's needed to load it in the appropriate environment).

This approach does a few things: it ensures that you've got a UI that fits every platform, it improves code quality (you can't add a chunk of business logic in your view handler), and it makes porting so much easier.

Facebook.com and Hacker News are cross platform apps, and they work amazingly well.

Of course Facebook.com has been removing functionality from their mobile website for some time. At this point when you post a link from mobile it doesn't even add the thumbnails anymore. I know it's to drive people to use the native apps (so they get much more tracking information, and run your battery down faster). But the affect is just pushing me away.

Agree completely, what I'm seeing though is "web" being the new native for a whole lot of apps. It's familiar to users across platforms, it usually looks good, and while it might not integrate with the host environment, it provides many aspects of the native experience.

But, even Firefox has a rather limited UI... Whenever you build anything with a moderately complex UI, it becomes nearly impossible to offer a good cross-platform experience.

I also think that standing on the shoulders of bootstrap and material design (like materializecss) is a better place to start where users will be cross platform than trying to look native everywhere... not to mention that native looks different every other OS release. Hell, look at MS Office from version to version, they break most of their own rules. A relatively clean, usable design is more important than getting everything precisely native looking everywhere.

Totally agree. Just look at the mess with mobile OS. It is nearly impossible to develop a native app yourself without excluding half of the world population. In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along.

> In my opinion, native mobile apps have been always an intermediary and I wouldn't mind seeing all of them going away if some better web app alternative comes along.

As primarily a user of mobile apps I would mind. A web app experience is at the mercy of the network I happen to be connected to. In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.

> A web app experience is at the mercy of the network I happen to be connected to.

That's one of many things that web apps have been fixing. It's entirely possible to write an offline-capable web app.

> In addition, as a user, the "build once, run anywhere" feature of web apps is a disadvantage since it often means that apps are written with the lowest common denominator in mind and don't quite blend in with the look and feel of either major mobile OS.

They do, however, look like web apps everywhere, and if you primarily use web apps, you'll feel right at home.

  > It's entirely possible to write an offline-capable web app.
Yeah. It is entirely possible to make web app do a lot of things. Even do them cross-platform. Even to get almost native feel. But when you are done doing it you understand, that going native even on each platform would be faster and cheaper.

And thus the reasons to keep trying to improve those stories. Offline is import for applications. Many web applications make perfect sense to also work offline, and if that can be done easily, then what's the argument? I'd agree that looking like a native app by matching look and feel is probably not a great plan, but I also just fundamentally don't understand the attitude of saying that the web should be relegated to blogs/news/wikipedia style pages and leave everything else to native app silos.

Except the complaint about inconsistencies in native UI toolkits to argue in favor of web apps makes no sense, since by definition web apps have no singular look and feel whatsoever beyond the basic semantics of hypertext and browser navigation -- assuming the app doesn't break them. (and then WIMP has its own mostly consistent semantics too)

I guess by that reasoning desktop apps should go away too, and we should all run ChromeOS.

We need a viewport-size-agnostic graphical native sandbox that works on x86_64 and ARM, and can be reasonably sure is escape-proof. Which is hard to do if you let it have multitasking and access to graphics drivers.

Then we need a means of letting it have just enough network access to be useful but not enough to exploit the rest of your system, bearing in mind the discussion of WebRTC going on at the moment.

Isn't this kind of what most browsers are currently doing?

As a corollary I'd like to say: stop pushing JavaScript forward. There seems to be a lot of focus on providing syntactic sugar for things that already exist (like classes, decorators, etc) at the expense of flexibility and composability (executable class bodies, @foo vs normal function application, etc).

What JavaScript needs much more IMO is a (better) stdlib, with more datatypes and procedures than currently available (including big numbers, the various flavours of trees, better support for equality and comparison, etc).

>What JavaScript needs much more IMO is a (better) stdlib, with more datatypes and procedures than currently available (including big numbers, the various flavours of trees, etc).

Isn't that "pushing JavaScript forward?"

Agreed. However I think to build on his argument, we should push JavaScript forward in a targeted fashion, based on its intended purpose.

Level 1: There are known huge missing chunks of JavaScript that should be resolved as they severely limit the power of javascript as a development platform which lives in a network application.

For instance modules, promises, etc...

Level 2: There are known huge missing functionality which are missing which are well known elements of a sane UI framework which should be implemented because bottom line javascript is a UI scripting language.

For instance properties and some kind of observable mechanism.

Level 3: IS all the highly subjective and often syntatic sugar intended to make javascript work more like other programming languages like C# or Python.

For instance classes,. arrow functions, generators, let statements...

Generally the problem is the focus seems to be completely skipping Level 2, to get to Level 3.

Yes thats the point really... Observable are scheduled for ES2016, which satisfies a clear unamibigous and relatively not controversial 'need' is coming out in 2016.

Meanwhile arrow functions, let vs var, generators, etc etc etc are coming out in 2015. Why?

Its not skipped as in 'its not on the roadmap', its skipped like 'lets leave it for now and do something else'. Its skipped over to add a bunch of shiny bells and whistles and syntactic sugar. You shouldnt put in the leather seats before the steering wheel.

Those phases exactly mirror the phases listed in the article.

where in the article?

Maybe what skwosh means is a moratorium on new features in javascript so that we can refocus on the features that are useful, and actually improve rather than complect the language.

Thanks, that's what I mean. My feeling is that some of the syntactic extensions to the language are piecemeal and don't reflect the full expressivity of JavaScript.

It's slightly different.

The addition of sets and symbols, for example, did little to change what an existing codebase looked like. Similarly, adding explicit trees, binums, and so on won't really change much.

The improvements going on right now, though, seem mainly concerned with syntactical sugar and extra syntax. The problem (and I'm in a minority here, I think) is that this creep and bloat takes a quirky language that fits into one's head and instead starts making it a rat's nest of special-cases and odd interactions. This is the sort of thing that caused C++ so much trouble.

Once they add annotations and shared state and threading (and that's coming), the party will be over and the earth salted.

Good call. Basic numeric and date/time types need work. I don't really need "Java-fication" syntactic misfeatures.

Javascript has decorators?

Higher-order functions do the same thing.

Yes, at least in ES7. Babel supports them.

"Native apps will always be much better at native than a browser. Instead, we should focus on the web’s strengths: simplicity, URLs and reach."

For me, the web's main strength is that you have to write your application only once. I don't have to think about redesigning the UI because "that's not the iOS way" or "that's not the Android way." I don't have switch between different languages and write the same damn thing one more time. I don't have to hire a whole team to have an idea see the light of day and be accessible to the great majority of people. And if my idea is a little idea, I don't have to struggle so much to get people to check it out, given that installing an app is a much bigger barrier than clicking a link.

I understand that if I want to be on the bleeding edge, and I want it to be optimal whether it runs on a phone, a tablet, or a computer-proper, browser dev can be challenging. But I don't always have to be on the bleeding edge.

Still, it's nice to know that browsers are becoming more and more capable, so there isn't quite as huge a chasm between native apps and something that runs in a browser. That's an artificial distinction.

Agreed. I for one do not want to be forced to develop on 3 platforms just to provide a decent user experience. Take all that effort and focus it in one place to create a truly great experience.

Also Security. Installing an app (even from an official store) is just too risky. Even a non-malicious app can significantly undermine your machines performance.

When I close a browser tab, the web app is gone!

"However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen."

Does it? I used to think that. Until every medium-complexity or worse web project I've worked on took forever as we went through all the different browsers and OS's and now mobile and tablets and responsive and OMG just give me a decent native app tool now please.

Browsers absolutely suck at UI beyond their original intended domain.

Was this in reply to my top-level comment? Looks like this ended up a sibling instead.

In reply to your comment:

Perhaps, and I lack the experience and evidence to contradict you. I work solo on small to mid size projects that are mostly back-end. But I am fairly confident that with the large number of mid+ size web app projects we would be seeing a migration back to more native apps if the overhead is actually greater than maintaining multiple native apps.

It's not like every company in the world is incapable of independently assessing their needs. And bandwagons will form when independently-minded companies change their processes. So why aren't we seeing a mass exodus from complex web apps? And why are many orgs using native wrappers around these supposedly terrible web apps to produce a pseudo-native app?

EDIT: Also, how would you address how much easier it is to try out a web app without having to install it vs. finding, downloading, installing and running a native/mobile app?

The company I work for has a web app. Has had for years, yet have rebuilt the exact same functionality a further three times as native apps for iOS, Android and Windows Mobile.

Presumably the overhead of maintaining multiple native apps (on top of the existing web app) is still cheaper for them than making the web app work for mobile.

As a further anecdote, I personally don't know many people who like using web apps on their phones. I certainly don't. On my phone I use my browser to read HN and other articles and native apps for everything else. Most people I know are the same.

Re: your edit - finding is no different than your web app. Downloading, your web app downloads too only everytime I load it instead of once. When installing from one of the app stores, I've never found downloading or installing any harder than clicking a button. Installing, sure, but only because the term sounds like a crazy heavyweight thing to us. The process (for mobile apps, not desktop) is generally a single click that you do once.

The thing that web wins at here is that it eliminates even these few clicks, and since you don't "install" it, people feel safer and happier.

It certainly allows (some) organisations to 'believe' this.


Ahhh, I'm with you, but not with you.

There's a lot of Line of Business apps that can be written really easily as webapps. Right now my default toolkit for doing those is: Rails, Angular, Foundation. These are often pretty much just slightly-interactive forms and reports, and fit reasonably well within the browser model.

These aren't profit-centric apps, these are cost-reduction apps. One of the best parts about web apps in this context is that they reduce the deployment and management costs. You don't have to worry about supporting legacy versions, nor about deploying new versions of the apps to every machine in your organization. They don't have to be perfect or beautiful, they just have to save more time and money than they cost to build and maintain.

ATM, The two top articles (Why Docker isn't Successful in Production) and this one are both cries for the world to slow down. It's not going to and everyone ought to strap in. If change is called for, it will be adopted. If not, it won't. Some technologies were rejected simply because they came about at the wrong time. Some technologies that are adopted now will later be deprecated as better solutions are found. Change is constant.

The article is premised on a distinction between "apps" and "the web". No such real distinction exists. The distinction is in the form factor and physical interaction. The software distribution model that mobile apps utilize was rejected outright in the 90's by both users and software companies. I don't want to worry about what % of users have a particular version of an app, what particular version of an OS a user is running (Android is not alone here), have my apps approved and taxed by a third party, or whether that app is properly discoverable. This is even before we get to the fact that developing for multiple platforms in the mobile world involves completely different skillsets and tools and therefore additional costs.

Furthermore, "performance" is a secondary (albeit important) concern. There is no computing law that prevents the web from achieving reasonable parity with native apps. Funtionality and usability will almost always trump performance.

The browser is a great VM, may the best features win.

> If change is called for, it will be adopted.

Please elaborate. This does not seem to be true but it's too short to fully understand.

Well, if the market sees a technology as solving a particular problem it will adopt it. As you suggest, this is more complicated than nine words can cover. It may only be temporary -- like flash video. Up until flash video took over, the existing solution were plugins like RealAudio/Video. If mobile application development solve a pressing need better than other solutions, ideally it will be adopted. Of course, technical merits are not the only issues at play here. Marketing, costs both hidden and direct are all absolutely factors determining whether change will occur.

> Well, if the market sees a technology as solving a particular problem it will adopt it.

Bollocks. The "market" is not a sentient, rational entity. There are many more factors that go into market adoption.

I hear that people have written entire books on the subject. Do you have a point you were trying to make other than "markets are not sentient and rational"?

PPK raises very valid points. I further want to add that you do not need flying boxes, fading tool-tips and what not to make your app look cool or even beautiful. In-fact it is pretty silly to try to make websites look very beautiful and cool because you can never cater to the taste of every single user. Your flying boxes which look cool to one person might look ugly and distractive to another one. Do we not have enough flame wars on whether iOS looks prettier than Android or the other way round?

Google is popularizing a set of styles called "Material Design" and it's friends. Here is an example: http://www.google.com/design/spec/animation/responsive-inter.... Here is another example of something more classy: http://motherfuckingwebsite.com. Why the first one is any better than the second one, only Google knows.

We can have simple sites, like the present google home page, like the blog post you linked, like the second example I linked, etc. without emulating native, which do their work, and users use them with a lot of love.

P.S. The question "why do you need smooth transitions" applies to native apps as well, PPK ;)

For comparison, see "Python Language Moratorium". I think its outcome was positive.


Python is a language with one official supplier and many customers. Most of the other Pythons base their functionality in the official Python and alter the underlying code to suit the platform.

Browsers are supplied by at least three main sources and several smaller sources, each trying to convince everyone that theirs is the One True Browser by pushing forward at breakneck speed. There is never going to be total agreement (or even sanity) as long as that is the case. It's a mixed blessing, IMO.

Was it really? I'd like to see proof that it actually helped Python 3's adoption. Wouldn't new features from 3.5 like async/await have given people more incentives to switch had they been released earlier? (they would have for me)

While I agree with the general idea, I completely and utterly disagree with both his examples and approach.

First, it's almost like he's arguing that IE6 was a good thing for the web. This one completely boggles my mind. Yes, some people came up with some pretty creative tricks. Did it stifle innovation? Absolutely. Countless hacks were made that are arguably(?) worse than polyfills. These hacks persist even to this days. Further, modern browsers must take all of these hacks into account when moving the web forward. This is massive technical debt. Additionally, how many man hours were spent creating these hacks to deal with the shortcomings of IE6? That time could have easily been spent working on something awesome.

The other example on page transitions is a bit more reasonable, so I'm being a little pedantic on this one. I agree that page transitions are a bit much, however why is a polyfill really necessary?

All that being said, I agree with the general sentiment. We need to slow down and put thought into the features we're creating. However, I don't think we need to stop working for a year and see how everything plays out. What happens after 5 years? We stop for a year and continue as if none of this ever happened, then continue pushing things forward for 4 more years. Then we run into the same exact problems. We need to have a way to vet experimental features, and a plan to remove them (and old features) if they don't pan out.

We've progressed far enough to where removing legacy features is as (if not more) important as introducing new ones.

> We’re pushing the web forward to emulate native more and more, but we can’t out-native native.

I can do better than native.

I can update web apps without troubling the end user, fix bugs and make improvements immediately.

I can balance processing where heavy lifting is done on my servers and simple processing done on the client.

I can store immense data in the cloud freeing the end user's machine from any such junk, aside from maybe a cookie, and stream it on demand.

Why should someone have to install anything on a phone, tablet or PC? Feels archaic. Open browser. Navigate to URL. Do work, enjoy media, etc.

> I can do better than native.

No, you can't. Not even close. Just because you only ever use a subset of what can be done in a native application doesn't mean the rest of us don't.

Also, which "native"? Win32 != OSX != X11 != mobile != ...

> I can update web apps without troubling the end user,

Which makes you the source of one of the most common types of user frustration: apps that change without their authorization, sometimes breaking important things that used to work just fine.

> ... processing ... done on my servers ...

Ahh, so you just want to lock people in using Service as a Software Substitute[1]. Trying to do an end-run around "1st sale" rights to insert yourself as a middleman where none was needed previously is terrible, sociopathic behavior.

> I can store immense data in the cloud freeing the end user's machine from any such junk, aside from maybe a cookie, and stream it on demand.

The user also has to trust that you will handle their data sanely (and not "monetize" - including using or selling the analytics of their usage patterns). They have to trust that you will not betray them and hold their data for ransom. They have to deal with the fact that you will hand over any of their data in bulk when the government shows up with a national security letter. They have to trust that you are competent at programming and have not stored passwords or allowed their data to be stolen.

The trade off being made by storing data remotely is huge, stop pretending it doesn't exist.

> Navigate to URL

And when internet access isn't available? Don't believe for a second that this isn't a problem. The reasons why are far too numerous to list; it would require a lot of wilful ignorance to pretend otherwise.

> Why should someone have to install anything

Because they like to actually use all of the features a native app can provide?

Because they don't want to risk their data with an external service?

Because they don't want to depend on the availability and whims of an external service?

Because they are tired of the lies and doublespeak the computer industry has been saying about "the cloud"?[2]

[1] http://www.gnu.org/philosophy/who-does-that-server-really-se...

[2] https://projectbullrun.org/surveillance/2015/video-2015.html...

All of those problems? Users don't know, don't understand, or don't care.

Native? Regular users don't care if an app is native or not - they just want a well designed app that works across their laptop and tablet.

Updates? That's probably one they do care about - they want it to happen without being interrupted.

SaaS? Users don't care - value for them is about 'it just works', not some philosophical debate about if they only have a limited use license for the music they stream on Spotify. If Spotify shuts down, they'll move to the next service.

Cloud storage? Users want their stuff to be accessible from their phone, tablet, and laptop. We need to educate them about risks with that, and put transparent controls in place to help them.

Installing apps? Users don't care - just make being able to use an app easy. Website, app store, whatever.

As a developer, it's your (our) responsibility to help the user figure out where it matters in terms of getting the outcome the users want. Hide the shit they don't care about, educate them in language and terms they understand about the things that do matter, and don't annoy them with inconsequential stuff.

For how many apps do users want it to work on their laptop and tablet? Personally, if it works well on tablets only, I'd just get out my tablet when I want to use it. It's not like I'm tied to using particular devices in particular locations.

Best comment so far! The web is a multi platform client-server application environment. Sanboxed so that unsecure (javascript) code can be downloaded and executed at runtime. THIS is the killer feature of the web. No other app environment has this and Web and JS will eat native apps in the long run because of it.

This was the first I'd heard of "Navigation Transitions" (perhaps I don't read the right mailing lists), and ppk's right - this seems like an absolutely crazy feature to add.

What about the idea turns you off immediately?

Two things: 1) it requires an extra stylesheet (from what I can make out, at least); 2) you can already achieve this with JavaScript, if you really want it (which is, itself, debatable), so why add extra cruft into the browser?

Also, from the page ppk links to:

   <link rel="transition-enter" duration="0.25s" href="URI" />
This makes absolutely no sense, though perhaps it has a place amongst the wealth of gibberish we've seen stuck between <head> tags over the years - <meta http-equiv="pragma">, anyone?

> Instead, we should focus on the web’s strengths: simplicity, URLs and reach.

How does new browser feature X prevent a developer from doing any of these things?

> Being forced to work around IE6’s issues required quite a bit of creativity, and although not every solution stood the test of time (most libraries and frameworks from that era, for instance), it still made the creative juices flow.

'Tools' are bad except when they are used to work around stagnant browsers, I guess?

Both of your points are right, but I'd like to point out that regarding:

How does new browser feature X prevent a developer from doing any of these things?

A moratorium on new features probably wouldn't help, but the reality is that web developers are focusing on new shiny browser features that allow for deeper native integration, rather than on the core elements of the web that work and carry greater usability gains, like offline support.

That's a good point. I can see a progression like: developer finds new feature X that solves problem Y, developer finds that feature X is only supported by 20% of customer browsers, developer adds polyfill in XXX kB, buggy javascript library with other performance-related side-effects.

Maybe the issue is just educating web developers about what's available, and the non-obvious side-effects using feature X.

Here's what I'd like to see: organize a site like caniuse not by feature, but by tiers of support in the entire population of installed browsers. Something like:

Supported by 99.99% of user-agents: image tags, ... Supported by 95% of user-agents: XHR, ...

(I'm making those numbers up).

For example, a lot of the problems that could be easily solved via declarative HTML tags are being solved via low-level JavaScript APIs.

Not to mention that the web sets its own expectations. If everyone uses stupid modal popups, your clients will expect you to use stupid modal popups.

The web is an ecosystem, browsers are species. They create new mutations in a new attempt to thrive. The definition for what it means to thrive is always the same. To replicate oneself the most. That means the largest user adoption. If performance is what users judge by, then browsers will adopt to it. If transitions are what users what, than browsers will adopt.

IE had trouble adopting, it had the wrong balance of features. That's why it started to go extinct.

You can't DESIGN an ecosystem. You can't tell an ecosystem to stop churning. It just keeps going.

Timing also matters. If a fish evolves a hand, does that make a better fish? Maybe not, but if the fish starts breathing, and living out of water... maybe those hands would be pretty useful.

In a way, I see what he means. Let's take a breather to let all the major browsers support the existing standards before we give them more draft specs to chase.

I think we need two primary things to solve this "problem".

1) we need more browsers

I know this probably sounds counter-intuitive, but I think I have a good explanation for it.

2) we need to allow developers to "choose" browser of choice that renders their page / app / whatever in the (what I would call "meta-browser").

The architecture of browsers is incorrect in that instead of having a few browsers, all of which developers must support, we need one (or a few) "shell applications", which "host" browsers. Browsers can then begin to become specialized and diversify in directions they want to (instead of forcing everyone to stay up to date with everything).

Today I agree, it's a circus, trying to keep up with things, and figuring out how to mash stuff together in order to ensure cross-browser compatibility.

So, how do we get things to a point where a developer gets to "choose" the browser for the user? Probably one of the simplest would be to pass HTTP headers which tell the "shell application" which browser to render the web app / site / whatever in.

There is not enough room in one HN comment to explain the nuances that I think can be solved relatively easily (ie. security, user confusion, etc).

I did write a blog post that explains more or less what I am talking about here:


With all that said, I really do hope the OP was saying all he had to say in jest. It seems ridiculous that one person should have any expectation they (no matter how well known they are to the community) can stand up in a crowd of 7 billion people and say "hold on, let's stop and think about what we're doing". This assumes all 7 billion (or even most of them) are not thinking before doing, or can't possibly be certain about what they're doing without express written consent of OP.

Just because one person can't possibly keep up with all that is happening in the world doesn't mean everyone should feel obligated to stop to allow them to catch up.

OP also seems to imply it'll be near impossible to reverse out of what is going into the web, no matter how good or bad those decisions are. I think it's a bad assumption. Things will continue to move forward. Whether that means one company or two decide to take two steps back is another question, but in general the web will (and should) continue moving forward. It's a great idea to have "web as platform", and not "web as html and links".

Please web, don't change direction of your thinking. You're on the right track. We just need some relatively minor architectural changes to make it go more smoothly for more people out here doing what we're doing.

One thing I do to try to slow down the rate of change on the web is to upgrade my browser less often than most people.

Specifically, I use Firefox Extended Support Release (ESR).

Mozilla resisted providing this "update channel" (Firefox ESR) for years, but eventually yielded to the desires of large IT departments. Despite Mozilla's writing that "Firefox ESR is meant for organizations", with only one or 2 minor problems (with plugins IIRC), which I easily solved by upgrading temporarily to Firefox's normal ("release") "update channel", I've used it personally for years.

Below is a link to the best page I've been able to find to download Firefox ESR, but note that both version 31esr and version 38esr are available from the page below. Version 31esr is still supported with security patches and is what I have been using. It is my understanding that before it stops getting security patches, version 31esr will automatically upgrade itself to version 38esr.


> will automatically upgrade itself

No no no no no no no no no no no no no no no no no no no. No. Just no.

This viewpoint reminds me of an Attorney's, who used to be a City Attorney: He felt that for every law passed, two should be struck from the books.

Or taxes: I have heard it said a politician rarely finds a tax they want repealed.

Wouldn't focusing on core web infrastructure for a period of time encourage addressing shortcomings, like the current state of security (and sometimes lack thereof)?

The cool thing about many of these features is that I can push out some code that I can share with a hyperlink and other people can run it without installing anything other than a browser.

The authoring experience is still terrible. And the user experience still requires hopping over the secret, invisible wall into developer-tools land... but the potential is there. If you're savvy enough to open your web console and view source you can mess around with some code I wrote to demonstrate some fundamental procedural algorithms[0].

I chose Javascript and <canvas> because everyone has a Javascript interpreter and most browsers today support <canvas>. If I had chosen to demonstrate these algorithms in Python, for example, I'd have to expect my reader to download and install a Python interpreter for their system, download or copy/paste my examples, and load them into their REPL before they could start playing around. The browser experience requires fewer steps.

A moratorium would be a welcome change of pace, IMO. It'd be nice to close the gap between the user and the developer and between document, code, and media. It'd be nice if authoring tools for these environments could catch up with the available features.

On the other side of the coin the proposed common byte-code format is really exciting and practical for all sorts of reasons -- in the case of my aforementioned blog post I think there are better languages to teach with than Javascript and having that language be available as a first-class citizen in any web document would be a boon.

I think some features would still be worth pursuing in favor of others.

[0] http://agentultra.com/2015/06/24/introduction-to-procedural-...

The cool thing about many of these features is that I can push out some code that I can share with a hyperlink and other people can run it without installing anything other than a browser.

What you describe is a hack for lacking isolation/security/permissions/package management in the operating system. Seriously, if there was a sensible way of isolating apps and handling dependencies, it would be perfectly sensible to implement a lot of the current web "apps" as real applications.

What I was attempting to describe was a document format the freely mixes code, documentation, and interactive media. The present set of features in the browser allows for a very fluid mixing of these elements but the authoring tools and user experience are lacking in most browsers.

I can share similar documents via org-babel, iPython notebooks, or Matlab notebooks, etc... but each requires the user to be accustomed with those applications to install them, fetch my code from a URL, load it into their environment, etc. With the present browser ecosystem they can fetch everything as a single document and run the interactive examples and modify code on the fly... if they're willing to hop over the developer-tools wall.

> The cool thing about many of these features is that I can push out some code that I can share with a hyperlink and other people can run it without installing anything other than a browser.

Both Windows and Mac have app stores now. Installing apps is a one-click affair, and you can even send URL's to them (in Windows 10 at least).

Most of the Windows 10 apps are only a couple MB. That's less than the typical media-heavy website.

I don't think web moved forward. There are some fun features, but the only thing I really see in last years is HTML video replacing Flash. Otherwise it's the same web as it was 10 years ago.

From a technology standpoint I agree with you, except that images have gotten larger in file size.

Socially, we've lost the "anything is possible" vibe that the early web had, thanks to oppressive governments and spying.

> Socially, we've lost the "anything is possible" vibe that the early web had, thanks to oppressive governments and spying.

I'm not sure those two things have anything to do with each other.

slinging around "web trying to be native is bad" in the way the author does is such a thoughtless argument: just because something exists in native land (a land of a lot of well paid researchers and designers, etc etc), doesn't make the idea bad for everywhere else. Maybe the idea is just a plainly good design decision?

(I mean, do you have fond thoughts of the entire page flashing white, then pieces of the page bouncing around the screen as they try to position themselves based on content that hasn't loaded yet?)

"(I mean, do you have fond thoughts of the entire page flashing white, then pieces of the page bouncing around the screen as they try to position themselves based on content that hasn't loaded yet?)"

You mean like it does now?

yes, which is why "imitating native", aka not reloading the entire page, is seen a lot more on sites like facebook and twitter (the ui stays the same as the main page reloads), this is done to provide a more comfortable experience, sans screen flashing rave party

navigation transitions (more of this horrible ugly "native" stuff) is standardizing a mechanism for this

We went from the stagnation to fast-forward.

I hated the old days because nothing seemed to change.

The browsers had slowed innovation because of IE and PHP didn't seem to try much new things (besides the OOP additions) for a long time.

But it was easy money. I learned PHP, HTML and CSS and was set for about 10 years with subtle changes.

Since 2013 I went from ExtJS, to Ember, to React on the client and from PHP to Node with Express and then Koa on the server.

It got a bit more exiting, with all the new features and a much faster development pace, but I went from old, never fixed bugs to new unstable libraries. So the rage stayed the same, hehe.

I can't disagree more with his critique of navigation transitions. Transitions are the best way people can create a great user flow without needing to structure their web app around the single-page, stateful, AJAX (or WebSockets) paradigm. If you think transitions are a bad idea, I hope you think single-page apps are a good idea. And if you think that the web just wasn't meant for that level of native-app-like functionality, I think you're not going to win that argument against the real demand for those kinds of offerings on the web.

The only reason web applications are such a big thing is discovery. It is much easier to get someone to your page than it is to get him to install an executable.

What we need is better app marketplaces with OS integration.

An experience is not a function of a feature. The browser does not define the experience -- the web developer does. So to say creating too many tools is bad, if anything, is an attack on the web developer for misusing their tools. For this reason, we shouldn't be able to say navigation transitions are a bad feature. The onus is on the web developer to create a positive experience.

>Do we want the web to be at whatever we push it forward to?

It never became what we pushed it to. A new feature is unusable. Nobody building a critical page can use cutting edge features due to bugs and compatibility, and they are mostly for experimentalists and fiddlers. Only those with deep pockets can do the multi-platform web page which is building multiple web sites just for a handful to have a cutting edge experience, but even this trend is dwindling it seems with the death of Flash.

A new feature, if anything, is an offering. It is a question posed to the web developers by browser developers asking them to examine a new opportunity for new experiences. The web developers then tell the browser developer community whether they love the feature or hate it, and this is how the web has organically evolved.

Therefore, it can only be a good thing that finally all these features are being pushed to production so that all these questions can be posed. So do we love them or hate them? The browser developers focus should be on pushing cutting edge features forward, and not on experiences. Leave that to the professionals, and mock their work if you have to.

If you can't keep up then don't.

Some of us have ideas we've been wanting to implement and are just waiting until a browser feature becomes available and widespread enough that it is a possibility.

I don't want to have to develop for the web and an Android app.

I don't want to have to develop for the web and an iOS app.

I don't want to have to develop for the web and a .NET app.

I don't want to pay 30% to a company just so they will let me deploy MY OWN app to MY OWN users.

I don't want to have another company dictate what I can or can not provide to my users.

I'm not sure how you square "If you can't keep up then don't" with what sounds (to me) a lot like "I have an idea that I want to implement, but only if I don't have to learn anything new"

To try to be at least somewhat constructive:

I took PPK's argument as: "Trying to cram everything and the kitchen sink into your browser so that you don't have to ever write native code may be appealing, but it risks collapsing under it's own weight."

Which, to me, doesn't seem so ludicrous that it deserves to be shouted down.

It's not the learning or the hard work that concerns me. I'm all for that. It's proprietary walled gardens for the most part. I want to build apps that I already know Apple won't approve so that leaves me with a reduced ability to service my users until mobile web gets better.

The guy is clearly over the hill and his old glory is over. He made a bet to chase and document every silly and ridiculous quirks in legacy browsers and established a name in this 'field' during the Great Web Depression 2000 - 2005 now that these days are gone and no one is interested to listen to what IE6 or Microsoft dictates on the community and we're living in a true Renaissance and booming expansion, his desperation and frustration with losing bets and falling behind his peers are showing but his phone outrage and indignation are not fooling anyone.

He was asking for it by shunning modern and progress in web development and instead endorsing everything that's reactionary and antiquated in the field and his latest outcry hopefully the last would be just a blip on the radar and we would be moving forward nevertheless.

You reap what you sow

Native apps will always be much better at native than a browser

That may be true but I don't want to install dozens of applications, I like being able to run apps in my browser. Google Docs is great... 99% of the functionality i could ever use in an office app, and no need to install software (if it even runs on my platform).

And I absolutely hate browsing the web on my phone to have every site pop up a "hey, try our mobile app, its soooo much better" message that gets in my way.

Native emulation has been a goal of the web from the beginning. I can recall several efforts as far back as '96 to create websites to replace desktop apps and we arguably achieved that around 2005 with apps like Google Maps or Writely. Two years before the iPhone was released we were chasing the tail of "native". The web vs native debate skips over the idea that these two worlds actually inform each other and are largely populated by the same developer community.

As an industry, I think people are starting to place more value on the comprehensibility of software over its capability and that's where I think PPK hits home here. When you're building to satisfy immediate needs it makes sense to eventually stop and revisit your implementation to make sure (1) those needs are still relevant and (2) your implementation adequately satisfies them. That's what I see this as, not a call to stop chasing native, but a call for replacing the patchwork with comprehensible design. I think that's perfectly reasonable and I would go so far as to say we should build it in as a cultural value to pause every 10 years to both celebrate what we've accomplished and refine the result.

> Interestingly, Microsoft added a similar feature to IE4, and deprecated it as of IE9. The idea didn’t catch on because back then nobody wanted to emulate native apps (which didn’t exist), and therefore nobody particularly cared if the users had to briefly wait for the next page.

> native apps (which didn’t exist)

Does this writer believe that nobody installed software on their computers before the iOS app store opened in 2008?

The usual meaning is "native apps" for smartphones, as opposed to traditional programs like PhotoShop and AutoCAD.

It's a broadbrush description but almost everybody gets it.

Would you like to offer a simpler, shorter and more accurate way of making this distinction?

I think it's a silly distinction to make. Native applications (meaning software running on a computer, outside a browser sandbox) have always offered a smoother, more comprehensive user experience.

That doesn't mean users get no value from the web, or that they're so spoiled by fast transitions in Microsoft Word that they won't want to use a website.

I agree, but that's not the point.

The point is that some -- perhaps many -- people want to distinguish between smartphone apps and traditional programs, and that's one way to do it.

It would be nice if there was a better way, but I don't know of one.

Incidentally, it's a distinction that people also make between "universal apps" (written for Windows Runtime) and desktop programs (written to the Win32 API) even when they do the same job on the same Windows 8 or Windows 10 PC.

The meaningful difference is whether there are isolation and distribution/update mechanisms so that users can install and maintain apps with less risk and hassle. This doesn't have much to do with (in-app) UI per se, though.

I've gotta say, I'm somewhat sympathetic to the idea that we'd be better served by a period of focusing on stability and performance over new features... but talking about the IE6 stagnation era as a good thing?

Yeah, no, that was awful, and if you're holding it up approvingly, well, now I officially disagree with you.

The IE6 era (2001 to 2005 or 2006) was a period of great creativity, and it was when a lot of dominant web properties became established. Examples include Wikipedia, LinkedIn, Second Life, The Pirate Bay, MySpace, Orkut, Facebook, Gmail, Flickr, OpenSreetMap, YouTube, MegaUpload, Pandora and Twitter.

Web 2.0 became popular during that era (2004 onwards).

That "stagnation" compares rather well with much of the flashy, transient rubbish being launched nowadays.

Also, when it came out, IE6 was the most standards-compliant browser and generally performed better than its main rivals.

I don't see how pages transition is trying to emulate native apps. It still falls under the paradigm of accessing a resource at a given URI, which is what the web is. Personalizing the way the resource is loaded by the client and displayed to the user? That's just cosmetics we should definitely care about.

Currently, the most popular way of implementing "native apps" in the browser are Single Page Applications, which breaks the web paradigm and hence have practical drawbacks such as the inability to open some resources in a new tab or to bookmark them. One motivation of SPA is the fact that loading a new webpage produces a blank intermediate screen during downloading, which is lame, especially for pages which are almost the same. Pages transition can change that, and in a beautiful way.

>But why do web developers want navigation transitions? In order to emulate native apps, of course.

You got this one quite wrong. It's not about emulation, it's the feature. Reducing the perceived delay with an animation. There is nothing wrong with an improved webpage experience ...

Damn that page loads fast.

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact