111–120 of 276 posts
Earlier quoted context omitted.
Web standards apps will always have to make bad compromises. We need browser byte code.
JavaScript is browser byte code. Just like Java byte code it's not that great for a lot of cases but, just like Java, eventually the JIT will get pretty decent.
Earlier quoted context omitted.
We are working on that, but there is only so much we can do if we want this to be open. If carriers want to use the Firefox OS branding and our system then there will be certain limitations on what they are expected to do in return. This is new to us, but I'm confident we'll come up with something satisfactory. Saying that, we can't stop someone taking the code from GitHub and producing their own non-Fx OS system and…
I think the key is making it easy for users to 'reset' the device to stock FxOS. I would hope the firefox brand was strong enough to keep carriers from releasing their own variants to avoid mozilla's requirements.
Earlier quoted context omitted.
Thanks for the comment, the WebOS question is one I see a lot. One of our engineers answered this recently on Quora, I hope it helps explain the differences a bit: http://www.quora.com/How-does-Mozillas-Boot-2-Gecko-compare-...
I might not be reading this right, but in my mind this summarized as: * WebOS added custom API's to handle parts of the phone hardware that are not web standard, for eg. phone calls, SMS * The Firefox project also added custom API's, except they are submitting them for standardization as web interfaces Why not just implement the WebOS API's and thus make them a standard, or are they considered flawed in some way that…
I'm sure that Firefox OS used the WebOS API's as inspiration though.
Mozilla, please don't allow carriers or manufacturers to modify your OS! You need to set the right tone from the very beginning. Otherwise you'll never get that kind of power back later on. Sell it to them as an alternative to Android. That's all they need to know if they want it or not. If they want more, you can go elsewhere.
Mozilla, please don't allow carriers or manufacturers to modify your OS! You need to set the right tone from the very beginning. Otherwise you'll never get that kind of power back later on. Sell it to them as an alternative to Android. That's all they need to know if they want it or not. If they want more, you can go elsewhere.
And per the article, one of the benefits of the OS is the ability to modify the GUI and default apps with simple HTML+CSS+JavaScript.
Mozilla, please don't allow carriers or manufacturers to modify your OS! You need to set the right tone from the very beginning. Otherwise you'll never get that kind of power back later on. Sell it to them as an alternative to Android. That's all they need to know if they want it or not. If they want more, you can go elsewhere.
[deleted]
Mozilla, please don't allow carriers or manufacturers to modify your OS! You need to set the right tone from the very beginning. Otherwise you'll never get that kind of power back later on. Sell it to them as an alternative to Android. That's all they need to know if they want it or not. If they want more, you can go elsewhere.
If it's an alternative to Android that doesn't let Carriers "add value" then it's an alternative they won't use . Open Source, in this case, becomes a race to the bottom in every respect. We need carriers to be dumb pipes we buy data plans from; then this entire class of problem goes away. Until then, any platform that doesn't let carriers charge us different amounts for bits from different places is going to die on…
I agree with what you're saying, but how do we get to a state where we can have "dumb pipes", yet have an open, privacy driven and easily user controllable OS on a device?
Is there an alternative to always needing to "add value"? Isn't earning our coin off carrier charges, data etc enough?
Terrific stuff. I still think there is a use case for a static C like language (with explicit memory management) for some kernels. The same way that WebGL has HLSL, it would be nice if there was a WebCPU API with C as the 'shader' language. (Alternative is LLJS approach - but that has other issues).
Can we please stop putting JavaScript everywhere? It's not a good language and people have a tendency to produce frailer code with it than they would otherwise.
JavaScript shows up in new places because everyone already knows it, because it's relatively easy to write a JS app and deploy it to every single platform, because anyone who wants to learn it can probably jump into a REPL from Facebook by hitting cmd-shift-J, because there's a huge amount of code already written in it, because there's intense competitive pressure to optimize the interpreters, etc. etc. etc. The same kind of reasons that English is hard to replace. If you want to improve the situation, you can't just point out the flaws, you have to offer a smooth transition from here to a better language.
But actually, that's already happening. JS is actively, incrementally improving. (As one random snapshot: https://brendaneich.com/2011/05/my-jsconf-us-presentation/) So the answer is, no, we cannot stop putting it everywhere. That is not going to happen. But we can make it better.
You could set your watch by the HN response to a story like this. Pure doom, gloom and naysaying. Smartphones these days live and die by their app ecosystem. I would love to be working on mobile apps, but for the expense of buying an iPhone, an Android phone and a Windows phone, plus licenses for software to develop for all three. Not to mention the daunting prospect of dealing with Objective C, Java and C# simultane…
I'm confused by your statement about "the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone developer." Perhaps that's true for a hobbyist. But any professional software developer should already be familiar with at least one (if not all) of those languages, and should be able to pick up the others with very little work. Once you know C#, for instance, y…