In today's fast-paced development environment, the ability to hit the ground running is key, and I worry that fragmentation will introduce unnecessary friction in the industry.
Because it's the straw-man.
ummmm, can someone elaborate? I don't understand that statement.
Well, no, you're just writing the locks yourself in an ad-hoc way. Every time you have a callback calling another callback, you have a lock and all the race condition/deadlock issues associated with that. Of course, writing an application that doesn't have complicated synchronization requirements (streaming fileserver) can often require less boilerplate in an evented system. However, you run into a catch-22 here: by definition it's an application with fewer synchronization requirements, so you'd have to use fewer complicated locks in a 'heavy thread' implementation as well :).
Ultimately it's an engineering tradeoff problem, and you have to weigh lightweight node-style cooperative multitasking with the ability of a traditional thread system to better handle highly complicated scenarios.
Or you can be Russ Cox and argue that this is a false dichotomy and that we should all be using CSP. I'm in that camp.
Andrew Birrell: threads.
John Ousterhout: events.
John DeTreville: no.
Rob Pike: yes.
So how do you handle concurrency without race conditions without using isolated processes or pure message passing? Ok so you don't have thread locks, big deal, but you still have shared data structured that could be updated in a non-deterministic order depending on which file descriptor gets fired first by epoll (or whatever select thingy is being used lately).
actually, i think one of the major flaws in the current programming job market is overrating the ability to hit the ground running. that leads to a dangerous level of short-term optimisation, where, say, you'd choose an employee who has experience with your current stack over someone with a better track record but requiring a month or so to learn their way around the specific languages and ecosystems involved.
It is always a bad idea to tie yourself too strongly to any single language.
Having said that, I'm pretty much tied to Java since 2000 and haven't seen anything wrong... yet. In fact, I'm determined to get better in Java everyday (memory model, JVM, concurrency, better design, etc).
Side note: I'm also learning pure "modern" JS just because there's no choice on the client-side.
GWT development is a bit painful to setup and to work day-to-day.
It's nice to have the similar Java structure and to be able to write unit-tests to test the app via MVP patterns but I'm still not sure it's a big win for me going forward. Especially when the founding members have left the team.
The fact that after all this time and efforts, ES6 won't be released for another year plus, speaks volumes about the "design by committee" thing.
First, Firefox and Chrome (under a flag, to be removed) already ship great pieces of ES6. JSC (Safari) and IE prototypes coming too. This is necessary to test interop and design soundness.
Second, we don't do "Design by Committee", we use the "Champions" model where 1 or 2 people design a proposal and a larger number beat it into consensus shape without "redesign".
Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.
Compilers on top are great, and many. Good to see MS do one that tries to build on ES6.
>Nope, spec finalization follows shipping.
Still, shipping ES6 is also scaled back at this time, and it requires special flags and hoops to be enabled.
This means actual mainstream use (the way we know use HTML5, IE7 be damned) will be possible 2-3 years in the future at the minimum, which would be like 6-7 years from the beginning of the whole process.
This is W3C-level waiting times, especially considering that ES now is essentially the same it was in 1999, with minimal changes to the language or the standard libs.
>Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.
I would wish for a "one guy sets them all straight, it's his way or the highway" benevolent dictator model, but I understand that while it works for Ruby or Scala or whatever, it doesn't work in JS case where you _have_ to have 4 different implementation by 4 browser vendors to have it adopted.
I think what those vendors need is something to force their hand, but don't know what that could be.
You can't get an interoperable spec of a new edition of a language the size of JS in less than three years, for any such language. Not for Dart (which is still changing and by Google's own plans nowhere near ready to standardize) or TypeScript (also new, and tracking ES6). Java, C#, Python, Ruby, etc. were built to today's state over years or decades.
Bite-sized specs are much better. Small libraries on github and universal edge-caching, even better. Could we have bite-sized specs for JS?
As I speculated at Strange Loop last week, with a few final gaps in the language filled (Object.observe, slated for ES7, weak refs and event loops, and definitely macros! see http://sweetjs.org/) by a future JS standard, we will be "all but done".
Working away at this goal,
It's also compounded because the majority of front-end developers write their code procedurally for each application component, which creates a terrible nest of repetitive and error-prone code.
They feel the pain, don't know how to solve it, so switch to a different syntax, blaming that as the root cause of the problem.
But feeling enough pain to viscerally HATE a language, as many front-end developers do, is not something that can simply come from the syntax of the language and the fact that the equality operator does type conversion and whatever small list of gripes users have. Most other languages (including CoffeeScript!) have a similarly-sized set of flaws and aren't nearly as derided.
Overall, cross browser js isn't really that difficult anymore and I rarely see people complaining about that. Of course, I've been part of the AltJS community for a while, and the people I follow closely are not front end developers.
A few of the weakest parts:
- for (var x in y) when used for array iteration or even dict iteration; hasOwnProperty? Really?
- x[obj] = y; seriously, did i really want '[Object object]' as my key?
- the choice of function level scope over block level scope
... local variables right here ...
Lisp has block scope.
Can you write Lisp like this?
var x = 2;
Compiles and runs with f(undefined)
I don't know of any JS developers that hate JS. I know a lot that hate some browser implementations of JS though.
Ah, the "only the libraries make the language tolerable" argument.
My experience has pretty much been that most of the devs who thinks the libraries are hiding problems with the language are confused on one or both of the following points:
2) the idea that a language is terrible if it doesn't have a specific class-based OO model
Hard to say in your case, though, given that you didn't mention any specific problems or solutions presented by specific libraries.
I use date.js or moment.js whenever I have to deal with times/dates in JS because the built in date support is pretty bad.