Hacker News Reader

Comment by tzaman | Hacker News Reader

One language to rule them all. There is no way to handle complex UIs in the browser without JavaScript. So while you absolutely need JS developers, why not make the API/backned in the same language so that you can hire additional developers that know the same language your existing employees already do. From an employer's perspective, it's easier to manage and (re-)allocate resources if need be.

JavaScript is becoming the web darling (or it already is?), whether we like it or not. And with some nice syntactic improvements ES6 brings, I don't mind.

View on HN

What I'm missing at our current place is being able to share business logic code between the client and server. Even simple things like validations that are run in both environments would be nice to not have to rewrite and maintain in two languages.

Meteor excels at this.

> One language to rule them all. > JavaScript is becoming the web darling (or it already is?)

I wonder, will it be still as popular if WebAssembly let us use any programming language on the client? I mean post MVP WebAssembly with support of GC, DOM, and so forth.

I suspect the Javascript-or-death crowd are a (vocal) minority of web developers. Most will jump at the chance to use whatever language they please in the browser.

>There is no way to handle complex UIs in the browser without JavaScript

Dart, ClojureScript, TS (technically JS superset but still a considerable improvement) are just the ones I've used.

And I'd rather use both of them on server (Dart/Clojure) than JS.

There are other languages as well.

ES6 is a pain in the ass - no browser supports it and using transpilers + polyfills and the JS build/package tools to set that up is a PITA that only grows as you add dependencies and it bloats your code size to be comparable or larger than the compile-to-JS languages without making the language significantly better.

do you honestly believe that ES6 is not an improvement for javascript? if so, why?

It's an improvement - but at this point ES6 is just another compile-to-JS language that needs to ship it's own standard library - except it's worse than all of the mentioned ones (it has no type checking, standard library is still meh, semantics are still good old JS semantics).

What do you mean it's a compile to js language? I use ES6 with no transpilers.

Same here; I guess it really depends on who your target market is. So far, all the ES6 I've written works just fine in Chrome, Firefox, Safari, Opera, and Edge. The only browser that breaks everything is Internet Explorer, but it seems like general consensus these days is that IE is only used in enterprise applications where you're locked into it.

Where are all the people who like dynamic languages? Do they just hide while other people duke it out over this?

It just seems like everybody except me hates dynamism sometimes.

I think ES6 is just in its in-between phase of adoption. The mainstream hasn't fully adopted it yet. As for the rest...

The Coffeescript converts have moved on from the 'one true language' now that ES6 cherry-picked most of the good parts and people started realizing that CS source maps are buggy/inconsistent.

Standards are for 'plebs' so they've moved on to the new shiney. By new shiney, I mean mimicing FP in Javascript and looking down on people who can't ELI5 monads and functors. Despite not being able to ELI5 monads and functors.

Typescript, is really geared toward OOP devs who live in an IDE and compulsively twitch an invisible set of CTRL-SPACE keys when they get nervous.

It's a well-known fact that Google is a OOP- heavy Java/C++ shop who have been developing algos in Java/C++ since their last CS course where they developed algos using Java/C++.

It's within their best interest to get all of there desktop devs to convert to writing desktop apps on the web before all that penis pills/local singles ad money runs out.

It's only a matter of time before we see the first JS AbstractFactoryFactoryServiceProvider class in the wild. Angular2 has made considerable progress on this front so far.

/satire

Honestly, I really enjoy ES6. The JS dev communities favorite past time is ragging on how ridiculously bad JS is. ES6 isn't bad so it's not worth talking about.

The new features introduced in ES6 are pretty conservative. They consist of good concepts poached directly from popular superset languages or sensible additions that fit in nicely with the usual JS style.

The really interesting additions are still in the specification phase. Additions, such as the new ES6 module and loader standard, decorators, native HTTP fetch, etc...

As long as new standards are being introduced, transpiling will continue to be a requirement. I think it's cool that people can create and use new supersets of JS. It beats having to listen to them whine about how 'Javascript isn't exactly like some other language that I really like to use.'

In a way it's the first democratic programming language. Instead of dictating what people should and shouldn't use, people are free to migrate around to different communities until they find one that more closely matches their worldview. Everybody follows the same baseline standard but there's a lot of legroom for differentiation.

Why axegrind over our differences when we can celebrate them and start working together.

Fair 'nuff. I probably fall into the "mimic FP" section above, as I REALLY like functional abstractions. Although I don't do much pure FP. And I don't look down on anybody who can't ELI5 monads and functors. Monads and functors are confusing.

It's all good. My comment was more of a friendly jab than a direct criticism. I agree that FP concepts are amazing.

I just don't see the utility in trying to translate pure FP concepts directly to JS. Same goes for the Typescript folks with OOP abstractions and design patterns. It's like watching a pissed off New Yorker rant about how the pizza shops in LA suck. Live a little and try a California burrito. It might change your life.

The point being, neither approach has provides measurable benefit to runtime performance/stability. They're nothing but really complicated abstractions whose sole intent is to protect devs from themselves. Why don't we build better tools to assist devs instead of inventing yet-another-feature-specific-language?

I think FP abstractions translated to JS could work as amazingly useful design patterns. Hopefully, decorators will make it a lot less painful to define higher order functions in JS.

Likewise, static type alike languages are very useful as a bridge to traditional OOP devs. I think gradual typing is a better long term approach.

...Don't you mean arrow functions? Decorators don't seem like they'd help with that.

And yeah, I don't think that monads are that useful JS. And OO is different in JS. Deal with it.

Also, if you use Strategy, Iterator, or Visitor patterns in JS by writing classes for said things, you deserve to be punched in the face really hard. Repeatedly.

Yeah, but what % of frontend developers use Dart, CS or TS? Not as big as you think. And no browser supports any of them, yet, including ES6. So you always have to transpile to vanilla JS, whether you use ES6 or ClojureScript.

Don't get me wrong I think all those experiments (if I may) are nice, but if I were to develop an interface in Dart/CS/TS today, I'd have serious problems hiring people that know one of those tomorrow.

ES6 support in modern browsers is pretty okay (see: https://kangax.github.io/compat-table/es6/).

It doesn't eliminate the need to transpile, but it looks like transpiling may not be necessary forever.

Why is transpiling ES6 any more of a PITA than transpiling Clojurescript? ES6 to ES5 is a one shell command with Babel. And TS is ES6 but with type annotations. And ignore all of the myriad of high quality plain JS modules on npm at your peril. I like Dart and ClojureScript too, but I've really enjoyed working on ES6 and ES5 projects too. I don't doubt your Dart and ClojureScript credentials, but your comment betrays ignorance of ES6 and the plain JS ecosystem.

>ES6 to ES5 is a one shell command with Babel.

You still need to include core.js to polyfil basically everything from standard library. And then you need to make sure Babel works with your framework (like Polymer or what not), and that's just the start of the interop hell that is using different JS libraries together. Rule of thumb - anything you add to your JS build system = increase in the likelihood of hair pulling when things break - and babel and core.js are two such things.

The value I get from ES6 compared to the CLJS change how much I'm willing to tolerate the PITA factor of the build system.

In dart I don't have to do any of that, just add few lines to pubspec.yaml with dependencies and transform directives and off I go. And every other library uses the same build system and the same package manager and the same standard library !

I have not found that to be the case. I run my code through gulp-babel and done. There is no runtime AFAIK, although there was one for traceur.

I have also had no real problems interopping with other big libraries. I think the biggest point of discontinuity would be the class keyword vs other class-like libraries (like coffeescript's implementation). Even that's not too bad, I'm able to extend those using es6 class syntax, I just need to be careful about calling super and setting up the constructor properly.

ES6 is pretty straightforward. You use Browserify or Webpack with Babel, and set it up to build with Gulp or Grunt.

I don't see how using Dart, TS, etc. make it any asier, and with the setup I just described, you're using Javascript top to bottom. I have an Angular project set up this way, and that allows me to run the unit tests in Node on the command line.

That's not really an argument for writing server code in javascript, since you could instead find a way of transpiling your favourite language to javascript and use it on the client and server. I give you typescript, clojurescript, haste, and GHCJS as examples.

That would depend a lot on the story for using npm modules in your favourite language and your transpiled code. If it's not possible, it's a non-starter.

And why would you write ClojureScript to use on the server, when you could just use Clojure?

I don't want to restart a flame war but after choosing NodeJS for some projects based on specific modules not available in other languages (e.g: bitcore*) I am moving away or leaving it for very specific tasks. The code we wrote more than one year ago making an SQL transaction in 8 statements with async is difficult to understand and have some implicit stuff that you need to take into account. The other problem is not having a multithreading environment (in the official release) because you may want to respond to new tasks instead of blocking the event loop. I have seen timeouts because of this. Even if the recommendation is to do simple tasks, you can't enforce this when using hundreds of third party modules.

With the up-most respect, and we've all been there, but I would submit that maybe you just didn't write your Node code very well? Written properly, async code shouldn't be hard to understand. And there are tons of ways to spin up a new process or worker to execute a task without blocking the event loop of the main app. I mean, I could go away and use my limited experience to write a small project in Python to do a specific task ... but if it turned out to have deficiencies I wouldn't blame Python, rather my limited experience. Next time you need something written in Node, why not hire a experienced Node dev? And what is this recommendation to do simple tasks? I never heard that :)

How did you manage to block the event loop? For all of JS's warts, the language makes it basically impossible to do this.

If you use a module which uses longer cryptographic operations it is possible.

OP said he was making a SQL transaction.

Using bitcore*...

If your developers only know JavaScript, they probably shouldn't be let anywhere near your backend. Any decent developer can rapidly pick up any other language.

I could not disagree more. Rapidly picking up any language is simply not possible (unless you're a genious). Because the language is not just the syntax; It's its history and evolution, design choices, documentation (or lack thereof), community (both kindness/aproachability and responsiveness), leadership, etc. It takes time. Which sometimes, as an employer, I'm not willing to invest in. Because money.

Plus you've somehow managed to state that JS developers are not decent enough.

Reply on news.ycombinator.com