Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Promise of Firefox OS

sergimansilla.com

Post reply on HN
Print view View original

41–50 of 147 posts

Re: The Promise of Firefox OS

#41

Post by RobAley »

shadowmint wrote: post #23

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 w…

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.

Re: The Promise of Firefox OS

#42

Post by ricw »

shadowmint wrote: post #23

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 w…

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..

Re: The Promise of Firefox OS

#43

Post by davidw »

shadowmint wrote: post #23

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 w…

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.

Re: The Promise of Firefox OS

#44

Post by brudgers »

dhimes wrote: post #38
lifeisstillgood wrote: post #31

Earlier quoted context omitted.

You are on a site that is not broken, slow or spammy. 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.

This site is totally broken for mobile, and has been for years despite complaints.

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.

Re: The Promise of Firefox OS

#45

Post by marknutter »

ricw wrote: post #42
shadowmint wrote: post #23

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 w…

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..

This is just trolling, come on now.

Re: The Promise of Firefox OS

#46

Post by marknutter »

PommeDeTerre wrote: post #37
supercoder wrote: post #12

I'm starting to feel like html/js/css is starting to become the 'this will be the year of linux on the desktop' of apps. They're flexible technologies, but don't think they'll ever have the feel of purpose built native API's.

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.

Because people use desktop apps all the time now...

Re: The Promise of Firefox OS

#47

Post by marknutter »

shadowmint wrote: post #23

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 w…

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.

Re: The Promise of Firefox OS

#48

Post by Offler »

PommeDeTerre wrote: post #37
supercoder wrote: post #12

I'm starting to feel like html/js/css is starting to become the 'this will be the year of linux on the desktop' of apps. They're flexible technologies, but don't think they'll ever have the feel of purpose built native API's.

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.

Re: The Promise of Firefox OS

#49

Post by zokier »

bergie wrote: post #10
jpwagner wrote: post #8

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…

One big difference here is that Firefox OS (just like PhoneGap/Cordova) is aiming at standardizing the APIs, not at just being another framework . That by itself will make the web richer regardless of how FFOS fares on the market.

And what makes those "standards" different from "another framework"? A rubber stamp from W3C?

Re: The Promise of Firefox OS

#50

Post by hosay123 »

anon1385 wrote: post #30
hosay123 wrote: post #21

Earlier quoted context omitted.

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 you…

>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…

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.

Post reply on HN