Slashdot Mirror
Has the Native Vs. HTML5 Mobile Debate Changed?
itwbennett writes: The tools available to developers who need to build an application once and deploy everywhere have exploded. Frameworks like famo.us, Ionic, PhoneGap, Sencha Touch, Appcelerator, Xamarin, and others are reducing the grunt work and improving the overall quality of web based mobile applications dramatically. The benefits of a build once, deploy everywhere platform are pretty obvious, but are they enough to make up for the hits to user experience?
The problem with frameworks is that they lower the end product to the common denominator. Instead of having an app for each platform that exploits the strengths of that platform, you end up with whatever you can manage to get to work on every platform. That works for simple apps like news websites maybe, but not when you want to integrate tightly with device hardware and how the established user base is used to interacting with their chosen platform.
Just because I can hook a shark from a boat, I do no offer to wrestle it in the water.
If you're Home Depot, no ... while it's important, those few milliseconds of lag and somewhat less native UI isn't a primary business concern.
... your experience has to be as optimized as possible to stay / get ahead of your competition.
If you're trying to take on an 'A' player like Google, Facebook, Twitter, etc, or trying to establish a new service, yes
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
Fuck HTML5 apps, slow as fuck buggy apps...
They might look like native apps now (mainly because native apps now look like webpages), but they are still an order of magnitude slower and they always will be.
If you're Home Depot, no ... while it's important, those few milliseconds of lag and somewhat less native UI isn't a primary business concern.
Low latency integration with the device's camera is a primary business concern when you're trying to let the user visualize how a particular home improvement product will look next to other things in the room.
We use Xamarin and our advice is don't use Xamarin. Too many bugs, garbage collection sucks. I love the idea of Xamarin but wish we'd gone native.
More specifically, HTML5/JS/CSS still give really shitty developer and user experiences compared to native apps. That has always been the case, and still remains true. That is why the debate has not changed.
First, Xamarin isn't a web framework. Secondly, I have experience with Sencha Touch. The documentation is TERRIBLE and the resulting apps are slow as balls. How can anyone actually like working with these things?
So if you need a framework so you can pretend to have a native version of the application ... why not just focus on having a webpage instead of a shitty application which is just a web page?
This sounds like lazy people who want to claim they have an app, when all they're doing is pointing to a web page.
I can view your damned web page on my own.
Honestly, this is why I've started getting away from apps ... because as often as not they're badly written, and contain a fraction of the information I can get from the website, but still insist on having access to my contact list and messages.
Most people writing apps care more about invading my privacy and selling ads than actually providing me anything useful.
Lost at C:>. Found at C.
I beg to differ html5 is catching up. Look under experiments there is a nice Quake 3 map demo and a webgl hexagon demo.
Many stuff can be done just fine in a web application. Banking, online shopping, quiz-style games, cellphone operator "my account"-style app. Even Facebook is fine as a web page unless you want those notifications (not having them is a feature IMO).
Some stuff still need to be an a native application. Camera, music player, email, chat, maps/GPS navigation, calendar. Most 3D games also benefit from being native.
For 99% of the applications out there, there's no reason not to do it in the browser if you're starting from scratch today. Most (useful) mobile apps simply display remote content in a way that's contextually relevant to the moment (Yelp, shopping (ordering and product reviews), *Maps, news sites, social media, etc). There's no reason for any of those to be app based. Most apps that aggregate content are poorly designed and not updated frequently. Couple that with the fact that most do not have useful offline modes (the only reason to have an app for content, IMHO), it just makes sense to optimize for the mobile browser rather than spend all the time and effort on an app. Hell, even most games I play casually have no reason being written as apps any more - any word game or puzzler would work fine in the browser.
Instead, put the effort into good mobile design and development practices. Hire good developers to optimize for JavaScript. Hire good developers to optimize your backend operations to reduce latency. Find what features are missing in HTML/JavaScript (e.g., a good client side persistence layer) and encourage the browser vendors to improve there so everyone can benefit.
For context, I develop complex scientific software. We use the browser (desktop) as our client and push the limits of what you can do there. Mobile is not far behind and should be the first choice for new development.
-Chris
When I last checked a few years ago, one of the cons of using any of the HTML based app development systems was that effectively you bundle the complete source code of your app inside your app.
Has this changed in recent years?
I am Slashdot. Are you Slashdot as well?
Lots of javascript reinventing basic things like the plain old link, button, form, image, whatever, but so badly it won't work on actual release browsers, need latest nightlies, eight cores AND a js accelerator or it'll just hang the system.
And that when it's really not difficutl to... dump your text and pictures in a webpage and have a little static css sort out the formatting. What a novel idea!
Similarly, lots of webpages getting "updated to html5", swapping out tags and doing things differently just to be different, breaking backward compatability, for really no gain in user experience at all.
We're seeing a combination of a rush to "mobile devices" (that would've worked Just Fine had you not tried reinventing stuff for no reason earlier) reinventing stuff for no gain yet again, plus a new iteration of the browser wars, this time with standards pushing the breakage. How novel. But at the end of the day, too much just doesn't work as robustly as it should.
Apparently this is what we want, because we're doing it everywhere, web pages and apps and whatnot else too.
Honestly, right now, native applications are by far the superior choice. Web apps sound like a great idea, but they're hindered by being incredibly slow (and phones are already not very powerful to begin with), they have far fewer features, and they often look hideous and out of context compared to the other applications on the system. Furthermore, web applications have no legacy - I can always guarantee that app version so-and-so will work on Android version such-and-such, but the same can't be said for a web application.
Besides, different browsers do have different Javascript standards, and for anyone who has ever tried to get the same webpage to display well across a variety of phones knows what pain and frustration are. It might honestly be easier to develop two different programs, one in Objective-C and the other in Java, because then at least it's clear where one system starts and the other ends. With Javascript and the like, the lines all blur together...
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Wow, that's really fantastic! We can build late 1990s era games with this web technology. That's totally cutting edge and innovative. It will only be another 15 years before we can use web apps to create shitty demos of today's software. I can't wait!
It depends. The hybrid frameworks have moved closer to native, and web itself has moved closer to native too. Google has now released push notifications for the web as well as Service Workers that add in offline support. A web site/web application can now do a lot of what apps were needed for previously. The hybrid platforms you mentioned are great (I love Ionic!), but the performance isn't 100% there yet. But, if you are not making a game, the performance is probably good enough. In general: If you need a device specific feature (TouchID, HealthKit, etc.) you have to go native. If you need really high performance, you need to go native. Otherwise, you can go with a hybrid solution. And soon, for many things, you'll be better off with pure web, if Service Workers and related tech takes off.
The author of the blog post that started this discussion owns a software consultancy that specializes in native application development (iOS and Android). Clearly his opinion is that native apps are better.
If you'd like to use your native language skills ( E.g. Java from Android ) on alternate platform ( e.g. IOS ), frameworks can be useful. I like open-sourced CodeNameOne and RoboVM because I work on the Java side of things and my needs on alternate platforms are fairly basic. An IOS developer may easily go in the other direction.
If you are Target and I just want to see what you have available in your store, then no, you don't need an app.
If you farm out to lazy app developers that simply ask for every permission on the phone, then no, you don't need an app.
And if you make a phone-specific version of your site, it will almost always end up crippled.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Great so now it takes 1 maxed out 3ghz core to render snes starfox level graphics in a browser at 640x480. I can't wait..
Obligatory XKCD(s):
Installing (and App)
Facebook gave up too early. On the other hand, Facebook can afford the development cost of native. For many other applications, native is unaffordable, especially for multiple platforms.
(Thank you, though, Facebook, for (before giving up on hybrid) figuring-out how to shut off the *&^%$#! iOS WebView "accessory view", and using your Facebook-powers to cow Apple into looking the other way when apps go digging into the virtual keyboard windows to shut that evil thing off...)
Embedded WebViews have gotten much better. Android has been the laggard, with awful animation/transition performance and glitchiness prior to 4.x, and user reluctance to upgrade OS (improved now) and inability to upgrade on many devices (alas, not much improved, so many Android devices cannot be upgraded to latest OS.)
Certainly, on iOS at least, I think most users would be hard-pressed to tell the difference between well-written hybrid apps and native.
I use (Zebra, was Motorola, and before that RhoMobile) Rhodes. I've also developed using PhoneGap/Cordova. I would not do a large project in PhoneGap/Cordova, because everything has to be done in Javascript. With Rhodes, I write models and controllers in Ruby, views in ERB (wish it had a better template language...) and code that touches the UI directly in Javascript. It's a very comfortable platform if you have been a Rails developer, because it's very similar - the server has been placed in the application.
I'd say at least half my development time is spent with JS and CSS (actually, I use SCSS). I see that as a good thing. I can tweak the UI interactively by twiddling CSS in Safari or Chrome desktop (developer tools for both can connect remotely to a device for inspection/debug/experiment.) I can easily teach a designer to do that themselves. Contrast that to the painful process of tweaking a native UI, being forced to use platform-unique tools and go through a slow and painful build process to see the smallest result.
I've been working with a small team implementing a number of similar energy-conservation apps (they are used by professional energy auditors - organizations are opinionated, that's why there are 6 apps...). I really think the effort would have been insurmountable had it been done with native code. This is not a typical consumer app with a few screens, but ones with dozens of pages of data-collection forms (per audited building). It's not your typical consumer app with some kind of silly one-page dashboard with text in circles...
If I had to do something with charts/graphs, I certainly would leverage the great JS libraries that are available, rather than struggling with native code! We did do a little sketch tool in JS (sketch over photos for annotation - just browser API) and nobody would ever know it is not native.
Ultimately, we abandoned Android (at least for now) due to poor performance and Balkanization, but I can see Android being supported in the future again.
I have not used Xamarin. It seems the worst of all worlds to me. You have to use the native API of each platform, but you write in a common language (C# yuck!). Where is the saving in development time here?
I strongly disagree with the bit about "different screen sizes" etc. being problematical. Using HTML helps solve that problem. It's easy to create flexible layouts using responsive CSS. Yes, native platforms have gotten better about this. But it's impossible to get designers directly involved, using the tools that they are familiar with. They still have to toss wire-frames "over the cubical wall" and the battle it out with programmers as to whether their fantasy UIs are even possible. With HTML5, they can work with what they are familiar with and provide complete solutions for UI bits. As well, there is an amazing volume of free and really quite high-quality resources for CSS3 effects, etc. that can be leveraged.
Yea, if you have a million-dollar budget for a small app, go for native. The rest o
Are web apps as amazing as native apps? No. And i doubt they ever will be. However, the time it takes to develop a native app vs a web-comparable app is immensely different. Web apps are infinitely easier to create and deploy. The question is if it's worth spending 2-5x the amount of money/effort to provide that level of immersion. To many it's not. Especially if your user base is small.
I work for a Fortune 500 company and we have internal web apps that serve anywhere from 10 - 10K people. There is little justification to make native apps that essentially do the same thing when we can put a wrapper on it and call it a day. Having an immersive app needs some serious justification for that level immersion when your throwing around $100Ks of develop/maintenance costs.
Except most app developers want to target as many users across as many devices as possible
Say, isn't that what Malware and Spyware authors want too?
It makes very little financial sense to spend months on a native app that runs on handful of devices
"Handful" = > 500 million... that's just for iOS. Android has more.
I'd say 500 million potential customers warrants SOME degree of effort.
Also if it's so easy for me to build out something mediocre in PhoneGap that works for everyone, doesn't that mean the inevitable Chinese clone comes out on my tail all the faster?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Ok, no.
That is not "catching" up that is merely putting a raw graphics adapter canvas in a web browser.
That is not providing API hooks for various system level resources.
There are a number of native libraries devoted to quickly defining and presenting working forms in iOS.
For charts, there are a number of really excellent solutions that cost money, but not much and they deliver really nice, dynamic graphs with many options.
If I were doing a heavy enterprise form app I'd still go native.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The debate hasn't changed about HTML5. It is just that we are consumed by the systemd controversy.
Not even close
The core difference is that Javascript is slow but less likely to result in a permission error that drains your bank account.
The webGL demo on that site is pretty impressive.
Yes, so why would the debate change?
Scrolling on smartphones with complicated UIs is a nightmare using html. If all you need is a long list and nothing or a few links then responsive can work, other than that it's always going to be an issue. React-native seems to be a way to go. Learn once, write anywhere. I don't think their Android version has dropped, may be wrong, but I played with the ios first release and it was great. Really smooth iPhone experience.
Yeah it's another framework but it's less like joining a religion than Angular or a creepy cult like Ember and it solves a real problem of look and feel on the mobile devices.
Facebook's React Native is an interesting data point in this conversation: https://facebook.github.io/react-native/
You write HTML, Javascript, and CSS, and you get a iOS native UI (Android "coming soon"). They're making an attempt at the "Best of Both Worlds".
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
And most phones have all the horsepower and HTML engine quality to pull off a lot of the sorts of user experiences you'd like (there are still rough spots though).
The device APIs in HTML5 now cover almost all the native capabilities you would want, once ServiceWorker and push notifications are fully deployed. They actually do a -better- job when used correctly because permissions are requested as needed instead of upfront, which avoids scaring the user off as they wonder why your recipe app's update needs camera and microphone support when you add the ability for users to post a Vine video of their baked goods (for instance).
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web, because everyone just lands flat in the "its crap" opinion instead of discussing the few missing capabilities and the specific performance issues they've seen.
The web ain't perfect (yet) but its getting better every day, and has no vendor lock in or censorship issues like the mobile walled gardens have.
Early versions of Firemonkey sucked, but it's worths taking a peek. Native performance FTW.
http://www.embarcadero.com/products/rad-studio
J-F
Goodbye Slashdot. You've changed.
Web apps are infinitely easier to create and deploy.
Well, no. I can buy an order of magnitude, maybe — but not infinitely easier. If it were infinitely easier, then it would take zero seconds.
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
Well, that's clearly a matter of opinion. I have done the same, and in my opinion, nothing beats going native (assuming you are trying to achieve the same end results, which is difficult-to-impossible, considering how limiting web apps are.)
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web
Why would you think this? Couldn't it equally be that Slashdot is filled with experienced engineers who find it instinctively painful to write applications in a way that provides a substandard user experience compared to the other options available?
and has no vendor lock in or censorship issues like the mobile walled gardens have.
That's a separate issue, and one that doesn't apply to Android (since you aren't required to work inside any walled gardens).
> Web apps are infinitely easier to create and deploy.
At this point, developing native Swift apps is MUCH easier than developing web apps.
Swift changed everything, and Javascript-based web apps just won't be able to compete.
Limiting - how. Please be specific or we can easily conclude you might not have as many clues as you think you do.
Honestly I'm not sure I buy an order of magnitude.
That said if user experience is secondary (internal tools for instance) a quick and dirty web app might manage that order of magnitude but once you want some sparkle, maybe some animations, the advantages dry up quickly. It always seems like the web devs can get the basic feature implemented faster but getting it refined and polished seems to take them more time than app developers and the results are not necessarily as good.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
However, the time it takes to develop a native app vs a web-comparable app is immensely different. Web apps are infinitely easier to create and deploy.
Only if the "app" consists of a pull-down menu, a fill-in form and a database. Now try to do a 3D FPS game app, using OpenGL, with HTML5. Is it theoretically possible? Sure. But it will be incredibly difficult to manage polygons, scenes, frame buffers, etc. in a language where an integer is a float, and a float is sometimes a string, where the only data structures are arrays and hashes, and errors are almost never caught by the compiler.
I have written apps in both native code and Html5+Javascript. Html5+JS is almost always my first choice if I just need to slap together an interface to some backend service. But I would never go that route for an app that requires structure, planning, teamwork, and real engineering.
Now, come on, there's no need to start getting nasty here.
The two main things that are limiting are that you can't take advantage of the unique strengths of the particular device you're running on, and the performance always (and inevitably) suffers.
Whether those limitations are important depends entirely on the type of app you're writing, although I maintain that maximizing performance is always important on mobile platforms in order to maximize battery life. That said, I am completely aware that the rest of the software industry long ago decided that sacrificing performance was acceptable in exchange for reducing developer effort. Which is one of the reasons why software quality has been declining for decades now.
"The benefits of a build once, deploy everywhere platform are pretty much a myth."
There will always be some tweak needed somewhere that blows the whole build-once-and-deploy-everywhere myth right out of the water. Android fragmentation being the latest example to blow up mobile dev. This myth has been around since C was released and it never seems to stop getting press, even though we all know it ain't true.
Please refine the question, I don't understand it. In particular, what is native vs javascript necessarily about mobile application frameworks?
In any case, more and more companies use SaaS with a service oriented architecture nowadays, since they want isolation of the different services as well as high reliability and scalability. In big companies, they build their own frameworks, Javascript/XML (or HTML) are quite popular for the UI, while C++ seems to be favored for the backend of the service itself.
How the heck do I get Swift apps to run on my client systems that are running Windows, Linux and Android?
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
Well, that's clearly a matter of opinion. I have done the same, and in my opinion, nothing beats going native (assuming you are trying to achieve the same end results, which is difficult-to-impossible, considering how limiting web apps are.)
My experience as a webapp user on the desktop is that for the most part the functionality and responsiveness of native applications can be achieved if the developer(s) know how to develop webapps suitable for desktop use within a web browser.
"The tools available to developers who need to build an application once and deploy everywhere have exploded"
Well, that's what happens when you try to cram a single square peg into millions of different round holes -- things explode.
Write a preprocessor that translates Swift to Java.
If the app is trivial, the web can work. It's good at managing my shopping list. But I still use native apps for all the real stuff. Email is native (Thunderbird), Docs are all native with Office, games are all Native (from massive FPS to even Farmville!), my music is native (Pandora Air app, native+SDK), the Whats Up sky app I just bought for my HTML5 tablet is ... Native. Everything I use is native unless it's just a list of strings on a web site. git is native. Gerrit isn't, and I wish it was. Studio is native. Eclipse is native. The compiler tools are all native. My debugger is native, if I am lucky enough to have one. My browsers are all native. The F1 app on my tablet is native, etc. etc. it's a really old dumb discussion and in the end NOTHING HAS CHANGED. NATIVE RULES THE BEST, the WEB GETS THE REST.
I use Firefox OS, you insensitive clod. :)
I was never a huge app user on Android anyway. Games and fart apps, yeah nah. If the latest online service that syncs to the cloud and data-mines my personal details wants my business, let them write a mobile web page!
The lack of native apps like Skype is the main thing I might miss on my next trip, calling family via hostel wifi. But hopefully I can get my relatives to adopt firefox hello! :) I've been wondering about one of those smart fitness wristbands such as Mi Band that sync to a 'computer' via Bluetooth. I'd need then to boot Android-x86 running in a hypervisor with bluetooth pass-through.
But for most stuff, I can't say I miss Android too much.
This. If everything is done in the client, the application will lag every time anything processor-intensive is done. Likewise, if the client has to call back to the server every time it does anything, the client will lag on high-latency connections or when the server is overloaded. There's a balance there; the trouble is that most developers don't know how to find it.
I think part of the problem is that web app developers seem to fall into one of two camps: Do everything locally for the best chance of availability, or do everything remotely for the best performance. The first camp is almost right, they do achieve better availability doing everything locally, right up to the point where their app becomes unusable due to processing lag (in other words, they're wrong). The second camp is also almost right, they do achieve the best performance in their local development environment, running in a VM on their workstation, where they're the only user; that falls apart the moment they add thousands users and wildly-variable latency between client and server (in other words, they're wrong).
What I prefer to do is provide all capabilities in the client (a-la first-camp), then identify those that cause the application to lag and implement them on the server (a-la second-camp). Once a function exists in both the client and the server, the client can run a job locally and on the server. If the local job finishes first, the client alerts the server and the server-side job is terminated; if the server returns its result first, the local job is terminated. I find that this structure provides the best performance, as well as availability, since the faster resource will always be the one to return the result used; and if the server is unavailable, times out, or returns an error, the application still works. I find that most users are willing to accept occasional slowness during server outages and upgrades, especially when the application is generally very responsive under normal conditions.
That, I'm sure, can be built upon to predict (e.g. based on bandwidth, latency, and local vs server load and performance) which job will finish first and only start the remote job when it will be the clear winner (still starting the local job just in case). That would give you the benefit of reduced server requirements without impacting application performance (unless you take it too far and don't keep any spare compute power online). I haven't run into an instance where this has been necessary or where the savings would be worth the effort (as evident by the number of cancelled jobs compared to completed jobs), but I'm sure such a case exists.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So many comments here miss the mark so widely. There is NO implication that a hybrid (or, more broadly cross-platform) native app has to rely on a server. None, zero, zip, zilch, nada. None.
You DO NOT NEED a server for native hybrid app! Only if you happen to need a centralized database. Use a server if you need a server. Period. For example, you have an app that shows current news, current sales figures, that updates the company database in some way? You are going to have one or more servers involved.
If you need a server, you need a server, whether webapp, hybrid app, or fully-native app. If you don't need a server, you don't need a server.
Even a "webapp" doesn't need a server, once the webapp is loaded onto the device.
Local databases are a common feature of hybrid apps, especially in the Enterprise world. Sync the local database to a central database when connectivity is present. Users can continue to work with the app offline. Of course, this is no different than with a native app. The argument is fallacious - you are imagining an architectural model that simply isn't common. Hybrid apps do not have any different networking requirements than native apps. That is, if they need access to a network, then they need access to a network. Nothing about the architecture demands servers.
You are correct. However, the post I was replying to was about web apps. If you want to complain to someone about getting it wrong, complain to that poster.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Yeah good point that sounds trivial, like using a RumplestiltskinJS quadrilateral framework that all the cool kids are running.
You can at least quit worrying about your numeric types if you use asm.js
Turns out that's a reasonable expectation. http://arstechnica.com/gaming/...
I would have read the rest of your comment, but you're obviously playing a terrible game of telephone. Every language is parsed. Java is a compiled (not interpreted) language.
Back to school, man. And learn what "interpreter" is.
Compiled language can also be interpreted. Progress was made since the times of BASIC.
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
Even if you wrote an "app", that doesn't make you a developer.
Most "app"s are so primitive and rudimentary, that their creation can be probably fully automated.
... you add the ability for users to post a Vine video ...
... I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web ...
Oh we do.
But we also know that this shit will blow over. As it does every 2-3 years. AKA "eternity" in the web development terms.
... the specific performance issues they've seen.
All over the fucking place.
I find it quite moronic, that with every new "cool" tech it takes the top performing PC about 1 second to display a table with ~1000 rows. I remember when LAN was bottleneck. I remember when HDDs were the bottleneck. I remember when modem was the bottleneck. I remember when crappy GUI toolkits were the bottleneck. Now - it is the crappy Web UI which converts and reconverts data dozen times.
The web ain't perfect (yet) but its getting better every day ...
Don't kid yourself. It's not.
It is the hardware becomes faster and more tolerant to whatever shit you throw at it.
As it always did to accommodate the R&D whims of the day.
The two main things that are limiting are that you can't take advantage of the unique strengths of the particular device you're running on
There was a reason I wanted specifics. This is a generic comment and it generally isn't particularly accurate anymore. Do you know of any specific things that would suffer on any specific platform?
performance always (and inevitably) suffers
Again, not specific, and generally extremely far from the truth. Yes, Javascript runs slower than native code, but that isn't necessarily an issue. It depends on what your app does. Many, many apps are not calculation heavy, they collect data from a back-end server, present it to the user, allow the user to alter the data in some ways and then send the data back to the server. Any slowness in such application will be caused, by network slowness in almost all cases. In other words, the performance of the underlying GUI language is mostly irrelevant as long as it is fast enough, and Javascript is, for a huge number of applications.
So, at this point in time you have not given any kind of arguments that supports your position.
Have you developed applications in Javascript that suffered performance wise? Have you developed any mobile applications that you assume would suffer performance wise?
It's easy to parrot the "wisdom" of others, that's why I asked you to be specific. You weren't.
FirefoxOS is basically a web browser with JS APIs to access the hardware.
All apps use web-based technologies, which means that the only thing needed for any OS to use FirefoxOS apps is a web browser that support these APIs, no need for native code unless you really need performance. You can already run some apps on Android as using Firefox components.
I really hope that the guys at Mozilla focus on the compatibility aspect by making it easy for developers to use the FirefoxOS framework on other platforms (Android, iOS, Windows Phone, Desktop, ...) rather than attempt to compete.
Try coffeescript.
Then I have no idea what you mean by "be specific". I was plenty specific enough for this discussion. I doubt that you actually want me to dive into the technical details.
I will add a clarification about my comment about performance. If by "performance" you mean "speed", then you are (as I already said) correct that what is good depends entirely on what the app does. However, performance means a lot more than speed. It also means things like CPU cycles: an app with good performance is an app that uses the least possible CPU cycles to accomplish a task. The importance of this goes beyond speed. On mobile devices, for example, it also goes to battery life.
Any app that is written in Javascript (or any other interpreted or semi-compiled language) burns through a lot more CPU cycles than is required for the task. That is why I say that performance inevitably suffers. This is true even is you don't notice a speed difference as the user.