Desktop apps won't have a "comeback" for a lot of us. There have always been questions about the viability of these sorts of online services. So we did the smart thing, and never put our data and apps at risk to begin with. We have nothing to come back to, since we never left in the first place.
Ubiquity should not be an excuse for the promotion of what is, by all objective measures, a rather poor programming language.
This is especially true when it's an environment where there are numerous other languages available, and they're all so much better than JavaScript. Lua, Python, Perl, Ruby and even Tcl would all be better choices.
It's mildly excusable when it comes to web browsers, because JavaScript really is the only viable option. But that just isn't the case with a full-featured environment like OS X.
I don't see why codereflection needs to spell it out. The problems with npm, and JavaScript in general, are quite apparent to anyone who has used them. And if you haven't used them, a quick search engine search will turn up this information many times over.
It'd make sense to ask for such clarification if the information truly wasn't available elsewhere, and accessible with a quick search. But that's obviously not the case.
It's pointless to rehash this obvious stuff over and over and over and over again.
It'd be good if there were a canonical "Why npm sucks" article, like the "fractal of bad design" one for PHP.
This one seems like a fairly reasonable candidate: http://www.jongleberry.com/why-i-hate-npm.html (though the "nested dependencies" bit needs much more swearing, and I disagree with the last paragraph suggesting things in Ruby and Python land are just as bad).
In the last paragraph there, is he saying that Golang is 'bad' because it doesn't have a package manager? Does it need one? I always assumed 'go get' was enough.
It is certainly isn't obvious to me. NPM is the best package manager I have used for a specific language. I do think there are things that can be improved, like everything else, but overall I think it is pretty good. And the vast majority of complaints I have seen are just nitpicks. So yes I would be very curious to know what you think is so obviously broken with it.
While I don't hate npm, there are better examples of how to do package management. For example, Nuget gets a lot of things right with no nested dependencies.
It reminds me of Chrome OS and Firefox OS. These all are based upon the Linux kernel, so they could potentially offer a very rich user experience like so many more traditional Linux distributions do. Yet they intentionally cripple themselves into being limited, JavaScript-only platforms.
This would be understandable if, say, storage space was expensive, like it was in the 1980s, and the software had to be kept lean and limited. But that's clearly not the case today, even when it comes to low-end smartphones.
The same goes for runtime performance. It'd be one thing if software written in JavaScript was consistently and significantly faster than software written in C, C++, and other commonly used languages. But that just isn't the case. Unless we're looking at highly tuned and highly unrealistic benchmarks that even the JavaScript VM authors have focused on making run fast, JavaScript's performance is quite bad.
It would be understandable if perhaps the user experience could be improved in some way by them providing superior alternatives to the traditional userland software offered by Linux distributions. Yet this isn't the case, either, because some of the biggest complaints with Chrome OS and Firefox OS are that the bundled software is awful, and users have no real recourse due to the very limited environment that both offer.
As far as I can tell, users just can't win with a system like this. The kernel is powerful, but this power is isolated and kept inaccessible. The userland experience is much worse than what one would get if just using a traditional Linux distro, and running the JavaScript software on top of that. The benefit to the user just isn't apparent.
Well, with FirefoxOS, you don't have Android's Dalvik nonesense nor iOS's restrictive marketplace. They needed some userland language, since the isolation keeps security high. These mobile computers aren't used in a security conscious way, and many developers are unscrupulous in the environments. Give them the power to install rootkits, and they will.
I'd say it's even less capable. Shared hosting providers typically allow the use of Perl, Python, PHP, Tcl, Lua and sometimes other languages for CGI scripts. From what I can tell, this service limits you to Lua only.
Definitely! Just as a shared hoster is less capable than running your own VM and a cash register is less capable than a laptop. That doesn't mean those things aren't useful. :-)
I'd say that most of the time, people are more productive with more specialized tools if the tool happens to specialize in what they're trying to do.
But it also doesn't offer many of the benefits and much of the functionality that Scala offers. A familiar C-like syntax, static typing, and so on are very important for a lot of Scala's users.
It's really absurd when people call Python 3 a "disaster". There was nothing disastrous about it. In fact, hindsight shows us that it was actually a very good path to take.
Python 3 didn't negatively affect Python 2 or earlier users. Their code still runs fine, and is well supported by a huge number of libraries. They weren't forced into upgrading against their will at any point.
Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language.
Much Python 2 code, especially well-written code, can be automatically converted to Python 3 code with little to no effort. Anyone with any sensibility who has been writing new Python 2 code within the past few years has been keeping an upgrade to Python 3 in mind. Their transition should be quite painless.
Over time, more and more existing Python libraries have supported Python 3, or been replaced with significantly better replacements, as the need arose.
The fact that we see so many libraries simultaneously supporting both Python 2 and Python 3 goes to show that the community is not "divided" or anything like that.
The only downside is that it took a few years longer than people may have initially been expecting for certain libraries or frameworks to support Python 3. But at this point in time, Python 3 is a clean, usable language with very good third-party library support. Existing users weren't forced into using the new version, yet those developing the new version weren't constrained by compatibility concerns. The end result is an improved and usable language, achieved with minimal disruption.
Perl 6 is an example of a real disaster, on the other hand. It still doesn't have a truly good implementation, even after 10+ years. Not only is Perl 6 pretty much unusable in practice today, but the uncertainty it caused stunted the growth and development of Perl 5 for quite a while. It is only recently that we've seen people finally realize that Perl 6 is a lost cause, and get back to using and evolving Perl 5. Compared to Perl 6, the Python 3 development process was perfection.
Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language.
Sure. But the improvements aren't really that great, and IMO they weren't enough to justify breaking everything. Some combination of a JIT compiler, GIL removal, and optional typing might have been.
The end result is an improved and usable language
And this is why I view Python 3 as instance of choosing purity over practicality. Python 2 was and is a very usable language. It's vastly better than JavaScript, which took over the world by virtue of being available everywhere and having halfway decent performance, which ended up outweighing its huge flaws as a language. I can't help but think that we'd be better off if the effort spent on the Python 3 migration had instead been directed toward speed and browser support.
Perl 6 is an example of a real disaster, on the other hand.
It's a major release and the language does need to evolve at some point. I'd agree that Python maybe got a little too ambitious with the upgrade but it was definitely a good thing.
> Not only is Perl 6 pretty much unusable in practice today
I don't think that's true anymore, and for some subset of people, hasn't been true for a while now. If you consider performance the big blocker, that's getting better all the time[1],and is close to being competitive with Perl 5 ins some areas.
"Compared to Perl 6, the Python 3 development process was perfection."
Comparing to a series of "Apocalypses" (the term used early in perl6 development to refer to radical breaking changes) is not great evidence that python3 is non-disasterous.
Do you really think python3 being 6 years in limbo (and counting) is a good thing? Probably not fatal, but I don't see how it's good.
From the very start its goals were clear. Yes, it took some time to implement them, but this was done rather efficiently and quickly.
Unless you were using one of a handful of libraries that didn't put forth the effort to be compatible with Python 3, it was very easily to adopt Python 3 early on, and to use it effectively.
I worked with a group that adopted Python 3 relatively soon after its official release. This would've been around early 2009. We developed a number of large systems using Python 3, without any major problems. Sure, we ran into bugs now and then, but we reported them and they were fixed soon enough. We helped port some libraries to Python 3.
We didn't regret the decision to go with Python 3 then, and the last I talked to people still involved with those projects, they don't regret the choice now. They're glad that their millions of lines of code are targeting Python 3, which is without doubt the future of the Python language at this point.
I don't know why people such as yourself continue to portray Python 3 as a "disaster", when all of the evidence and much of the experience with it shows the complete opposite to be true.
It was a smooth transition for Python 2 users who didn't want to or need to upgrade. It was a smooth transition for Python 3 early adopters. It's a rather smooth transition now for Python 2 users who want to use Python 3. "Disaster" just isn't the sort of term to describe a transition that goes well for all involved.
> Unless you were using one of a handful of libraries that didn't put forth the effort to be compatible with Python 3, it was very easily to adopt Python 3 early on, and to use it effectively.
You're speaking in the past tense about a present problem. Many large projects that would like to migrate to Python 3 cannot because the library support isn't there.
This is in no way meant to disparage the motivations that led to Python 3, because it's better in every way than its predecessor. Only that the transition problems are still present, and the larger the project, the more difficult the transition.
Sage (http://www.sagemath.org/), a project I'm involved in, is just one example -- a large, complex project, it relies on dozens of mathematical and other libraries, and to transition to Python 3, all the libraries would have to be available in Python 3 versions -- even one exception would prevent the transition.
It's safe to say that everyone involved would like to see a transition to Python 3. But it's not possible, and for the foreseeable future it's not even likely.
The reality is that customers just don't want to use Firefox OS. Even with Amazon's support, it would still be very inferior in many ways to Android and iOS, and even to some of the other less-popular mobile OSes that are already out there.
Given that Firefox OS apps written in HTML5, CSS and JavaScript should run just as well on Android and iOS, anyone actually wanting to use such apps is better off just getting an Android or an iOS device. That way they can run the Firefox OS apps, as well as all of the other apps that Android or iOS support.
> The reality is that customers just don't want to use Firefox OS.
Is a Firefox OS device on sale in any US retail store? I've never even talked with another person that had heard of Firefox OS. How could you possibly know that customers don't want it?
I've never even talked with another
person that had heard of Firefox OS.
How could you possibly know that
customers don't want it?
I could pick anyone who didn't have the slightest clue what FLOSS means, besides something they should do at least once a day, and ask them about a FFOS phone. Here's how that conversation would go down:
Me: Hey, did you know you can get a smartphone for $33?
Them: Cool! That sounds great, and $66 cheaper than my iPhone.
Me: Yeah, that would totally pay for 3 weeks of your cell phone bill.
Them: Sounds good, so I can get Instagram on it, right?
Me: Yep, except you won't be able to post photos.
Them: Oh. How about Flappy Bird.
Me: Nope, sorry.
Them: Darn, but that's ok. Too addictive. How about Uber, Whatsapp, and Facebook?
Me: Totally! Mobile web all the way, baby! HTML 5!
Them: Awesome!
<2 Weeks Pass>
Them: I went back to my iPhone. Those mobile websites suck.
You obviously wouldn't be having that conversation with me. You might want to consider that others might not use a phone the same way you do. ("Anyone" is a pretty bold claim.)
Though I would really love it if you could show me where to get a $99 iPhone.
I realize that, but there are a lot of people out there that are smart enough to take the monthly cost of the contract into account, however you want to describe them. I do a lot of programming, but am a "non-tech" guy myself.
More people bought 1958 Edsels than 1958 Volkswagen Beetles too, that doesn't make the Edsel a better car than the Beetle. Popularity is not the same thing as value.
Emotion is totally irrelevant here. I don't "hate" Firefox OS, nor do I "like" Firefox OS.
It's just a tool, so I give it an objective, unemotional analysis. That analysis shows that it lacks the features and functionality that are needed for it to be a useful tool for the vast, vast majority of users.
Most people use a phone for practical reasons, not ideological ones. They don't care how "open" it may be if it doesn't run the apps they need or want to use. Firefox OS will have no chance of succeeding in the long run as long as it continues to provide a sub-par user experience.
These sorts of arguments or claims aren't very convincing, or don't appear to hold true in practice.
The claim that the development of Firefox OS is somehow more "open" is very suspect. Even if the source code is publicly available, and outside contributions may be accepted, Mozilla is still going to act as a gatekeeper, which inherently limits which contributions will or will not make it into Firefox OS. That doesn't strike me as being any more "open" than the development of Android or iOS is. A contribution to Firefox OS is a suggestion at best, but one that can be unilaterally disregarded by Mozilla without any sort of consequence to Mozilla. That's no different than making a suggestion to Google about Android, or to Apple about iOS.
The recent tendency of Mozilla to force totally unwanted changes (like Australis) upon Firefox users, even after very vocal objections to such changes, further makes me skeptical about how much openness there truly is when it comes to their products. Any objections, suggestions, feedback or contributions that aren't compatible with the direction that Mozilla has already decided to take appear to be ignored. "Openness" means that non-Mozilla parties can actively influence the development and future of Firefox OS. Merely being able to provide non-binding feedback or suggestions, even if in the form of code, is not really openness.
Likewise, the claim that Firefox OS "doesn't limit your freedom" is suspect, too. How can that claim be made when developers are pretty much forced into using HTML5, CSS and JavaScript to build apps? I don't consider myself to have "freedom" if, as as developer, I'm forced into using JavaScript or some half-baked "transpiler" that attempts (usually poorly) to target JavaScript.
It's also odd to claim that these apps will somehow be portable to other platforms, especially if they're using APIs that only Firefox OS currently supports. Even if there have been efforts to standardize these APIs, the fact that they aren't widely implemented by other browsers or platforms renders them as proprietary to Firefox OS, in practice, at least for some time. A standard that exists but isn't widely implemented probably shouldn't be considered a standard.
And the "HTML5 is a first-class citizen" distinction seems quite irrelevant in practice, as well. If the same apps will supposedly work on other platforms, either natively or with the help of something like Cordova, then they're just as "first-class" there as they are on Firefox OS.
So as you can see, the arguments you gave are theoretical at best, and some of them don't even appear to hold true in reality.
> Even if the source code is publicly available, and outside contributions may be accepted, Mozilla is still going to act as a gatekeeper, which inherently limits which contributions will or will not make it into Firefox OS.
Even the Linux kernel has submodule maintainers, and Linus himself, who will need to approve your changes.
Your other option is to fork, apply your changes, and then use your custom-baked FirefoxOS on your phone.
> Likewise, the claim that Firefox OS "doesn't limit your freedom" is suspect, too.
It respects your freedom (see: http://www.gnu.org/philosophy/free-sw.html) which means that you're free to add support for programming additional languages, if you like. Your additions may never make it into FirefoxOS core, but that doesn't mean your phone can't have those additions.
> And the "HTML5 is a first-class citizen" distinction seems quite irrelevant in practice, as well.
No it doesn't. Think about your argument in terms of natural languages. There are countries where English, French, Spanish are the official languages. There are also countries, where these languages may be spoken, but they're not official.
> A contribution to Firefox OS is a suggestion at best, but one that can be unilaterally disregarded by Mozilla without any sort of consequence to Mozilla. That's no different than making a suggestion to Google about Android, or to Apple about iOS.
You are seriously saying that Mozilla's openness is no better than iOS's? That's one of the more ridiculous anti-Mozilla statements you've come up with over the years.
(disclosure: I'm an employee of Mozilla working on localization technologies for Firefox OS)
> That's no different than making a suggestion to Google about Android, or to Apple about iOS.
I believe you are wrong. There is a substantial difference between being able to send a suggestion to Google or Apple, or even being able to write a patch against an open source subset of Android codebase released months after the phone release, and being able to fork Gaia repo, patch it, and submit a pull request.
I've been helping volunteers go through their first patches for weeks now and it works great! They have helped me clean up the code base for Firefox 2.1 in many ways.
They now submitted their first patches and are skilled to start working on more complex problems and suggest features.
You are right, that that doesn't mean that anyone can submit any random feature and get his/her PR merged. That would result in chaos. But they can suggest features, work with module/app owners, and write the new features for the platform. They can participate in decision making process, weekly calls, daily meetings and day-to-day IRC conversations because it's all open and in public.
In the end, if things go wrong, they can fork the platform and start working on a fork. You may respond - hey, Android has it with CyanogenMod!
If that was your first thought, please read about struggles CM has with Google or read arstechnica article of how someone tried to use Android without Google services.
Android sources are only partially open and are released many months after product release. Firefox OS sources are available for hacking from day 0 of work, many months before the product is ready. (for example: if you fork github gaia repo, you'll have the code that will land as Firefox OS 2.1. Current stable version is 1.3).
> The recent tendency of Mozilla to force totally unwanted changes (like Australis) upon Firefox users
Did you read the studies and feedback analysis or are you extrapolating your own sentiment onto majority of users?
> "Openness" means that non-Mozilla parties can actively influence the development and future of Firefox OS.
That's exactly what is going on with the project right now. Many external contributors, both individual volunteers, and companies, are involved in the development process of Firefox OS.
> Likewise, the claim that Firefox OS "doesn't limit your freedom" is suspect, too. How can that claim be made when developers are pretty much forced into using HTML5, CSS and JavaScript to build apps?
That's a fallacy. Freedom in question is referring to the freedom of the user to choose how he wants to use his device, not to programming languages that are supported on the platform. It's like saying "roads does not give me freedom if I have to drive my car on them and can't use them with my submarine of choice".
> A standard that exists but isn't widely implemented probably shouldn't be considered a standard.
You are right. I believe that it's just an oversimplification.
But the sole fact that all API's created in the process are on the standardization path is a major push toward empowering web technologies to be fully capable of handling more advanced applications and systems and does set a precedence.
We will soon live in the world where HTML+DOM+JS will be enough to write operating systems and apps that will work on multiple platforms. That's the opposite of vendor lock in that major platforms are leveraging.
