Good job Facebook.
I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's something I rejoice about. Javascript is like anti-Batman: a language we all deserve, but not one we need.
No,it's not fine, it's a horrible language,with a few good features that saves it from being a catastrophy.hence "Good Parts".
Or we wouldnt be here talking about Flow,Typescript or others if the language was "fine". JS was clearly not designed for what we are making out of it today.
But since there is no way around Javascript in webdev,good or bad,it doesnt even matter.It exists.TC39 isnt going to fix types,so types are fixed in userland.hence "Flow".
Also we already have Strict mode; I imagine in the future it will get more and more uncompromising, so the JS subset we'll be actually using will be just fine.
It used to be that building a competent web app was something you could do in a number of different languages, these days you really need to know JS or one of it's skins and it's made developing for the web much less friendly to people that don't do it every day.
For example, yes callbacks were very messy but very soon we will have generators. And, yes, the scoping was nasty but soon we will have the 'let' keyword. I cannot remember where I read it, but I do also remember seeing a talk about some proposals to extend "use strict" to allow people to fix some of the type-casting behaviours made infamous by wat, too.
My point isn't that everything is fixed and we can stop complaining about the bad parts. My point is that it is very impressive how those in charge are handling the evolution of the language.
I think it's worth taking a bet on a language which improves so much every year.
Then deal with the 5-10 years or so legacy browsers hang around with significant market share.
JS was anointed long ago, and if we knew then what we knew now, maybe it wouldn't have been so? I remember DHTML and how silly it was and how it was just a toy and BOOM! Ajax.
So here we are. Every browser supports it, none could agree to change, so we deal with what we got. Better tools are better than nothing.
While its no Haskell, it certainly isn't much more verbose than other dynamic languages anymore. And a typesystem like TypeScript or Flow pretty much eliminates the rest of the gotchas.
Off the top of my head, there are two embarrassing holes: bigger integers and parallelism. Can't think of anything else at the moment (macros maybe, but they're a double-edged sword wrt tooling). Wonder if anything else is missing?
I'd go so far as to consider it a feature.
This is a long and complicated answer. I doubt I'll do it justice in a few paragraphs, but I'll try.
In one word: simplicity. Primarily, not having parallelism is far simpler than having it. Yes, some models of parallelism are simpler than others but at the end of the day I think we can all agree none of these models are as simple as not having parallelism. As per "net negative": yes, ofcourse, not having parallelism is a "negative". However, "net negative" is interestingly more linked to the applied domain rather than the actual concept. Simply put, the domains that JavaScript is used in don't heavily rely on parallelism (or rather, require the optimization of parallelism).
Thinking about this now, its sort of similar in nature to why people like garbage collection. There is an inherent negative to using a garbage collector, however, (I think we can both agree) in certain (most) domains it turns out to be a net positive. Why? For the same reason, simplicity.
I mean, I could go on, but I'm trying to be as concise as possible. Hopefully, that was a useful. I'm happy to elaborate if you have more specific questions about this.
* s/simplicity/developer efficiency + implicit safety guarantees/g -- Since "simplicity" is quite vague;
With Erlang you can't share memory [0], but in exchange you get sequential code (no callbacks or yields), true parallelism, and even distribution over a cluster. With node.js all the asynchronous calls live in the same memory space, but code is written with nested callbacks (or yields), and of course you get no parallelism.
[0] There are shared dictionaries for when it is really absolutely necessary.
When people sat down and decided how workers are to act in browsers - Actors are what they had in mind.
This is why Web Workers don't have access to the window scope, use explicit message passing etc.
Correct me please, but from what I understand web workers are not a part of the JavaScript language. The same way AJAX isn't a part of the JavaScript language. I would consider those (AJAX/WebWorkers) more like "system calls" to the browser. And like any system call, it has privileges the application doesn't.
- The JavaScript language is specified under the ECMAScript specification.
- Web workers are indeed not a part of the ECMAScript specification which considers them "host objects".
- WebWorkers and other browser APIs (timers, ajax etc) are called the DOM API. The DOM (document object model) is how JS interacts with the web page and what capabilities it exposes. (document.getElementById isn't any more JavaScript than web workers).
Imagine your on your favourite social network that used a JS based encryption in a p2p chat to your friend. On that same page advertisers are pushing content to you. That content could be a malicious JS file which can eavesdrop on your conversation, all the while you think its encrypted.
Yes. But the existing warts do not go away (and neither will they ever, due to the need for backwards compatibility).
I think we all agree. JS has very ugly things, but it isn't going anywhere for the forseeeable future.
If we're going to use for at least a few more years, I'd applaud anyone making better tools and rejoice when I see better frameworks and easier to use libraries.
Now by the time alternatives to javascript become viable, we might have made javascript something way better than what we already have now. It could survive a long long time and with people actively making it evolve, and it could be very enjoyable. Who knows.
If you factor in all these improvements, and the fact that it runs brilliantly on the server, it's a vastly different situation than just a few years ago.
You're looking at it from a technical perspective, and from a technical perspective JS is an awful language.
It may be a turd. But it's the only sandboxed-by-default, zero-install, reasonably-fast, free, preinstalled-on-every-machine turd that we have.
JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in
Oooh, there's many more computers around you than you think ;-) Nearly every modern piece of electronics. Many don't run browsers. For instance your washing machine has an OS, but it probably doesn't run Javascript. Same goes for your car, washing machine, dishwasher, microwave, central heating system, stereo/hifi, etc. And of course the more obvious "non-PC computers" like routers, printers, scanners, TV (might actually run JS if it's "smart" and has a browser), computer monitor and who knows what else. Coffee machine. The "fancier" it is (for a rather low barrier of "fancy"), the more likely it is to have a chip in it that runs some firmware/OS something, equal in power of what people ran as desktop personal computers a few decades ago.
- Rule #1: C-like syntax
- Rule #2: Dynamic typing with optional static types
- Rule #3: Performance
- Rule #4: Tools
- Rule #5: Kitchen Sink
- Rule #6: Multi-Platform
This tool provides #2 for Javascript, the NBL.
Makes much more sense, but I am going to forgive him.
I would consider C++ to be way more verbose than Javascript. Especially with ES6 coming (and things like Flow / Typescript allowing you to use ES6 today).
Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird. When you understand how it works, it's not a problem. Use it to your advantage.
Not nice to optimize for? Javascript is fast enough for most tasks, provided you use best practices. You can even build AAA games with it nowadays, through ASM.js. I'd like to learn more about what you mean exactly when you say it's not nice to optimize for, if you have the time.
I get that Javascript has its quirks. But so do most languages. What's awesome is that JS is easy to get started with, but can be used to build complex apps (especially with things like Flow / TS). And it works everywhere. And it has an amazing ecosystem of client side and side libraries.
Rather damning with faint praise there.
> Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird.
Yes it does. In the '80s this was an open research area, but a consensus was reached in favour of lexical scoping for a reason.
> I get that Javascript has its quirks. But so do most languages.
False equivalence. Python (to pick an example I'm familiar with) has some quirks, sure, but it's a million times nicer to program in than Javascript, and it has all the other advantages you list (it's easy to get started with, suitable for complex apps, cross-platform and so on). I'm sure the same could be said for Ruby or OCaml or hundreds of other languages. If it were as easy to run these in the browser, I don't think we'd see anyone choosing Javascript - it really is a worse language than so many alternatives.
(I mean, by the standards of a single-application scripting language that was written in three days, Javascript is very good - we wouldn't expect such a language to be the equal of a carefully designed general-purpose programming language)
I'm interested in who is the driving force behind this open source change in Facebook, I don't recall facebook in behaving these way 4 years ago.
Can anyone find anything on a policy change that happened? They really turned around.
From my point of view, most of what has changed is resources and the immediacy of our survival-level concerns. Four years ago Google had declared nuclear war on us, we had far fewer users, we were not profitable, there were constant fires to put out with basic production operations stuff we've gotten better at, and we were enormously more under-staffed. I was working on HHVM already, but it was in a million little pieces spread across Drew's, Jason's, and my desks. The tools we're open sourcing over the last two years mostly did not yet exist, and if they existed, it was in some primordial form. We also have gotten much, much better imho at being good stewards of our open source projects; HHVM's predecessor system, the HipHop compiler, was also open source, but we people were spread way too thin to be able to respond to bug reports, pull requests, get FB's latest code into public hands, build binary packages for popular distros, etc. on a timely basis. Huge props are due to all of the technical people on our open source teams.
It would be awesome if you blogged about this. It would be interesting to read _how_ you got better at being good stewards of your open source projects and what made you open source these. I think it's a challenge a lot of people face.
I don't think there's been any policy changes. I think the policy has always been that we're open to open sourcing stuff, so long as it is useful to others (ie, not just a code drop that nobody can use) and someone signs up for the work and there isn't something important that's being dropped in the process.
The difference I think is people, energy, and momentum.
We've been able to find people (many already at the company) genuinely interested in some of the less glamorous parts of building a scalable program to open source things - things like sync processes and pull request management and UIs for ACLs and CLAs and so forth.
We've had people who, often due to the availability of these tools, have developed an internal energy to want to put in the extra effort to make their project ready to be open sourced (like making sure all dependencies are available already, or scoping out or stubbing out things that are Facebook-specific (our asset management flow, for example) while still keeping the software useful, and so forth.
The momentum has also made the idea of open sourcing code more top-of-mind to people, which helps to get people to rewrite their changes to accommodate a nascent open sourcing effort on a piece of code, or to get more discretionary time to investigate or work on making something open source. Or even just moral support from your team and colleagues.
And I think these efforts will pay off in spades for Facebook, in terms of attracting top talent and in terms of the expertise that results from having the some of the best dev tools available being developed in-house.
My guess is that Facebook was just much smaller 4 years ago, over that period its staff grew very quickly. And even today it has an order of magnitude less employees than say Google, Apple, Microsoft, etc.
Larger, more established companies have more opportunity to open source things on this scale.
Not to say that Google's OSS hasn't done much of the same, but AFAIK many of their projects fail on at least a couple of these points.
"...on the web language of the past, which we are unfortunately stuck with for the foreseeable future: JavaScript" might have been a better summation of the current (rather dismal) state of affairs with regard to web scripting.