Firefox OS Participation Hub
firefoxos.mozilla.community
firefoxos.mozilla.community
I'd love it if the page that was linked noted more ways to contribute to the community -- at present, it seems like there are two (but should be more):
- Port FFOS (I'm actually doing this on one phone I had laying around, and it's actually pretty difficult because I am new to porting mobile android-based OSes)
- Try FFOS on android
What about app reviews? last I checked, that was also a great way to contribute to the platform (assuming they're still done by volunteers). Also, contributing code, mashing bugs (a link to the bugtracker), i18n help all seem like things people could do to help (when I last built from master, some translations were still lacking)
I guess this might work someday, but I honestly don't understand the point of making an interface out of just HTML and CSS. The performance is truly awful, and will never get better until the models that govern those technologies are refined. It's impossible to optimize CSS, for example. (Although Javascript is definitely getting better, it's still not "native" speed either.)
I hope some rethinking comes to this project.
That's a bold claim, and it does not square with my experience optimizing CSS implementations. In fact, CSS at its core is well suited for parallel implementations, saturating all CPUs on typical workloads, and its declarative rendering structure maps more naturally to hardware-accelerated graphics APIs than traditional vector graphics APIs do.
Why, specifically, do you think CSS is unoptimizable?
If you want to make a responsive UI, doing work incrementally and amortizing the cost of actions across frame intervals is more important than raw performance. This is especially true on mobile, where frequency / voltage controllers for CPUs and GPUs are tuned to work best on consistent workloads rather than bursty workloads.
So this is a really broad statement and without further clarification it's hard to pin down precisely what you mean. By incremental layout do you mean partial layout, or relayout after dynamic changes? For the latter, I don't see how flexbox (for example) is worse in this area than springs and struts, as it essentially is springs and struts. And for absolutely positioned UIs (the old way mobile apps were laid out), layout time of CSS is essentially zero. For the former, it's commonplace to use frameworks that will do the standard "UITableView" sort of optimizations in script. Moreover, though, there's CSS Containment [1] coming soon to allow for these sorts of optimizations without having to use JS. I agree that CSS Containment is critical to allow CSS to achieve the performance of native frameworks, but this is an area of active work, and I don't see any roadblocks in the way of partial layout once CSS Containment arrives.
Also, shadow DOM and web components may even fix my disagreements with it anyway.
CSS as specified is imprecise, yes, but individual browser implementations implement their own precise behaviors. (This is no worse than native UIs.)
CSS has a lot of weird quirks, but techniques such as Gecko's display lists have gone a long way toward taming this complexity by lowering to a simpler form. This opens up aggressive optimizations at the engine level (which is not to say that browser engines are currently doing all optimizations that are possible!) What's nice about CSS in terms of analysis is, again, its declarative nature: the fact that common layouts are implemented declaratively means that browser engines have a lot of freedom to optimize them in different ways.
Graphical glitches with the icons, being unable to use any of the bundled apps (Browser, Music, Gallery, etc.) because it just results in an instant crash, likely due to being out-of-memory killed, unresponsive gesture support (dragging from the side of the screen takes multiple tries, even after you figure out that's a feature and only way to go back).
The most important issue is definitely that if the home screen is unloaded, pressing the home button results in a 10 second long FirefoxOS booting process before you can launch any other app. If someone wants to start up Snapchat by pressing the home button and launching the app, but has to wait 10 seconds for your home screen to reload, you're dead in the water. This is entirely possible to be due to me using a fairly low-spec phone...but that's the entire market for FirefoxOS...
The second part of your comment makes close to no sense. There are a lot optimizations done in a web rendering engine, both on the css/layout/painting part and in the js engine. A modern web engine goes to the GPU as much as possible, and is very comparable to what a "native" toolkit does (I'm not convinced that android's xml layout/views are really more native than html/css).
A bunch of the home-screen icons were missing and when I clicked on them they opened a completely different App that wasn't even on the screen. Trying to click on rows in the settings App did nothing, or hung, before finally responding. I'm not sure if a jank is the right word (it wasn't in the scrolling performance sense) but it felt quite buggy and unresponsive.
And the abilities to customize things are an awesome vision, although it is a bit early to judge if it actually works out. (I'm somewhat skeptical, but I dislike all other mobile OSes as well, so even a not-perfect improvement would be welcome)
My Nexus 7 has a 7" screen and on it, the home screen icons are incredibly huge: at least 2-3 times the diameter of the standard Android App icons and look really out of place on my screen.