So... it's 2013, and I'm sitting here with my blazingly fast nexus 4, and the web sites I visit are... slow. terrible. broken. spammy.
Half of them have 'popups' that try to banner at the bottom of the screen, but end up flailing wilding and either taking up the entire screen, or just helpfully sitting exactly over the middle of the page. A lot of them try repeatedly to direct me to a specific page, or a native app when ever I flick between pages.
The links are tiny and impossible to click on without zooming in.
It's just a terrible, terrible experience.
How do we get from this broken UX experience story of right now, into the magical compelling 'mobile web app' future that OP talks about?
I worked as a front-end developer for an adnetwork for two years, so I take a little responsibility for your experience. I tried my best, but there just wasn't that much interest in getting it right.
Here's why I think we're all having a hard time with advertising in mobile. Basically, adnetworks are still learning how to do it right, the same way designers and developers are still learning how to do mobile websites right. The layout issue you mention comes from a conjunction of various reasons:
* Marketing thinks mobile == iOS, which sets limited expectations and for example means developers have a hard time getting a variety of devices to test on
* Adnetworks are likely targeting mobile with the same front-end infrastructure they use for desktop. Most of them still target IE6 so they're trying the same ideas
* Old iOS versions and many other webkit browsers have big issues with fixed positioning. First they didn't support it. When they did, they still had issues rendering while scrolling and firing the correct events
* Ads in mobile require a complex layout but the standard in the industry is that the website doesn't have to do anything but insert a script tag in the page. If there was teamwork between websites and ads, they could use better layout tools like flexbox
Rooted Android phones can install apps[0] that block most ads (I think it only blocks connections to the ads and doesn't do any fancy CSS rules).
And Firefox on Android has Adblock Plus browser extension which as far as I know blocks ads like it does on the desktop version. No root needed for this.
When I open an app or browser on my smartphone, I'm usually focusing on a single task, where ads are intrusive and take away precious real estate from an already tiny screen. It's an enormous relief to use an app or site that just does what you want it to do and nothing more.
Ironically, it's on my smartphone that I'm most likely to use an app that's completely focused on advertising. When I'm looking for a movie or nearby restaurant, I love being able to read reviews and eventually move on to a dedicated web page where I can get more info (movie times, menus, etc.). There are apps that do this very well.
There are plenty of ways to get consumers to happily view advertising and promotional material, but inserting unrelated/unwanted ads into apps and websites just creates a frustrating user experience, especially on mobile.
I'll provide a different option: it takes too much time to get it right! iOS for example provides so many default widget toolkits complete with gradient, sheen, and dropshadow which make it really easy to create a polished experience quickly. The web has no such concept (well, bootstrap is sorta close but not nearly as polished and not for mobile). Why does the web not have these polished frameworks? Simple - ROI. The incentive for Apple and Google to develop said frameworks is large: a pool of developers who will take advantage of the toolkits and write much better / way more apps. What's the incentive for the web? Basically nil. Anyone can rip off what you did (one of the downsides to the web being open and standardized!), and you gain none of the benefit of enhancing your platform.
It does have them. There are many toolkits that provide components for the web. Bootstrap is just one of them and one that has been getting a lot of publicity here for a while because it's new and has a nice design. But there are many out there that cover different aspects of mobile web development: YUI, Sencha Touch/ExtJS, Dojo, jQuery UI/Mobile, Enyo...
And pre-made toolkits still require you to tinker with them to get layouts right, make them fit your design and make ads work OK in them. That's true for both the web and native toolkits.
Frankly, if all the ad networks in existence fall over and die from their own crudulence, I'll not shed any tears whatsoever.
Any site that uses crap ads that affect my user experience will really have to be something special for me to continue to use them. I'm happy to leave these sites for other sites that don't do stupid things to users.
You (as with most of us) probably spend so much time on the web now, shuttling around many many different websites, that you don't notice (or remember) that a large proportion of the myriad of native software, beyond a few well polished examples, exhibits flaws that while different are just as annoying, slow, buggy and otherwise irritating.
Bad websites are just like bad software. There's a chance that my making it easier to create apps there will be an increase in bad ones, but there should be an increase in good ones as well. There has been on the web.
I think a good way or restating your point is that, the better web gets i.e. more advanced frameworks with better testing suites, the harder it is to screw up.
A point I'd like to make:
At the end of the day though, mobile _can_ be fast, but it just doesn't compete with native, yet. When I take a web project after concluding an iOS app, I miss being able to run tests and deploy to my phone or iPad in one place and easily. I miss how formal native code feels over a javascript stack. I hope this changes one day, and I love what Firefox OS is promising, but until then, I will be working with native solutions.
And this doesn't even mention the pain of actually MAKING such a webpage. HTML5/javascript/css are, to put it blunt, rubbish and antiquated technologies. Why even force people to use this "boxed" and shit set? Firefox OS is just wrong from so many perspectives..
Not at all. Dead serious. If HTML/CSS/javascript had been properly developed we wouldn't even have to deal with all the issues surrounding web dev. All these issues have been addressed by OS development decades ago (e.g. duplex connectivity, UX layout, MVC split, performance, just to name a few), yet we still have to deal with them now. Million of man-hours have been wasted due to them.. So no, this is not trolling.
Mobile apps have been an absolute blessing and finally enabled proper mobile development. I don't see a need to go back to html other than legacy..
I actually use http://cheeaun.github.com/, which is entirely web based and works wonderfully well. No updating of the app required, no mini-browser within the app, etc.
Mobile apps have made it possible to write your app once and have it work on multiple platforms? Gee, I must have missed that (as I post to HN, a web app that works on multiple platforms).
Don't kid yourself. Anyone writing web app "once and have it work on multiple platforms" is just writing different workaround for the different platforms into the same codebase.
HTML was created to markup structure of the document, CSS was created to style the look of that document. JavaScript was created to add some interactity. The idea of the HTML web was about documents, not apps.
Now compare that to the native SDK's which were created for apps develpoment and specifically targeted to solve specific problems. Anyone claiming that web technologies today or tomorrow will be a good replacement for native SDKs has very little idea about native SDKs. Myriad of frameworks trying just so hack some MVC with webtech is a good indicator about the suitability for the task.
Sure, with enough time you can bolt-on enough feature on the top of HTML and JS to make it bearable for apps development: but it will be just that — stuff bolted on the tool created to solve completely different problems.
I don't know why looking at every problem like a nail just because all you have is a hammer is suddenly a good idea.
> I don't know why looking at every problem like a nail just because all you have is a hammer is suddenly a good idea.
Uh.. because it's cross platform. The ubiquity of the web is literally the only reason why people use HTML/CSS/Javascript. All your points are valid except for the fact that you are blatantly disregarding the single biggest downside of native development: multiple-platform support. I'm sorry, the world isn't made up entirely of iPhones or Android phones.
If only I could write web documents in yaml + python.
I do agree, and I hope people aren't downvoting you like crazy, because the only reason html/css/js exist is because it is entrenched. Same reason people use C and C++. They both took a market you can't easily shift away from (by both being effectively an ABI) and are now indisputable.
Fuzzy XML with a curly braces C style semicolon delimitered design language? A programming language with no standard library besides a math module, so your website ends up being 3mB of JS libraries and 100kB of actual document?
Though I wouldn't say mobile apps are absolutely a "blessing". The Android XML + Java morass is barely a step above html + javascript, and I'd argue it has even less productivity. I end up getting the most freaky bugs in layouts trying to get them working on multiple devices and waste so much time on that blasted syntax.
> the only reason html/css/js exist is because it is entrenched
It wasn't entrenched in the mid 1990s, heck, it arguably wasn't entrenched into the early 2000s when some people were trying to move apps to *ML, or another VM besides the one that failed in the 90s. None of the alternatives won out.
I'm not going to argue that making in-browser apps is a walk in the park, but I do think that a lot of people making arguments about how app development was a solved problem for native OS are both (a) overstating their case (b) seemingly blind to the advantages that html/css/js have along with the liabilities.
Making firefox os is great, but how do we get from here to, people making web apps that don't suck on mobiles?
Is it a market place they're going to sell apps on and curate so they're no rubbish?
Is it a platform that is so great and compelling people are going to stop making native apps for it?
Is it a new browser that is so amazing they everyone is going to swap to it, and it makes web apps responsive and amazing?
Is it an entire 'platform' that runs inside a browser?
A native app that acts like it's own 'OS' that runs on all phones?
...you get the idea. What about firefox OS is going to change anything? I'm not trolling, if you can figure it out, tell me, because then I'll pitch it, at work, and we can start down that path.
> Is it a platform that is so great and compelling people are going to stop making native apps for it?
I think that's the idea, yes :)
> Is it a new browser that is so amazing they everyone is going to swap to it, and it makes web apps responsive and amazing?
Browsers are already pretty cool; what's good for Firefox is what's good for the web (including webkit browsers). Since Firefox is pursuing consensus and standardization with all their new phone/browser ideas, it should be easier in the future to write cross-platform web/phone apps.
> Is it an entire 'platform' that runs inside a browser? A native app that acts like it's own 'OS' that runs on all phones?
It sort of is a broswer. It provides a bunch of APIs that make it possible to control phone functions from javascript. So you load a web app, and it can make phone calls and send texts and take pictures and whatever. In this video you can see the app launcher and the phone app written in HTML, CSS, and javascript. http://cnettv.cnet.com/hands-mozilla-firefox-os-boot-gecko/9...
By making the browser a true platform-a "first class citizen"-it will no longer be "that place you have your blog" and most app makers won't have to decide to go "web" or "native" (and make a different app for a growing number of phone OSes) because they'll be one in the same. It means people will care more about the web to begin with.
If that happens, we'll see more mobile OSes being created, competing and innovating because you've solved the "chicken and the egg" problem with apps. Devs won't stay with the Big 2 simply because that's where the customers are, because the customers won't stick with a phone OS they hate simply because that's where the apps are.
What I find interesting is how much the trend in mobile resembles the PC/Web boom. Ten years ago everything you did on the PC besides browsing required its own software. Not so true anymore, huh? I hope mobile continues to follow the PC's trends and make this happen next.
> So... it's 2013, and I'm sitting here with my blazingly fast nexus 4, and the web sites I visit are... slow. terrible. broken. spammy.
No, your browser sucks. Because there is virtually no competition among browsers on mobile. The vast majority of users never even think to use any but the default and therefore there is little incentive to make the big improvements they need.
While a lot of the web is still horribly broken on touchscreen devices, it should be noted that the situation is getting better.
The popularity of iOS and Android devices means that a lot of even regular websites now have to pay attention to responsive layouts, large input elements, etc.
Of course, there is a lot of web that updates slowly, HN included. Getting all those on board the modern, responsive web will probably take years.
But having used touchscreen devices daily for browsing since early 2006, the situation is clearly improving all the time. Popular CSS frameworks like Bootstrap help, too.
>You are on a site that is not broken, slow or spammy.
Is this sarcasm? I honestly can't tell. You have never experienced the expired link error? Or the 'site not available' error? HN is one of the most broken websites I frequently visit.
Also you ignored the part about tiny links. HN is full of tiny links: have you used the site on a phone and tried to upvote a post?
I surf this site on my iphone daily. Yes I occassionally downvote something I did not mean to, yes dead link annoys me if I lose what I typed. But the user experience of sharing and gathering opinions of intelligent well informed people from all corners of the world and backgrounds more than compensates. IMO of course.
And thats what I mean - Craigslist is the other "broken" site that does UX well. Its not meant to be pretty or responsive - its meant to do what I expect it to do.
If pg decided to fix the broken CR/LF issue, he might be tempted to add bootstrap, and then make it responsive, and then have a feedback form. So I quite like #lazilyproductive
My experience of HN is mostly reading the content.
The User Interface is the text box, the outstanding orange/grey theme. But the experience is, upvote buttons that are too small to use well, and great insightful posts from clever informed people. Also me.
It works reasonably on my Dell Venue Pro with Windows Phone and IE, though there are a few glitches when long comment pages don't word wrap. But I've been using HN on my phone for almost two years. Having a hardware keyboard helps - my Nokia brick had one too.
Short version: "If you're not paying for it, you are the product, not the customer".
Most of the sites probably don't have a big incentive to make a really awesome mobile app type experience, which would involve zero ads, and a lot of work to make the site work like an actual app on a variety of target devices.
Except for the ones that aren't slow, terrible, broken, spammy. Selection bias at its finest. I could open up a random sampling of native apps from the Play or App store and make the same ridiculous claims about how lame native apps are - because 90% of native apps are complete crap.
shadowmint asked: "How do we get from this broken UX experience story of right now, into the magical compelling 'mobile web app' future that OP talks about?"
How about: by paying for content?
Right now, websites are so messed up (and not just for mobile) because of ads essentially. The content providers want you to look at them, and you'd prefer not to. Unfortunately, 99% of the time, there is not even a way to pay and get a good experience instead.
Look at it this way, the only people making money off of my internet usage is my ISP. Actually, I also pay yahoo $20 a year for ad-free mail, but that's the only one. Until that changes, the ads will continue. The industry needs to figure out some sort of micro-payment for content, because nothing else works.
And if your problem is with JavaScript as a language, you can already use a myriad of languages that reliably compile to it. Do you come from a Java background? You’ll probably like Dart, from Google. More of a functional kind of developer? Try ClojureScript, which is an impressive, well-maintained and well-performing implementation of Clojure on top of JavaScript. Coming from Ruby? You’ll be almost at home with CoffeeScript. You get the picture.
God no. Instead of having to use a single awful language all the time I get to choose what language to transpile to javascript and I never have to look at or think about javascript at all. Unless of course there are bugs and then you get to experience the pleasure of debugging machine generated javascript. Maybe some people are filled with joy by the thought of debugging generated js, all I can say is that those people are certifiably insane.
How about we work on platforms that support more that one language as first class citizens. Is that really such a crazy idea in 2013?
How does this differ from debugging any other VM? Except in Javascript you're almost guaranteed your 'crash' will come as an exception with a stack trace – guaranteeably raised by the only executing single thread that could contribute state to the crash.
Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I'd much rather debug a JS exception than the subtle mental math required to statically analyse the stack operations of some assembly.
>Debugging a Java or a C crash in infinitely worse, since instead of comparatively pretty symbols and a verifiably correct stack trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers
My experience of crashes in C is that the OS typically provides a decent backtrace including function names, not just a 'vector of bytes'. Your millage may vary, I expect it depends what kind of C you are writing on what platform, if you strip symbols etc. Sure your memory could get totally trashed beyond recognition but that has not been very common in my experience. I'd like to point out that I was not advocating writing C. I've not used Java but I always assumed it gave you decent stack traces.
>instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I've honestly no idea what you are talking about here. Java code swamped in gotos?
>I for one would much rather debug an exception in JS than the mental math required in statically analysing the stack operations done by a chunk of assembly.
If I'm writing Python I want a Python exception. If I'm writing Ruby I want a Ruby exception. Not an exception from JS code that I did not write. I have no idea what 'mental math' has got to do with this.
On many architectures almost any stack overrun will overwrite the frame pointer in C, resulting in a corrupted stack trace.
As mentioned in my second comment, I slightly conflated what C and JVM crashes look like – the comparison was poor.
> I've honestly no idea what you are talking about here. Java code swamped in gotos?
Yes, the JVM has goto and your favourite compiler probably emits it, it's just not exposed in Java. If we're to compare the similarity of debugging a crash on the JVM to one on the "JSVM", then we cannot discount the complexity of the toolchain producing the target JVM code. If we assume that toolchain is bug free, then we must also assume a similar compiler targeting the JSVM is bug-free. At which point the OP should not discuss trying to debug Javascript – in this scenario it should never be required.
If instead we assume the JVM compiler and the JSVM compiler are not bug-free, then we must account for the debuggability of their languages. In the JVM one works in terms of stack offsets and goto (see http://en.wikipedia.org/wiki/Java_bytecode_instruction_listi... ) while useful constructs like "string key -> Object map" are totally missing (aka. a Javascript object), and all complex expressions are lowered to a long series of basic instructions, all involving stack manipulation.
In contrast a JSVM-targeting compiler can emit human-readable expressions and control structures, has no access to goto or stack manipulation instructions, and short-term architectural choices about how those constructs are further lowered is not baked into the language. Each individual implementation can choose their own approach, and improve on it in the future without requiring recompilation.
The result is that given a bad toolchain (and currently the JS transpilers really are all quite bad, and JS lacks some trivial features like source maps), the JSVM is an inherently more human-friendly debug target with less assumptions about the runtime environment. By now it should be clear that to compare you must discount the short term comparitive maturity of existing JVM compilers – an excellent idea when making long term architecture decisions. Additionally since in JS there are no threads contributing to shared state, code flow is also easier to understand.
[Edit] If we're to discuss anything like supplanting Javascript as the language for the web in the long term, let's not resort to 1980s architectural notions about static, totally inaccessible binary formats. Approaches like PyPy are far more interesting – given a minimally modified existing language, annotate it such that an implementation can build an optimizing interpreter for any language implemented in that existing language. Imagine Javascript being that existing language, and suddenly all the upheaval and backwards compatibility destruction disappears. Your JS-authored language interpreter could still function in old browsers, it'd just execute more slowly.
Maybe eventually we will have 'sufficiently smart transpilers' and interactive debuggers for languages that target javascript and don't expose the 'JSVM' but that is not the case at the moment. Mozilla said "And if your problem is with JavaScript as a language, you can already use a myriad of languages that reliably compile to it", i.e. if you don't like javascript you don't need to use javascript. This is what I was responding to, because I don't see it being true in the near future (next several years at least).
Right now source mapping is only working between uncompressed/combined JavaScript to compressed/uncombined JavaScript
Which was exactly my point. The tools for targeting javascript from other languages are non-existent at the moment, never mind mature enough that I would want to rely on them in production.
As an aside, am I the only person who reads things like this and is filled with a sense of foreboding:
The spec mentions cross site script inclusion issues that could arise from the consumption of a source map. To mitigate this it's recommended that you prepend the first line of your source map with ")]}" to deliberately invalidate JavaScript so a syntax error will be thrown.
> How does this differ from debugging any other VM?
You can run a plethora of languages on the JVM and get full debugging support - i.e. an application crash will show you where in your code things exploded, rather than showing you a trace into generated code (or more applicably in the case of the JVM, bytecode).
> Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I don't have a huge amount of experience of debugging in C, so I cannot comment on how accurate your statement is for C, but for Java it is absolutely not true. That scenario bears no resemblance at all to debugging Java applications.
To be pedantic - you can't put Java and C crashes together unless you mean JVM crash. If I dare say - Java stack trace information is much better than JS stack traces.
Sorry, I'm conflating my own crash experiences. :) You're totally right, a JVM and a JSVM can crash in horrendous ways, but 99% of the time you'll get a nice stack trace.
Even without source maps it is not such a big deal as people who have no experience using cross-compilation would think. I write a very big game engine with GWT (http://www.webworks.dk/enginetest) and have no problems debugging. Clients send neat stack traces back to the server and I can even obfuscate the application code and using symbol maps deobfuscate the stack traces on the server.
True. I think it's also important to recognize the points against including many languages on a phone, though. A lot of the power of mobile applications derives from their integration with a standardized event system integrated in to the phone. Maintaining such a beast at low latencies and in a well-tested state across multiple languages is not exactly desirable overhead. Then there's the space concern, relative difficulties providing cross-language-platform sandboxing/security, etc...
"How about we work on platforms that support more that one language as first class citizens. Is that really such a crazy idea in 2013?"
That was the nice things about the BBC Micro computer, you could code in Assembly and BASIC right out of the box. Since then the trend has been towards ever higher layers of abstraction. Even in python you sometimes still get indecipherable OS level error messages, but most of the time the tools work well.
It would be nice to have other languages in the browser, but at this point it seems as likely as python built into the processor. At least something compiled to JavaScript is unlikely to be any less secure than JavaScript on its own.
One of my 'things to do: not urgent', includes porting all the examples from 'Practical Programs for the Acorn Atom and BBC Micro' to JavaScript.
I checked, and yes, there is an accessible developer console even in Chrome on my Chromebook, so it seems fitting that programs designed to teach the basics of programming to one generation, should be brought up to date to be used to teach another generation.
Ok so is the solution a standard bytecode for browsers ? Or is is NaCl ? Or PNaCl ? Or something like Hypercard ? Or do we tear down the monoliths that browsers are in small Unix-style components ?
"uzbl-core: main component meant for integration with other tools and scripts
- Uses WebkitGtk+ for rendering, network interaction (libsoup). Css, javascript,
plugin support etc come for free
- Provides interfaces to get data in (commands/configuration) and out (events):
stdin/stdout/fifo/unix sockets
- You see a webkit view and (optionally) a statusbar which gets populated
externally
- No built-in means for url changing, loading/saving of bookmarks, saving
history, keybinds, downloads..."*
Compare Javascript and Java Bytecode. The respective virtual machines are IonMonkey,V8,etc vs Hotspot,Harmony,etc. All those VMs are pretty portable across various architectures and operating systems. The syntax is C-like vs binary stack machine code. Both languages come with a documented standard, reference implementations, and standard libraries.
Sure, Javascript is somewhat harder to parse than Java Bytecode. Java Bytecode usually runs faster. However, from a high-level software architecture perspective there is not much of a difference. And the parser is usually not the performance critical part in any VM.
I never said it doesn't run in a VM. JavaScript is not bytecode. When the code is run, I grant you that you that the JIT will compile to some sort of bytecode. But you can't take that bytecode and run it under any virtual machine.
As for bytecode "running faster", that's entirely up to the JVM implementation. Given a feature complete JavaScript bytecode, I don't see why a JVM needs to be faster than the JavaScript VM.
You may be conflating the JIT nature of JavaScript vs fully compiled Java apps. With JavaScript, it interprets (even compiles) as it gets the JavaScript code, whereas Java code is already compiled into bytecode.
The V8 engine [0] compiles Javascript to assembly. Maybe it uses some other intermediate representation internally, maybe not. Why would you want to use bytecode for some random VM as internal representation?
You can run Javascript anywhere [1], why would you want to compile it to some portable bytecode?
The situation is better in Dart than in languages that only compile to JS, because during development you're usually using the VM and don't have do deal with the translation. If you have an error, you have a full debugger and nice stack traces to diagnose it.
If there's an error in the dart2js output that doesn't occur in the VM, then it might be a bug in the dart2js compiler. That would be unfortunate, but the goal - backed by a very large test suite - is for that not to happen. If it does, then source maps can help.
Why is nobody building a second kind of browser, one which is not based on html and css. A browser which is geared towards app execution and development. A browser which can run apps which can be programmed in a way that is similar to programming Android apps. Where I can for example have a footer without doing some css hacks.
DNS and most of our backends could still be reused but the client stuff would have to be written again.
Delivering apps and linking between them like the web does is awesome. Building sophisticated apps is not awesome but on Android and iOS it is. Why not take the best of both worlds...now....not in 10 years when some standards might agree on something. Just think about how very important the web is. Everyone is using it. The whole world largely depends on it, but it's increasingly not up to the task.
And why do web developers seem to be so satisfied with the state of the technology which drives the web. Oh, you think css is great because you can code a hack for putting a footer on the bottom of the page even when there is no content in the attention area? What? It's so strange.
Why has nobody ever tried to create such a browser?
To everyone saying that this has been tried and failed with Java Applets / Silverlight / Flash: what those technologies did was try to shoehorn app-like environments into the browser, which of course annoyed users because it broke all kinds of expectations when compared to visiting regular HTML pages.
What I (and I think, the OP) have in mind is an actual 2nd "browser". A different standalone app. I envision something where "webapp" authors can post manifests at URL endpoints which define the UI and behavior (not unlike styling in Android), and this 2nd browser will "render" the webapp using native widgets and controls. This brings with it a number of things:
- OMG! The basic keyboard shortcuts all my other native apps have are now available, instead of some poorly hacked-together javascript-detected version
- Rich user interaction with the app and the controls is now a first-class citizen - no more weird highlighting of the entire page, or unexpected popping-up and disappearing of elements on misclicks
- Right click can actually be used, without hacks!
- Opening a new "window" with a new app actually creates an OS-level window with the icon and name being the webapp's favicon - furthering the notion that you're actually using an app and not visiting a website.
- It still retains the main advantages of the web - it's cross-platform and ubiquitous (and users don't have to go through the hassle of explicitly installing and updating native apps)
- I'm sure developing highly interactive webapps for this platform would be a lot simpler, more fundamentally sound, and more enjoyable than the huge hack that is HTML5/AJAX now
- etc etc
It would really surprise me if nobody has thought through this idea in more detail than me, or if there isn't someone out there working on something like this already...
It would have to be huge piece of software, and nobody would use it. That is, it would be very difficult to get adoption. That said, some of us are thinking about it.
It seems like this ought to have made it onto PG's list of frighteningly ambitious ideas.
Not 100% sure what you mean, but wasn't Java ME a portable solution, a platform geared towards app execution and development? And in a limited sense it even succeeded...
Not sure I want a 2nd iteration though.
Java ME doesn't have any of the advantages of the web. Like links or being searchable and so on. It's just another app environment. I am talking about combining the advantages of the web (which is not css/html) with those of successful app development platforms.
Your way has been tried, by not one but two companies. Their browsers were called IE4 and NS4, and the blame for the Web "not being up to the task" is pretty much entirely theirs.
The language issue ultimately leads you to conclude that we need a browser with a built-in VM, rather than a built-in scripting language. It makes so much more sense, as a clean and elegant solution.
"I know! I'll make my own new browser with an embedded VM and newer cleaner APIs, and revolutionize the web! It'll be amazing, allowing native-like performance from the browser. WebGL will finally achieve performance feasible for high quality games, the need for full native apps would be tremendously diminished, etc. etc."
JVM is a well known example of a cross-platform VM, which tried to enter the browser via Applets. I think Java Applets failed because they were slow, ugly, clunky, and usually looked horrible and disturbed the web experience. Kind of like flash ads, but worse.
Microsoft Silverlight is kind of similar, but using the CLI rather than the JVM. As a plugin, it still wasn't seamless. And it had cross platform compatibility issues (not a fault of the CLI though).
The GUI issue (bloated DOM, hacky HTML/CSS) leads me to conclude that we need a new API stack for rendering GUIs that satisfies both web and application use cases without massively sacrificing memory and performance like the DOM seems to excel at.
But here's the thing:
Creating a new browser with a new VM and new GUI stack, all from scratch, is almost an insane undertaking. Sure, it's one I could almost see myself trying (being a perfectionist ADHD OCD coder) as a hobby, but I know better than that if I want to actually ship anything.
Ideally, I'd like to see some day a kind of "Mono Browser" - a browser that basically runs CLI code "scripts" in an otherwise traditional HTML/CSS stack for backwards compatibility. But the primary feature would be a new GUI stack completely disjoint from HTML/CSS for people who want to create blazingly fast and native-like snappy UIs.
It's fairly critical though to expose this new GUI stack, because otherwise it's just CLI-scripting-in-the-browser. CLI in a regular browser would be great IMO, but not a significant enough change for end-users to upgrade to the browser. Moreover, such a API stack would be extremely useful for cross-platform developers even of native apps. It would essentially compete with web-based cross platform frameworks like PhoneGap, and native ones like QT (though QT IMO is ugly and old fashioned vs web rendering).
So a great deal of work lies ahead in creating this GUI stack. This is something I'm kind of intermittently working on in my spare time. Unfortunately I'm usually kept quite busy on research work towards a PHD, but now and then I make a little progress. But if you know of others working on something similar, feel free to point me in that direction to collaborate.
I've also been thinking about the same sorts of things lately.
Mostly I've been thinking about the GUI issue on the web. CSS and the DOM are just not up to the task of creating a responsive app GUI. The incredibly complex set of nested CSS rules that need to be calculated and applied for each reflow is a nightmare.
I personally think the DOM is a fine way to define an app structure. GUIs are after all containers and components which map nicely to nodes in a tree.
CSS is great for presentation (colors, font styles etc). One of its strengths is its simplicity and its cascading nature.
What we need is a sane constraints-based layout model. This is standard fare for native apps (eg: iOS autolayout).
Imagine being able to specify:
Block_A sits at the top of the window.
Block_B is anchored to the bottom edge of Block_A.
Block_C is inside of Block_B and is anchored to the left edge.
etc..
A complex layout can be defined in a handful of rules which even JS can solve for.
Solvers for these types of optimization problems have been around for 20+ years. There's even a nice one written in JS eg:
I don't have any experience with Qt&QML, though I've heard lots of good things about it.
I don't think a wholesale replacement of HTML/CSS is feasible though. There's just too much inertia behind the incumbents, not to mention that HTML/CSS is very good for the document centric web which applies to 90%+ of the existing web.
More flexible CSS layout modes such as display:flex are quite usable and go some of the way to addressing app-style layouts, however movement on these standards is slow and doesn't go far enough IMO.
Great to hear someone is looking into this even though it's only a side project!
But I am not sure the GUI engine would really take THAT long. How long did the Android guys need for their GUI solution?. It would be interesting to know that.
And no, I actually don't know people working on projects like this :)
Yeah it's not an impossibly complex task, which is why I'm working on it, one step at a time. But it's much more involved than it sounds at first.
Of course a simple "widget" library is relatively easy to make, provided you already have powerful drawing and text functions. Then you realize, integrating text entry and copy paste consistent with the operating system gets much more tricky if you're making all your own widgets from scratch. More complex rich markup is even harder though... getting text to flow around correctly while achieving the layout you want at the same time. I think CSS does a fairly good job here, but I think we can do better.
A lot of the work before you even get to this stage though lies in good cross platform drawing and text rendering. OpenGL support is a 'must', of course. Then, 2D and vector graphics need to be implemented. OpenVG is supposed to provide this, but is useless as a cross platform solution, because it's only supported on a handful of mobile only systems. So I'd either have to implement all of OpenVG through OpenGL (and I certainly don't look forward to implementing the mess that is SVG) to get HW acceleration, or make my own VG library.
But that doesn't even solve text rendering. Text rendering western fonts is relatively easy, but it gets much more complex when you need to support unicode cursive fonts like Arabic with HW acceleration consistently. Fortunately the actual shape generation is already solved in the GNU world, but caching fonts efficiently on the GPU and with smooth antialiasing is another matter. It would be nice to just use the operating systems text renderer, but not only would the results be inconsistent across platforms, but I don't think it's possible to do this on an OpenGL framebuffer on all platforms.
So once I have HW cached text rendering, and vector graphics, only then can I even start thinking about building a widget library on top of it.
So it's much more complex than it initially sounds when you have to essentially reinvent the entirety of what the OS GUI API should provide. And if you can't settle for lowest-common-denominator functionality provided by all OSes, then reinventing the wheel is your only remaining option.
I know how to do all this, it's just a lot of work. If I was working on it full time it would go fairly quickly, but it doesn't seem to be a very profitable task so that's not feasible right now.
Some people on this thread are completely missing the point of Firefox OS.
Its about standards and making it work cross-platform with no lock-in about vendors. Last week, I spent some days on a hackathon to promote Firefox OS app development. It was very refreshing and fun.
After developing for iOS and Android, developing for a mobile phone using JS was a very good experience. I enjoy using Javascript. I think Obj-C is great too and I am not fond of Java but this is not about whats your favorite language, its about bringing the freedom of the web to your mobile device.
In couple days, I created a tiny QR Decoder that anyone with a Firefox OS device could browse too and install on their phone. That was great. During the hackathon we shared lots of apps between each other without the need for market approval, vendor saying or whatever. And yet there's the Firefox Marketplace to help discovery and certification for privileged apps.
Firefox Aurora for Android already has open web apps support that allow you to install web apps on your Android device and will hopefully implement all the WebAPI. Once Android and Firefox OS support the WebAPI there will be pressure on the other vendors to implement it as well and then we'll be in a better place than we are now.
I'm really excited for Firefox OS, but I'm not sure why. Maybe it's because I have a lot of respect for Mozilla and the high quality of their software. Having a fresh ecosystem is always going to attract developers who haven't bothered with the current platforms due to overcrowding (among other things), even if it never rivals the size of Android/iOS.
Some people are not getting the main goal of the Firefox OS: To give emerging markets (cheap) smartphones and keep the web as open as possible. Therefore, HTML/CSS/JS is a damn good combo to keep the web open, and to enable rapid development of apps.
Glad to see this coming out - I think the technical chutzpah of FirefoxOS is fantastic, now let's see Mozilla Market it in the same clear vision and spirit.
Hi lifeisstillgood, I am one of the core Persona developers. Persona is a pretty awesome project with very ambitious goals. We obviously want to see growth explode and are working hard to make Persona great for both users and site operators.
Persona's growth has been steady, primarily driven by newly developed sites. We hope that as the user base grows and support for the BrowserID protocol is natively built into the browsers, existing sites will have more of an impetus to offer support.
A version of Persona is already integrated into FirefoxOS and we hope to offer support in desktop Firefox by the end of the year.
In some downtime at work I threw together a rough proof of concept just to see what it invloves in go[1].. It was crazy simple to get running. I hope people start using it in more places.
Mozilla uses django for many of our web apps, and there's a django app that integrates Persona (formerly called BrowserID). Take a look at the repo, and if you have questions, ask in the #webdev IRC channel mentioned in the readme.
Only just starting? It was pretty apparent after the DHTML craze of the late 1990s fell flat on its face that web apps weren't any threat to native desktop apps. Then the exact same thing happened during the mid 2000s, when AJAX was all the rage. The more recent HTML5/CSS3/JavaScript fad is yet one more revival of the same failed set of ideas.
I think those eras had browsers that weren't capable of delivering on the promise.
If you only work with IE9+ (all the other browsers are quite good now) you will be working in a run time environment that is far superior to those available in the DHTML/Ajax era.
Another issue is that very few people know how to do large scale JS applications, where I work we do (130,000K+ lines of code, 900+ classes) but it has taken us several iterations to get to this stage.
I believe we are planning on making our tools open-source so hopefully people will start to see that large scale JS apps are very doable. www.caplin.com if you want to keep an eye on the open sourcing of our tooling.
We have a framework more than a library, we basically ship a framework that our clients use to create their own web trading applications. This framework covers many asset classes and many use cases.
It's not likely that any client would use all of our code and so we have build a tool framework that only pulls in the JS code that your application uses, this is done without a build and is immediately available (add a 'new namespace.sub.Class()' line and hit f5 and it will be in the js bundle you get.)
Are you seriously trying to suggest that people don't?
I'm sorry to be the one to break it to you, but desktop apps are still very widely used by all sorts of people. This includes home users, business users, scientific users, software developers, academics, and so forth.
Even when it comes to web browsing, traffic from non-desktop devices is generally only around 10% to 15% of a site's total traffic these days, for sites that aren't specifically targeting mobile users. The remaining 85% (or more) of traffic is coming from people who are, guess what, using web browsers implemented as desktop apps.
Unless the native apps are meant to be built with web technologies. It's not like using these technologies no a mobile OS is a new concept. And be wary of using something like iOS has a base for your assumptions. It's not built with those technologies in mind, and people already use HTML/JS/CSS for their apps (successfully, I might add).
Good article. The main reason for FFOS is not to take over the world but rather disrupt the closed ecosystems that Google, Apple and Microsoft are creating; the same way that Firefox broke Microsofts monopoly on the browser market.
Android itself isn't, but the ecosystem that they're building is. The market is controlled by Google and the apps will only run on Android phones. Not the OS is important, the ecosystem is. That's why Apple and Google and everyone are trying to keep everyone inside.
There is an official marketplace offering from Mozilla: http://marketplace.firefox.com but others are free to implement their own and no one has to use the official one. The apps will run on both the OS and Firefox for Android, Firefox Desktop.
I tend to agree there are advantages to a packaged SDK but there are project initiatives such as Mortar to cover this base also.
Curiously, Google has produced another (enterprisey) system than disrupts the (more) closed Android system ... GWT. If you like the strong typing of Java, compiling it to Javascript seems "safe".
I still don't understand why Firefox OS will go anywhere when webOS did not. Aren't we talking about basically the same thing? HTML5/JS/CSS? Is it timing, the changed environment that now focuses attention on web apps? Is it the reputation of Mozilla vs that of Palm/HP? I'm not saying web apps won't have a place, I'm just extremely confused about the seeming contradiction or about-face here.
The problem with webOS of course was not the sdk or anything related to how to build an app for that platform. It was just the lack of interest and relevance which is needed to attract developers.
I can easily see it beating Android/iPhone (or at least competing). I can't wait to get my hands on such a phone and I'll definitely be making apps for it. I think a lot of developers are like myself since 1) it's all JavaScript/HTML5 which is cool and 2) it's by Mozilla and company. Once there are a bunch of apps the people will come, unless the mobile industry decides to make this fail or Firefox OS turns out to be terrible.
Also I think people miss, this isn't just a phone full of webapps, it's about opening up the native functionality of the phone to JavaScript. So operating the camera, accelerometer, contacts list API, etc.
Interesting if this is in fact the goal. I would argue you still will have a mix of both. No ubiquitous environment, but Web apps will get first class support on upcoming platforms. At least this seems to be the most logical route. If you've ever used Cordova or "PhoneGap" you would know about the plug in architecture and how it is in fact still the wild west. Developers write native extensions to do things the underlying JS API can't, this won't change for a long time until the Web API does. The future is a mix of both Web and native, not just the Web.
I would have liked to have heard a story like this one at FOSDEM. You had a room full of interested IT people/devs/... and missed selling the 'spirit' of fOS. Too bad...
There are plenty of js/html frameworks for mobile. That mission was (and is??) the _promise_ of webOS. So I don't see how you can say "even in the unlikely event that Firefox OS itself disappears in the process, if web-apps become mainstream it will have succeeded" since it's far from a controlled experiment.
Mozilla always seems to have the same answer to "what if we just started from scratch": which is "let's do it". It's endearing I guess.
In general, I'm curious about the hatred here on HN towards W3C. Sure, standards often move slowly, but it is still the best way to achieve interoperability.
Good...i would be interested to know what kind of hardware support FireFoxOS would be targeted to build on...Just you know before i buy my new mobile...... I am already looking fwd for UbuntuOS which also supports JS as native and Nexus seems to fill their hardware req.
But the likely realities aren't. It's hard not to assume the ease with which Firefox the browser can be installed by my Mom when thinking about the OS. But doing so is plain wrong.
For most end users it will be as tied to a particular device by the manufacturer as any other mobile OS. And the likelihood that the end user will, as a practical matter, be able to load Firefox OS on their own is low because there is no ISA for mobile and the mobile ecosystem is so mined with patents.
It's not that some people may not be able to hack Firefox OS onto an iPhone - I actually expect it. It's that such hacks will kludged beyond utility for most non-technical people.
Interesting. I'd love to see Firebooks in the future along with Chromebooks. It would be nice to have two cloud-based operating systems for the desktop out there.
At the end of the day , the only user will care about is the app store and performances. If the apps are great and run fast then people will not care how they are made. That's the only thing we should care about.If FFos doesnt deliver on these levels then it wont work. There is already an os for cheap celphones , android. Cheaper hardware means crappy software.
Half of them have 'popups' that try to banner at the bottom of the screen, but end up flailing wilding and either taking up the entire screen, or just helpfully sitting exactly over the middle of the page. A lot of them try repeatedly to direct me to a specific page, or a native app when ever I flick between pages.
The links are tiny and impossible to click on without zooming in.
It's just a terrible, terrible experience.
How do we get from this broken UX experience story of right now, into the magical compelling 'mobile web app' future that OP talks about?
I just don't see a roadmap for it. :(