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

141–147 of 147 posts

Re: The Promise of Firefox OS

#141

Post by ux-app »

nsm wrote: post #140
ux-app wrote: post #128

Earlier quoted context omitted.

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…

I've often wondered about replacing HTML/CSS/JS with QtQuick and QML. Thoughts?

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.

Re: The Promise of Firefox OS

#143

Post by pjmlp »

marknutter wrote: post #136
pjmlp wrote: post #109

Earlier quoted context omitted.

You mean a mix of server side generated code full of CSS, JavaScript and HTML hacks so that it behaves in a similar way across multiple browsers?

You mean webkit?

Ah the web engine that has a different set of features depending on the browser that uses it.

Re: The Promise of Firefox OS

#144

Post by lucian1900 »

kibwen wrote: post #124
lucian1900 wrote: post #32

Earlier quoted context omitted.

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.

While the Play backend isn't open-source, there are already at least two other competing app stores.

The differences really aren't that big.

Re: The Promise of Firefox OS

#145

Post by chris_wot »

qznc wrote: post #79
chris_wot wrote: post #64

Earlier quoted context omitted.

I'm not following: Javascript is an interpreted language, not a bytecode standard. You can't compile Javascript to bytecode and run it anywhere.

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…

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.

Re: The Promise of Firefox OS

#146

Post by qznc »

chris_wot wrote: post #145
qznc wrote: post #79

Earlier quoted context omitted.

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…

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…

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?

[0] http://en.wikipedia.org/wiki/V8_(JavaScript_engine) [1] Well, there are restrictions, just like there are for Java Bytecode.

Re: The Promise of Firefox OS

#147

Post by chris_wot »

qznc wrote: post #146
chris_wot wrote: post #145

Earlier quoted context omitted.

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…

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? [0] http://en.wikipedia.org/wiki/V8_(JavaScript_engine) [1] Well, there are restrictions, just like there are for…

The original poster wrote "JavaScript is the standard bytecode". That's what I was responding to.
Post reply on HN