idlewan

They do. However, don't be so quick to dismiss the point they are making: on high-end devices at least, html5 apps are at least as good/performant as native apps.

By the way, Apple, Google and Microsoft each have an agenda as well: to enclose developers in their walled garden, making them learn and use proprietary non-cross-platform APIs so that apps can't achieve a "ship new features everywhere, at the same time, easily" approach. They also want you as a user and a developer to abandon your phone after a while by deprecating APIs and making the OS effectively non-updatable, and making it very hard to update manually (do you know how to port Cyanogenmod to your device? Fix its bugs?).

as soon as your target middle to low end handsets it is turtle speed time.

... on Android. It probably isn't great on low-end or old hardware (although light pages should still run fine). However, Firefox OS is designed and optimized for running those webapps on low-end hardware, contrary to Android.

Which vendor do you trust to make the web fast? The ones who have nothing to gain from it, because they wouldn't be able to retain users anymore who could switch to a new OS in a heartbeat if all the apps were webapps? Or the vendor who made huge contributions to the open web?

You might also want to check out what Sencha did with Fastbook: https://www.youtube.com/watch?v=wCn3R3-XxBU

You seem like you can't conceive that html apps on a FirefoxOS phone can be just as fast as any good app on another phone.

If you tried Cordova/Phonegap on Android and didn't find the performance adequate, if you tried a web view on iOS and didn't find the performance adequate, just don't take the shortcut of believing that you would get the same inadequate performance on Firefox OS. The whole stack is different.

HTML5 based os need a lot of processing power,webos already proved it in the past. WebOS and its fate proves nothing regarding the performance of mozilla's OS.

That's why firefox os will fail,it's not designed for lowend devices. It IS designed for lowend devices. My Keon boots more than 3 times faster than my HTC Hero. In its early days, B2G was even booting in 10 seconds (flat). You just didn't see it with your own eyes.

I suggest you revise your 'pure crap' opinion when you actually see the OS running in front of you.

If this was a troll (feature phones? are you kidding me? We're talking about a phone that can really browse the web, here), I don't know what to say. Otherwise, you're just full of FUD.

Disclaimer: I have only used the Keon. I don't have any experience with the ZTE or another one, but I'm still pretty confident they're not 'pure crap and a total waste of money'.

My HTC Hero (which is totally obsolete by now - you can't upgrade Android phones once the manufacturer released other phones and doesn't care anymore) is only fluid on the home screen. Everything else (even the Play store!) is slow and laggy. I can't play most games and can't install most apps on the Hero (armv6 means no Firefox, no Telegram, no 'anything using jni').

So I strongly disagree: the Keon is good enough, and the first Android phones were NOT better (you seem spoiled, high-end user! Just because it's not as fast as $400 phones does not mean it can't be interesting).

Thus, I recommend `atool`, which use tar, unzip, unrar, ... but wraps it all in a very good UX not depending on the archive type.

    aunpack my_archive.zip
    aunpack my_archive.rar
    aunpack my_archive.bzip
    ...

The first sentence of the quote, however, is ridiculous. The OS doesn't "live mostly in the cloud". The OS and default apps are installed on the phone and don't need internet to run, they live on the phone. Web technologies != cloud.

I guess you can't expect technical details to be right when you're talking to some non-technical guy ("Wayne Lam, senior analyst for consumer and communications at IHS").

If I try to answer your points:

-> 1) The procedure keyword comes from Pascal. I am not shocked by it, when I learned programming the teacher used to call them procedures also. The 'var' in procedure arguments could be considered the opposite of the 'const' of C/C++. Everything is const by default in Nimrod, but if you want something modified in place you indicate it.

-> 2) Herm... I got nothing. I haven't used include, I didn't see the use for it yet.

-> 3) 'when' is compile-time, 'if' is at runtime.

-> 4) Unnecessary? varargs is quite useful. For example, if you use redis, you can do db.del("akey", "anotherone", "otherkey"), instead of having to fiddle with an array. Varargs makes some calls cleaner.

-> 5) "The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions." from the Nimrod manual (http://nimrod-lang.org/manual.html). It forces you not to name functions and variables too closely. So you won't be able to have different things named myStuff and my_stuff because it will refer to the same variable or proc. You enforce your own writing style. That is debatable. You have others enforcing a style, like with gofmt. The case insensivity did not disturb me, though (but I admit it surprised me at first).

So you need less explicit error-checking everywhere with a language that support exceptions.

It can improve readability a good deal. Here's an example I made: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Go version: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

I also tend to prefer catching errors early, and having a typed language that warns and errors at compile-time is great.

Constructive criticism (like in this article) is a valid way of trying to convince others that a better way is possible. He is cleary stating the use cases he would like the tools to fix.

Shooting down the critic by saying 'so fix it yourself/so fork off/so go code another lib out of the 30 000 that exists' is, on the other end, not constructive. Do you have better arguments?

The old repo (https://github.com/UWNetworksLab/uproxy-common) mentions the new repo, which is hidden / not available.

So, not yet open source. So, still closed source, for now.

You think the DRM blob would be less slow, less buggy, less closed and less resource-hungry than flash is and has been? Think again.

I would use it so much more if it was between H and J.

How do you stretch your finger towards the middle of the keyboard with no issue? Stretching just to type a letter is fine for me (think Y, H or B), but staying on the TrackPoint is hard.

A great amount of time in software development is spent searching for libraries and reading their docs, to avoid reinventing the wheel each time you are doing something pretty common ('saving a file').

Polyfill and shim libraries are making the lives of developers so much easier. The problem is usually to know about them. One year ago, I remember searching for Blob and File saving shims, without much success. Thus my fascination, by randomly bumping into what seems great ones.

I second that. Use Firefox for Android, Opera, Dolphin... They are all better than the stock browser.

It does make the 'first webapp' very small, which is quite elegant.

Do you often read the output of some library macros that the C pre-compiler generates?