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.
Stop pushing the web forward
51–60 of 307 posts
Re: Stop pushing the web forward
#52> 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 try…
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…
>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.
Re: Stop pushing the web forward
#53For comparison, see "Python Language Moratorium". I think its outcome was positive. https://www.python.org/dev/peps/pep-3003/
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)
Re: Stop pushing the web forward
#54> 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 try…
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 cod…
Oh, so a dumb terminal. Ok. It's 1980 again.
Re: Stop pushing the web forward
#55For comparison, see "Python Language Moratorium". I think its outcome was positive. https://www.python.org/dev/peps/pep-3003/
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.
Re: Stop pushing the web forward
#56As 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 availa…
Good call. Basic numeric and date/time types need work. I don't really need "Java-fication" syntactic misfeatures.
Re: Stop pushing the web forward
#57As 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 availa…
>What JavaScript needs much more IMO is a (better) stdlib, with more datatypes and procedures than currently available (including big numbers, the various flavours of trees, etc). Isn't that "pushing JavaScript forward?"
Agreed. However I think to build on his argument, we should push JavaScript forward in a targeted fashion, based on its intended purpose.
Level 1: There are known huge missing chunks of JavaScript that should be resolved as they severely limit the power of javascript as a development platform which lives in a network application.
For instance modules, promises, etc...
Level 2: There are known huge missing functionality which are missing which are well known elements of a sane UI framework which should be implemented because bottom line javascript is a UI scripting language.
For instance properties and some kind of observable mechanism.
Level 3: IS all the highly subjective and often syntatic sugar intended to make javascript work more like other programming languages like C# or Python.
For instance classes,. arrow functions, generators, let statements...
Generally the problem is the focus seems to be completely skipping Level 2, to get to Level 3.
Re: Stop pushing the web forward
#58> 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 try…
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…
There's a standard for most things happening in a browser
There's POSIX, too. In practice, divergences are plentiful.
Differences among current browsers are more among performance and experimental features
The fact that are huge web tables meticulously documenting feature compatibilities across browsers implies differently.
Besides, a lot of web standards are done post-facto. I don't see the situation as being any better than POSIX. It might even be worse.
Re: Stop pushing the web forward
#59> 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 try…
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 cod…
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.
Re: Stop pushing the web forward
#60PPK, I'm sorry but you are midair, directly above the shark on this. Its not too late to change course though. We realize you are a mobile consultant, and standardizing many features in a cross platform is a threat to you and your client base. But getting on your soap box and telling people to not add features to browsers is unhelpful and myopic. Not everyone uses your stupid mobile platforms. Some people in the worl…
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 a…
This is the problem with what PPK is suggesting.
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...