The Promise of Firefox OS
sergimansilla.com
sergimansilla.com
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. :(
It has "stickiness" and "retention" that all of those sites cannot dream of.
Good User Experience beats terrible. Good user experience makes money - trust us, the market will win.
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?
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
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.
I do mean experience. Its a holistic thing.
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
* No adblock on mobile (yet?) :P
Hopefully it'll change.
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.
The ability to properly adblock is actually a genuine factor that could make my next mobile something other than an iPhone
No adblock on mobile (yet?) :P
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.
[0]: AdAway (I use this) https://play.google.com/store/apps/details?id=org.adaway
Adblock Plus for Android (Seems to have some non-root support, I haven't tried it): https://play.google.com/store/apps/details?id=org.adblockplu...
This app above is not the same as the browser extension mentioned before
https://addons.mozilla.org/en-US/android/addon/adblock-plus/
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.
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.
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.
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.
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.
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..
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.
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.
You can (and we do):
iOS: http://xamarin.com/monotouch android: http://xamarin.com/monoforandroid
You should give it a shot. And as much as I like HN and its content, its mobile UX is pretty shabby (dare I say incompatible? ;)).
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.
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.
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.
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.
Yes. https://marketplace.firefox.com/ They're not interesting in locking down the device to just one app source though.
> 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...
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.
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.
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.
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?
I gave a presentation a couple of weeks ago with a couple of slides with example stack traces with and without deobfuscation: https://docs.google.com/presentation/d/1TCzHx1UH24gA1Au8LOvZ...
You mean like iOS' half-C or Android's half-Java?
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.
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.
You can run Javascript anywhere [1], why would you want to compile it to some portable bytecode?
[0] http://en.wikipedia.org/wiki/V8_(JavaScript_engine) [1] Well, there are restrictions, just like there are for Java Bytecode.
Huh? JavaScript JITs have been around for 4 years now.
That last one might not be a bad idea. The first browser I used ran 'xv' to display images.
"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..."*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.
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.
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.
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.
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.
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.
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.
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?
It seems like this ought to have made it onto PG's list of frighteningly ambitious ideas.
- Java Applets
- Microsoft Silverlight
- Adobe Flash
pro - what?
s/propietary/proprietary/
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.
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 :)
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.
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..
Solvers for these types of optimization problems have been around for 20+ years. There's even a nice one written in JS eg:
http://www.badros.com/greg/cassowary/js/quaddemo.htmlI 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.
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
(EDIT: formatting)
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 mean I simply did not know there was an emulator (https://hacks.mozilla.org/2012/12/firefox-os-simulator-1-0-i...) until this post, and honestly I looked.
Edit: oh and can someone tell me if persona is taking off or not - are there stats from login.persona.org?
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.
If you want to participate in discussions, have an idea on how we can improve, or just want to see what we are up to, our mailing list is open to everyone: https://groups.google.com/forum/#!forum/mozilla.dev.identity
I agree - Persona is an awesome project - and I like anything that is going to take the pain of managing passwords away from me.
I am most interested in python / wsgi integration - if any of your collegues are working on this I will be very happy to contribute.
They're flexible technologies, but don't think they'll ever have the feel of purpose built native API's.
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.
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.
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.)
We bundle js, css, xml, i18n tokens etc.
All automatic and requiring no build.
Everyone is free to implement the Android app API, as Blackberry have, just like they are free to implement the Firefox OS phone APIs.
The difference is very small. Firefox is more likely to have portable apps, Android offers a much higher quality API for building apps.
I tend to agree there are advantages to a packaged SDK but there are project initiatives such as Mortar to cover this base also.
> The Firefox OS app market is controlled by Mozilla
https://github.com/mozilla/zamboni
Any corporate or individual entity could take this code and set up their own entirely compatible platform.
The differences really aren't that big.
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.
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.
That by itself will make the web richer regardless of how FFOS fares on the market.
See for instance http://blog.chromium.org/2013/02/hello-firefox-this-is-chrom... and https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-c...
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.
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.
I'm more interested in how it stacks against other open source mobile OS's, most importantly Ubuntu, but also open webOS and Tizen.