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

121–130 of 147 posts

Re: The Promise of Firefox OS

#121

Post by zabraxias »

lucian1900 wrote: post #32
janjongboom wrote: post #26

Earlier quoted context omitted.

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.

The Firefox OS app market is controlled by Mozilla and the apps will only run on Firefox OS (for now, at least). 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.

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.

Re: The Promise of Firefox OS

#122

Post by watmough »

7952 wrote: post #27
anon1385 wrote: post #15

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

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

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.

Re: The Promise of Firefox OS

#123

Post by 205guy »

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…

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.

Re: The Promise of Firefox OS

#124

Post by kibwen »

lucian1900 wrote: post #32
janjongboom wrote: post #26

Earlier quoted context omitted.

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.

The Firefox OS app market is controlled by Mozilla and the apps will only run on Firefox OS (for now, at least). 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.

  > The Firefox OS app market is controlled by Mozilla
One clarification here: Mozilla's marketplace code is entirely public (though confusingly named):

https://github.com/mozilla/zamboni

Any corporate or individual entity could take this code and set up their own entirely compatible platform.

Re: The Promise of Firefox OS

#125

Post by Offler »

chris_wot wrote: post #63
Offler wrote: post #48

Earlier quoted context omitted.

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…

900+ classes, in Javascript?

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

We bundle js, css, xml, i18n tokens etc.

All automatic and requiring no build.

Re: The Promise of Firefox OS

#126

Post by wwweston »

zanny wrote: post #111
ricw wrote: post #52

Earlier quoted context omitted.

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

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…

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

Re: The Promise of Firefox OS

#127

Post by Someone »

rwmj wrote: post #33
otibom wrote: post #20

Earlier quoted context omitted.

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 ?

Or do we tear down the monoliths that browsers are in small Unix-style components? That last one might not be a bad idea. The first browser I used ran 'xv' to display images.

In case you don't know of it: http://www.uzbl.org:

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

Re: The Promise of Firefox OS

#128

Post by ux-app »

electrograv wrote: post #91
mephju wrote: post #66

This is a real question and no trolling: 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…

I've thought about this a lot myself. 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. WebG…

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:

  http://www.badros.com/greg/cassowary/js/quaddemo.html

Re: The Promise of Firefox OS

#129

Post by spankalee »

anon1385 wrote: post #15

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

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.

Post reply on HN