Stop pushing the web forward
quirksmode.org
quirksmode.org
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.
>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.
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.
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.
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.
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.
And that's bad because? Given some use cases it could be a very handy and pragmatic re-use of available resources and protocols.
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)
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.
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.
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.
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.
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?
Does anyone have a link for something similar for Android phones?
http://www.html5rocks.com/en/tutorials/appcache/beginner/
It's rad.
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...
> 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.
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.
Isn't that the point? To slow this down because perhaps the people driving "innovation" are insulated from its disruptive effects?
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.
Deleted comment
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.
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.
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.
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.
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.
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.
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.
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).
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.
- 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 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.
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.
Etc.
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?
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.
Personally I prefer to put up with some cruft than not being able to do something at all.
(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)
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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 for the record, doing a port well (as opposed to a hacky, broken one) frequently requires lots of creativity and technical ingenuity.
I've heard that some users have both a phone and a laptop.
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.
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.
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 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.
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.
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.
And it does this a lot better than the browser.
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.
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.
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.
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.
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.
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.
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.
Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.
Just because it's been done before it's the wrong answer?
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.
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".
Though I think the development and training for your new front end will be a bit cumbersome no matter what you use.
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.
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.)
That's ridiculous. Is Javascript "like flash" because most browsers ship a several MB interpreter for it?
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.
I like the ideas around https://www.youtube.com/watch?v=6UTWAEJlhww instead.
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.
[1] https://www.google.co.uk/design/spec/animation/meaningful-tr...
In a sense the web browser, and SaaS, has become a reinvention of that...
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.
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.
(Unfortunately, you can't implement this with a Firefox add-on, short of patching every link in the DOM, or I would.)
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.
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.
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. :)
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.
> 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.
(1): http://gs.statcounter.com/#browser-ww-monthly-201106-201506
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.
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.
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.
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.
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.
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.
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.
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).
Isn't that "pushing JavaScript forward?"
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.
Modules: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Promises: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Data structures: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Obervable mechanism: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
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.
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.
When I close a browser tab, the web app is gone!
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.
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?
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.
Unfortunately.
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.
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.
Please elaborate. This does not seem to be true but it's too short to fully understand.
Bollocks. The "market" is not a sentient, rational entity. There are many more factors that go into market adoption.
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 ;)
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.
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.
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.
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...
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.
Also, from the page ppk links to:
<link rel="transition-enter" duration="0.25s" href="URI" />
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?
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.
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).
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.
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.
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:
https://medium.com/@datashovel/why-isn-t-there-a-meta-browse...
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.
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.
https://www.mozilla.org/en-US/firefox/organizations/all/?q=e...
No no no no no no no no no no no no no no no no no no no. No. Just no.
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 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-...
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.
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.
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.
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.
(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?
navigation transitions (more of this horrible ugly "native" stuff) is standardizing a mechanism for this
If you get a good set of low level primitives exposed that are freely composeable, then you can stop adding "features", and let third parties develop those features.
The Web is missing lots of features for mobile that are being added today which simply cannot be replicated by freezing features and using IE6 era hacks. These are features that are needed not to emulate native apps but to make the end user experience of the Web better for end users.
For example, ServiceWorker replaces the terribly designed Application Cache, and enables better caching logic, offline use, and push message delivery. If you're building a mobile site app for say, users in developing countries with very restricted data plans, than using ServiceWorker to control and preinstall cached resources, incrementally update those resources, possibly just by receiving a push notification, and allowing users to browse the site without even spinning up the cellular radio, that will be a huge boon to both the economics of the app in those regions, but battery life too.
These rants don't come with any context of what the alternative is. The vast majority of human beings are now online via mobile as their only mechanism for content. The Web wasn't designed for mobile. It needs updating, and simply thinking we can return to the vision of XHTML Mobile/Mobile CSS circa 2004 era is not going to convince anyone. Either it will encourage Facebook Instant style destruction of the Web, with more and more content moved into proprietary silos, or you'll see something like Flash come back.
Remember, we finally disposed of Flash by upgrading the Web to the point where it wasn't needed anymore.
We don't want a similar situation to occur for the mobile web.
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.
What we need is better app marketplaces with OS integration.
>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.
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.
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.
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
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.
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.
> 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?
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?
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.
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.
Yeah, no, that was awful, and if you're holding it up approvingly, well, now I officially disagree with you.
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.
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.
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 ...
Mine would be next-generation image handling — <picture> tags* and some sort of alpha-blendable lossy format.
I work for a lot of artists and designers, these guys want fast, retina full-screen responsive images, and I’m not sure that it’s an unreasonable expectation, but I’ve got enough technological hoops to jump through to recall the days of “Netscape Now!” and “IE 5” badges.
* don‘t talk to me about the unholy abortion that is srcset
Do the users want those too?
When I get the visuals dialed in a way that is quick and responsive, yes, the users seem quite receptive. I could do a better job for them with better tools at my disposal.
web’s strengths: simplicity, URLs and reach.
I just don't trust native apps. Even a non-malicious app can undermine your systems performance and behave badly.
I've spent too many hours trying to "clean" windows systems, there is just no way I want to be installing native apps on them any more. My windows machines have the OS and its bundled apps, MS Office and that's it.
Windows is also pushing towards sandboxing desktop apps, but look at the backlash that's received. (Although they implemented it poorly - there are two completely different types of apps, and you have to choose one?)
(Also, realistically, installing trusted unsandboxed apps generally goes fine, because if they were malicious you would've heard about it by now)
> screenshot of Microsoft Word in a 14-year old unsupported OS on what is most likely a 1024x768 screen with all toolbars activated
> Navigation Transitions
Seriously? It's like Frontpage 99 again.
I'd rather push the web forward and have it at least stay "somewhat" close to native (no it'll never be better) and constantly learn new features... rather than:
.... have it lag behind native even more and thus create even more pressure on myself, my company, and my career to adopt, learn, and build native alongside web.
Many of the best things about the web are features that we didn't originally plan for but created using javascript and such, then we folded it back in to the specs.
When you add something new, most likely someone somewhere will do something very cool with it in ways we could not have envisioned.
If all those spec writing engineers were told "sorry, the spec store is closed", they might actually get their hands dirty writing code for the current specs. Hell, I might even lend my tired old hands if there were a moratorium on new specs.
Just for fun, I've spent a couple of minutes compiling a list of technologies, just for the backend side of things, which many of us know or have heard of, which ilustrates the complexity and diversity that we have in our industry atm.
It's both beautiful and scary at the same time - how will we be able to move all of that into the future ? How will we scale our brains as we get older ?
So here it goes.
You want to implement something on the Backend ? Nothing can be easier!
Step 1. Pick a language.
C, C++, Go, Java, Ruby, Python, Dart, PHP, Hack, Erlang, D, Xhp, Javascript/CoffeeScript, TypeScript, Perl, Scala, Scala, Clojure, Lisp, ColdFusion, or ASP.NET (C#, VB, F#)?
(https://en.wikipedia.org/wiki/Programming_languages_used_in_...)
Step 2. Pick a framework for the selected language:
ASP.NET, Ruby on Rails, ASP.NET MVC, Django, Meteor, Laravel, Spring, Express, CodeIgniter, Symfony, JSF, Flask, Flex, CakePHP, Zend, GWT, Play, Yii, Sinatra, Tornado, Grails, Struts, Dojo, web.py, Wicket, Bottle, Pyramid, Kohana, Koa, web2py, Yesod, Revel, (fab), Gin, Compojure, Martini, Vaadin, beego, CherryPy, Ring, Scalatra, Mithril and many more (http://hotframeworks.com/).
Step 3. Pick a database:
Oracle, MySql, MSSQL Server, MongoDB, PostgreSQL, DB2, Access, Cassandra, SQLite, Redis, SAP Adaptive, Solr, Teradata, Elasticsearch, HBase, FileMaker, Hive, Splunk, HANA, Informix, Memcached, Neo4j, CouchDB, Couchbase, Firebird, MariaDB, Netezza, Azure SQL DB, Amazon DynamoDB, Vertica, Riak, MarkLogic, dBASE, Ingres, Sphinx, Endeca, Greenplum, Ehcache, Interbase, Amazon Redshift……. http://db-engines.com/en/ranking
Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures.
Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end !
Given that most of these have been created in just the last 15 years or so, what will the next 15 years bring ?
Since the focus seems to be on web backends (given the section following this one), I'd imagine that trying to use C or C++ for such a thing would not be one of the obvious choices.
Also, you've listed Scala twice, I'm pretty sure Xhp and Hack count under PHP, and God help you if you opt to use ColdFusion or ASP.NET (or PHP, for that matter) in anything new.
> Step 2. Pick a framework for the selected language:
Once you've picked a language, you can usually narrow down the selection quite a bit. For some languages it's a bit harder, but for most, the choices are manageable.
C/C++ -> Raphters, CppCMS, WSO2, Wt, ffead-cpp
Go -> Revel, Martini, Gorilla
Java -> Spring, JSF, Struts, GWT, Play, Grails (if we count Groovy as Java), maybe some others that I haven't heard of yet
Ruby -> Rails, Sinatra, Padrino (which is basically Sinatra plus some helpers for databases and views), camping (if anyone actually uses camping in production, please let me know)
Python -> Django, maybe some others (but Django's the only one I hear about regularly)
Dart -> does anyone even use Dart? I'm pretty sure even Google has moved on to Go for backend stuff, and the plan to integrate Dart with Chrome was apparently cancelled.
PHP -> Laravel... I can't think of any others that I've actually seen used. Pretty much every PHP app I've encountered was CGI-based.
Erlang -> YAWS or ChicagoBoss. If you're counting Elixir with Erlang (we might as well), then we can throw in Phoenix and Sugar.
D -> vibe.d is the only one I know of
Javascript -> Node.js, probably.
Perl -> Catalyst, Mojolicious. Or just use (Fast)CGI.
Scala -> Play, Scalatra, Lift, Sweet, Slinky
Clojure -> Compojure, Webjure, Conjure, Moustache
Lisp -> (Common -> Weblocks, possibly Hunchentoot), (Scheme -> SISCWeb (via J2EE)), Racket
ColdFusion -> ColdFusion. I don't know if ColdFusion doesn't instead count under the Java category, though.
ASP.NET -> I dunno, ASP.NET?
Basically, once you have a language picked (based probably on which one looks the best to you), it's pretty straightforward to search the web for "$LANG web frameworks" and find some sort of comparison between them.
> Step 3. Pick a database:
If you're not picking PostgreSQL, then you're wrong, end of story. Maybe CouchDB or Mnesia if you know for sure that you need their replication features and are aware of the tradeoffs of using a non-relational database.
SQLite deserves special mention, because while it's absolutely wonderful for end-user applications, it's not at all ideal for server software except for specific use cases (like using it as an offline data storage format, e.g. for backups or data imports/exports).
MongoDB, Oracle, MS SQL Server, and MySQL also deserve special mention because, if you're using them willingly in a new application (other than to interface with a legacy system that did involve such a regrettable choice), you're probably not right in the head. In particular, there's pretty much zero reason to use MySQL instead of MariaDB (which is also arguably marginal due to its MySQL heritage, but at least it's slightly better), using a commercial database like MSSQL or Oracle is basically begging for vendor-lock-in-related problems, and MongoDB... Jesus fuck-me-in-the-ass-with-a-pogo-stick Christ. Might as well just pipe your data to /dev/null while ranting about how it's "web scale" while we both transform into 3D-animated bipedal animals and I resign from my job as programmer/sysadmin and go shovel pig shit for a living.
> Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures.
If you're smart, you'd go with Cloud Foundry, since a large number of PaaS vendors support it, so you can pretty much just pick whichever one has the best bang for the buck (might I suggest IBM Bluemix?) and use the `cf` tool to deploy to it.
Additionally, if you're using containers of the Docker variety, the vast majority of PaaS and hosting companies nowadays support them with little to no modifications, so - again - the choice matters very little beyond one's priorities regarding performance, location, and cost.
> Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end !
Now that is a massive can of worms. So many frontend frameworks. So little time. And pretty much all of them constrained to the quirks and pains of Javascript.
Of course, you could just go with straight HTML and CSS (plus a smattering of JS using JQuery or Mootools), which is what I generally prefer to do in most cases.
The point was - there's just so many technologies to consider and it's been just 15 years.
When I got my first PC, my choice was: MS-DOS 3.3. QuickBasic, Pascal, C or Assembler for writing programs.
There might have been other stuff, but I had no access to it. Ditto for documentation, tutorials or books.
Things have definetely evolved and if the rate continues, we'll have thousands of languages/frameworks in the next decade, unless something absolutely mind blowing comes up and replaces everything forever.
I'm aware. I just like taking things needlessly seriously. It's a hobby of mine :)
> When I got my first PC, my choice was: MS-DOS 3.3. QuickBasic, Pascal, C or Assembler for writing programs.
Indeed, though those weren't the only choices even back then. Lots of different microcomputers, all with their unique dialects of BASIC, up until the late 80's and early 90's, when the diversity died off and IBM-compatibles became the norm.
Really, the current evolution in software is more just a resurrection of the diversity once strong in the realm of computers. Back then, one would actually have to make conscious choices about CPU architecture of all things; nowadays (for better or worse), we seem to be resigned to the idea of big machines being x86(-64) and little machines being ARM or maybe MIPS.
Not to say that languages weren't diverse back then, either. You still had Lisp and FORTRAN and COBOL and Forth and C and assembly and PL/I and ALGOL and Pascal and Logo (turtle power!). A little later there was C++ and Perl and Tcl to join them as some others faded out.
Basically, the evolution now is less about the quantity of platforms to develop for and more about the accessibility of those platforms. Pretty much all the good ones are open-source, available on the internet, and have plenty of online documentation. The free software and open source movements have been a boon to those seeking to get their foot in the door.
> unless something absolutely mind blowing comes up and replaces everything forever.
I suspect that "something" will either be artificially intelligent or pretty damn close to it. Development time and effort will decrease substantially if a programmer can just tell his artificially-intelligent software maker what the program needs to do - in a natural language - and the software-maker goes and makes a program. I suspect there will be a couple of stepping stones before that, including some existing stepping stones that we've already walked on. One of them is LLVM, providing a common core that any language can use with relatively-few obstacles. Another is the concept of programs that create other programs; languages like Ruby, Tcl, and Lisp facilitate this quite well, and it's probably a matter of time before those and similar languages are used to do things like automatically generate HTML/CSS/JS for web apps (as one example of potential usefulness in the short term). Natural language parsing by artificial electrical systems is getting better and better, too.
The Web is an ephemeral enterprise.That's why everything relevant has a DOI and not an URI.
Hardware accelerated Canvas 2d graphics and Web-sockets are the two I'm most excited about because they are now stable across most browsers.
quirksmode.org used to be a great resource but it stopped being updated 10 years ago when IE 6 was still the "thing". Nowadays, http://caniuse.com replaced it.
So quirksmode transformed to a rant blog, like this one we had on HN three months ago: http://www.quirksmode.org/blog/archives/2015/05/web_vs_nativ...
As we say here, the dogs bark but the caravan moves on.
We realize you are a mobile consultant, and standardizing many features in a cross platform is a threat to you and your client base. But getting on your soap box and telling people to not add features to browsers is unhelpful and myopic.
Not everyone uses your stupid mobile platforms. Some people in the world don't even have a phone at all. But they might be able to use a browser once in a while. Do they not deserve features just because you have decided that it would be too difficult to implement in the browser, and will "never be as good as native" or however you put it. Your failure to see how things could be implemented faster/better/cheaper does not preclude others from actually getting things done.
I actually agree with many of the points that you make, but seriously... try to see the forest for the trees and take a look at what you're asking of people, and ask yourself why you are doing that.
What I see is an immature community that cannot make up its mind. I see fads, I see awful tools, and even more awful tools that try to fix the awful tools. I see standards committees that pump out unimplementable garbage and I see device manufacturers who think they are good at writing software (and they are not). I see very bad, widespread and unpatchable security holes. I read, every week, about the latest fad thing that will fix all your problems, just install a list of 30 packages and suffer per-page downloads that are larger than the native apps this mess is trying, badly, to replace.
I guess this will all shake out. But in the mean time, I am shaking my head.
The Firefox and Chrome developers are mostly certainly professional developers who are well qualified to create a standardized cross browser feature set that will obviate the need for the cruft.
Only recently have we started to emerge from the Silverlight-Flash-JavaApplet-ActiveX-webish ghetto that we were mired in for years as Microsoft refused to add new standard features to IE. His suggestion is essentially to return to that paradigm. He should know better... he built a site called 'quirksmode' after all...
His suggestion is to stop, and wait.
Spend a year on standardizing, fixing bugs (like the bug with chrome where it sometimes just "forgets" float-css rules), a year spent on improving issues and making everything behave consistently between browsers.
A year spent so that we won’t have to use jQuery afterwards anymore. Or underscore.js.
A year spent on fixing all the little bugs, and making a consistent roadmap where we actually want to go. Thinking about stuff like the Virtual-DOM of Angular or React and finding a better solution than that.
This is what we need to focus on. Making stuff behave consistently. And with one year, we can make sure that afterwards most of the market will actually use our new version. We can finally get rid of all the polyfills.
Newer HTML/CSS standards appear to be defined in a somewhat compartmentalized fashion. I'm doing an app rewrite in Angular, and its actually working pretty well so far (1). It's much snappier than java/struts, and we are able to convert the legacy code into REST services for future product integration work.
The author mentioned horrible Chrome documentation. Mozilla / Firefox has EXCELLENT javascript documentation, including listing MS IE compatibility to save you the trip to the MSDN swamp.
Much of this is overkill for "pages", but not for "apps".
(1) "pretty well", with exception of IE, of course -- even 11 won't gzip or cache static files. At least IE 8 dies in Jan 2016, though.