| News | Features | Interviews |
| Blog | Contact | Editorials |
| 'There is something magical about Firefox OS' |
| By Thom Holwerda, submitted by MOS6510 on 2012-09-13 20:00:06 |
| "Over the past year and a half I've been spending more and more of my time working with Mozilla's latest project, Firefox OS. During that time I've fallen in love with the project and what it stands for, in ways that I've never experienced with a technology platform before." I'm not convinced just yet. I hope it succeeds, but I just doubt it actually will. |
|
| RE[4]: Another fallen mobile OS. |
| By swift11 on 2012-09-14 17:21:17 |
|
> May be, but it doesn't seem that anyone besides Samsung is going to release any devices. Just curious: where did you get that info ? FYI Huawei is hiring engineers for Tizen ;) Edited 2012-09-14 17:22 UTC |
 - Score: 1 |
| RE[6]: HTML as a toolkit for a mobile OS? |
| By Nelson on 2012-09-14 17:22:14 |
|
> I said web development... as in JS as it applies to web development is better than it was 10 years ago. There is no comparison there, because there is nothing to compare it to. Whatever though - I get your point. That's true, and fine. I just don't see how its a counter point to excuse poor tooling. > Now you getting into religious arguments :) Personally, I would argue that static typing is just a compiler optimization - it isn't a language feature. Its a stupid design decision because its primary purpose is to make compilers faster - it isn't about developer productivity at all. Its about forcing developers to manually disclose things that a computer can easily figure out at runtime. To each their own on that one - I use 7 or 8 languages routinely, about half statically typed and the other half dynamic. I prefer dynamic any day of the week, I don't like having to put training wheels on my code. I don't particularly find that to be a win. Dynamic typing make code less readable at a glance, and especially in the case of JS leads to ridiculous decisions like the lack of an integer system. > Ill give MS credit for allowing the CLR to do it either way though - if they didnt' allow dynamic typing the number of languages running on it would have stopped at 1... I think this is a good idea and would rock for JS. Default static typing with optional dynamic typing. > The exact same thing can be said about C# or Java. Time, money, and good engineering can turn a weakness into a strength... Well, I think that there are certain design issues in JavaScript that make it relatively harder to make fast. That's the crux of this argument. > Again - "features" that exist to make compilers happy and developers sad don't interest me much... I don't know man, as a developer, poor performance makes me sad. > I would argue that the user experience depends more on the developer than the tools used. Ill even concede it is much easier to create a consistent user experience when using a full stack application development framework - as long as you are only targeting that single stack. I often care more about how many screens I can reach - and it is far easier to spend the time and write a good UI in HTML5 that you can deploy everywhere. It depends of course - it isn't good for everything - but that doesn't make it bad. Code reuse greatly alleviates this. Its middle ground between two extremes. Not quite write once run anywhere, but not quite single stack either. > I do too for the most part. I'm pragmatic - sometimes it is easier that way to get a good result. But I find I choose that route less and less often because the JS/HTML approach is improving so much. I'm not religious about it - I just think saying it is crap and nonviable is extremely short-sighted... I don't think its improving fast at all. The next improvements to the fundamental technologies are still years off. In the meantime, the deficiencies are unacceptable to me. > Um.. Java. Flash. Silverlight for the most part too. Im not saying they are dead for app development, but they are all dead for general purpose web development... Silverlight was never meant to replace the web, only augment it. Remember, HTML5 didn't exist at that time. The only way to write RIAs was using a plugin. Silverlight was the best at this. It doesn't mean byte code is categorically bad for the web. Hell, the generated , minified, gunk that is JS on most sites is a lot less human readable. > Look at meteor. Or angularjs. Or knockout. Or about 20 other up and coming declarative frameworks. Same thing... That is my point - HTML eventually adopts anything worth doing. It might not be quite as elegant and refined as XAML, but in the long run it won't matter because it doesn't need yet-another-runtime in order to work. While good, you said it best, it lacks cohesiveness. For Knockout you need to select elements out of the tree and apply bindings and view models manually. There is no declarative databinding because markup can't be extended. Its not really declarative then, its just a hack. The point is, its an app platform, not the web, you'll need a runtime anyway, so Mozilla used suboptimal tech for a really terrible reason. Developers should reject this crap. > Markup is markup. XAML is not good because of the markup language - it is good for the reasons you stated above - which are features of the runtime. Most of the same features can (and have been) applied to HTML/JS... No they have not, because the markup hasn't been leveraged in doing so. JS has. Its not the same thing. Its perfectly reasonable to say HTML is terrible and inadequate, and say XAML is a lot better. > 800 million devices with a 2-3 year lifespan... Well see how it goes. I'm actually a fan of Windows 8 - Im not knocking it at all. My point was what they call XAML now will likely be replaced with the-next-new-paradigm in the next 10 years or so. There is always something better around the corner - things like XAML fade away - remember OWL, MFC, etc. Web technologies evolve and adapt... XAML has been around since 2004. Its been used in WPF, Silverlight, Workflow Foundation, XPS, WinRT, Windows Embedded, the Xbox 360, etc The key difference now is that its part of the Windows Division, not the Developer Division. Its gone from a dev platform to an inherent part of Windows, with all the legacy implications that it brings. |
| - Score: 3 |
| RE[7]: HTML as a toolkit for a mobile OS? |
| By Nelson on 2012-09-14 17:25:01 |
|
It makes perfect sense. I'm not in the business of caring about what lazy developers prefer. Anyone using HTML/JS to write run anywhere app is pretty much the worst kind of developer I know. Wake up, developers. At one point, people were more principled than this. |
| - Score: 1 |
| RE[5]: Another fallen mobile OS. |
| By shmerl on 2012-09-14 17:58:36 |
|
I don't know much about them. Except that they tried to troll the Opus codec (which is an important part of the open Web) with some weird IPR claims: https://datatracker.ietf.org/ipr/... Not a good reputation IMO. I have no trust in these kind of participants. Edited 2012-09-14 18:04 UTC |
| - Score: 2 |
| RE[6]: Another fallen mobile OS. |
| By swift11 on 2012-09-14 18:04:26 |
|
Huawei is just an example: every participant of the TA will have Tizen devices ;) about the codec: open source is a learning process for most companies, but you're right: it's plain stupid :) Edited 2012-09-14 18:07 UTC |
| - Score: 1 |
| Security Concern |
| By Pro-Competition on 2012-09-14 18:09:13 |
|
I am always in favor of more choices, so I would like to see Firefox OS succeed. But one potential problem jumped out at me from the article: > Because Firefox OS is constructed using HTML, JavaScript and CSS it means you only need basic Web development skills to reach in and completely change the device experience. You could literally change one line of CSS and completely change the way the icons on the homescreen look, or re-write some core JavaScript files that handle phone-calls. That sounds like a security (and tech support) nightmare waiting to happen. I hope they are thinking about things like this. |
| - Score: 3 |
| RE[8]: HTML as a toolkit for a mobile OS? |
| By Alfman on 2012-09-14 18:17:31 |
|
Nelson, "It makes perfect sense. I'm not in the business of caring about what lazy developers prefer. Anyone using HTML/JS to write run anywhere app is pretty much the worst kind of developer I know." Wow Nelson, I think you might have initially started out defending a sound principal, but your argument is becoming absurd. Writing portable code is ultimately about not having to reimplement the same thing everywhere. You can call it lazy if you want, but I'll call it being efficient. The WWW, for all it's problems, could not be as ubiquitous and transparent as it is today if everyone used their own protocols and different standards. Unless you believe in segregating the online population, it's a good thing that everyone can visit each other's websites with the expectation that they will work everywhere else. |
| - Score: 3 |
| RE[6]: Another fallen mobile OS. |
| By galvanash on 2012-09-14 21:51:57 |
|
> Just to be clear, this example did NOT measure script parsing overhead, which was mere milliseconds on my machine and an acceptable one-time cost. What was slow was the run time inside the loop - several seconds in each case. I'm baffled why you're claiming 90% of the execution time is due to "parsing, compilation, etc"? Obviously we can't be talking about the same thing. Sorry, I wasn't clear. Your right - we are not talking about the same thing. I wasn't trying to imply that the code above only takes 10-15ms to run in walltime - it takes (on my machine) 1.45s. What I was saying is that, minus the 10-15ms, the rest of the time is purely parsing, compiling, memory management, type inference, etc. etc. - i.e. non-user code or system code. The actual amount of CPU time spent executing _only_ the actual loops and dong the calculations is 10-15ms. If you want to run it in Chrome and look at the CPU profiler you will see what I am talking about. In other words, in a perfect world where JS was a compiled to machine code language and memory allocation was perfect and could be done in advance - the code would take around 15ms to run, which is probably very comparable to GCC (if you rewrote the GCC code to allocate the whole chunk of memory in one shot, for example). But - It is obviously not fair to discount the rest of that time - memory allocation counts too and is real overhead. Its just that since JS does this automatically it isn't done in user code - so it ends up being counted up as "program" time by the profiler. It still matters of course. I was simply pointing out that it isn't purely because of object access. Object access is slower of course, but the bulk of the time is actually spent on engine level stuff (like memory allocation). That is, by and large, where you will end up seeing all the time go relative to something like GCC - memory allocation, compilation, and garbage collection overhead. Other things (like difference in object access performance) tend to be eclipsed by it. Object access patterns are slower, and that is a real problem, but it isn't the bulk of the performance delta your seeing. > There are several ways we could have eliminated the objects, but given that they were what I was measuring the overhead of this would have defeated the point. That is my point though - only about 40% of that overhead you measured is due to object access. I removed it and the code runs 2x as fast, but it is still more than 50x slower than GCC. The big difference is memory allocation and general engine overhead. Like I said, that isn't a fixed cost - it is highly dependent on the code. But it does tend to become less and less significant the larger and more complex the code base becomes. |
| - Score: 2 |
| RE[8]: HTML as a toolkit for a mobile OS? |
| By galvanash on 2012-09-14 22:26:42 |
|
> It makes perfect sense. I'm not in the business of caring about what lazy developers prefer. Anyone using HTML/JS to write run anywhere app is pretty much the worst kind of developer I know. Wake up, developers. At one point, people were more principled than this. I'm very principled... One of my first principles is that I don't believe that development is the process of becoming attached at the hip to a particular vendor's idea of the right way to do things. HTML/JS might not be perfect, but it has one very significant feature that no other development platform has - no one company is steering the boat. And since you want to resort to name calling... What is being content to slop up Microsoft or Apple's latest dog food for the sake of it making things easier for you? That sounds pretty lazy to me. My development platform is the world - yours is just the latest gadget fad... |
| - Score: 1 |
| RE: Comment by Luke McCarthy |
| By adkilla on 2012-09-15 05:26:42 |
|
I wouldn't want the stagnation that is happening in the x86 platform to extend to ARM SoCs. If it weren't for AMD, we would all be stuck with a 32-bit ISA on x86, with an overly costly and less than optimal upgrade path to Itanium. Unfortunately we've lost the 3rd party chipset market on x86 due to having too few CPU players. I hope the ARM SoC market stays the way it is with even more competition and SoC options coming into it. |
| - Score: 3 |
| News | Features | Interviews |
| Blog | Contact | Editorials |