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)
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.
>This sounds cool, but why would we want to do that? We’ve done without for years. More importantly, end users have done without for years, and are quite used to a slight delay when they load another page.
The damage caused by the lack of Navigation Transitions in web browsers has made the news repeatedly for decades. My great grandfather died in the hospital after he was crushed by a non-animated change to a different webpage.
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).
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.
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.
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.
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.
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?
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?
> 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.
> 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.
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.
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.
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.
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.
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 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.
> 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.
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...
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.
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.
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.
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".
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.
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.
> [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.
> 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.
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.
> 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.
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 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]
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.
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.
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)
> 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.
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.
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.
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.
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.
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.
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.
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?)"
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
"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.
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.
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.
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.
> 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?
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.
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.
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.
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.
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.
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.
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".
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.
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%.
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.
> 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.
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?
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.
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 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?
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.
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?
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.
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.
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".
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.
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.
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?
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.
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)
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.
> 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.
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'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.
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.
> 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.
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.
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.
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).
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.
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.
“Everybody will have a favourite upcoming feature that would be hit by the moratorium — mine is offline capabilities.”
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
> 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.
Do users want cellphones with 64bit CPUs, 1gb DDR4 RAM and an SSD, or a phone that turns on instantly and has near perfect responsiveness?
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.
You know what I want? I want a tag that I can use like <img> but more flexibly- I want to manage cache and authentication on images displayed in-browser, and the fact that I basically have to use URL or Cookie auth for image embeds is ridiculous. My entire API uses tokens, except for when it deals with image resources (and those images need to be protected to only display in the correct place, because they're not pictures of cats, but Highly Sensitive pictures of Important Cats).
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.
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.
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've spent the last two years doing "full stack" [yeah, those words, sorry . . . but going from bare metal to C++ to PHP/JavaScript to frobbing routers all on the same day probably qualifies], coming from a background of C/C++ driver and native code development for 30 years.
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...
Can I sing a few praises for the ghetto for a minute? It had more features. It was friendlier to non-developers because of things like Flash. It had more features. You could directly port native code through things like ActiveX (which we are now only recently getting back through ASM.js, with performance within an order of magnitude). It had more... you know where I'm going with this. The problem with that paradigm is the rise of resource-constrained mobile devices and security issues. But I'm unconvinced that the new paradigm won't just regrow the security issues and the performance problems as the features catch up.
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.
You're missing my point. The world won't stop just because you decide to reflect on the situation and have small groups of people unilaterally decide what will someday maybe be standardized in some browsers. In the meantime the new features will get developed as non-standard features and you'll have even more proliferation of cruft, "polyfills" and whatever else PPK is complaining about.
I have also been doing software for a bit over 2^5 years, and the glass IS half empty. But, it's also half full.
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.
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.
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.
Things like webRTC are the real push forward. It turns the browser to an operating system that can do everything a native app can do. I agree about the attempts to mimic "cool" animations from iphones - that's just cheap.
301 comments
[ 5.3 ms ] story [ 261 ms ] threadhttps://www.python.org/dev/peps/pep-3003/
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.
People were used to dying of typhoid, too.
The damage caused by the lack of Navigation Transitions in web browsers has made the news repeatedly for decades. My great grandfather died in the hospital after he was crushed by a non-animated change to a different webpage.
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?"
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.
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.
Also, from the page ppk links to:
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?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.
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.
I've heard that some users have both a phone and a laptop.
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.
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.
Beyond that is the fact that Swing was fugly everywhere, and bootstrap looks decent everywhere.
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.
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>.
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.
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.
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.
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.
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.
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.
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.
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.
Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.
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.
And it does this a lot better than the browser.
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.
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.
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.
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.
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.
https://blog.mozilla.org/luke/2015/06/17/webassembly/
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.
[1] http://s3.postimg.org/53784icoj/afterlink.png
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. :)
[1] https://www.google.co.uk/design/spec/animation/meaningful-tr...
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.
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.
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.
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.
(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
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.
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.
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.
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.
> 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.
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.
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.
> 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.
Isn't that the point? To slow this down because perhaps the people driving "innovation" are insulated from its disruptive effects?
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.
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.
http://c2.com/cgi/wiki?WikiWikiWeb
>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.
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.
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...
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.
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.
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)
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.
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.
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.
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).
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.
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.
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.
The Web is an ephemeral enterprise.That's why everything relevant has a DOI and not an URI.
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.
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.
What we need is better app marketplaces with OS integration.
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.