Hacker News Reader

Comment by edem | Hacker News Reader

I simply don't understand how can someone like javascript (or anything derived from it) when there are so many much better languages around. Can someone state some advantages for web development for example compared to ruby, python, or clojure? All I see is a slow tangled mess of dependencies and broken libraries with a package manager which lets you change already released modules and a language which is even more poorly designed than PHP. Is it just because of node.js and the promise that you can use javascript from database to frontend?

View on HN

I am a Python fan and I'm not a huge fan of JavaScript, but I do understand why many people love using JavaScript/TypeScript:

1. It's available in the Browser which opens a lot of possibilities. Yes, there are transpilers for other languages but it's not the same.

2. On the server side is really fast. In fact JavaScript is one of the fastest dynamic languages out there. Much better performance than Python (even with PyPy), Ruby or Perl.

3. With TypeScript you get amazing IDE support. Which is something that you just don't have with Ruby, Python or Perl. Yes, I'm aware of PyCharm, but it's not up to the things that you can do with VS and TypeScript.

4. I know the language has some design mistakes, especially around operators and other few things. But in the end the language is small enough and simple enough that it's easy to learn. And it's also easy to learn how to avoid the pitfalls of the language as well. So in the end that's not much of a problem. Besides that, even when the language is simple, it's still quite powerful because of its dynamicity, closures and prototype oriented programming. In the end you can be as concise as you are with Ruby, Python or Perl.

Best thing about JavaScript is the speed of development. Once you master it, all other languages & ecosystems feel verbose, archaic.

Modern JS (ES2015+) combined with a code style (Standard, Airbnb) is beautiful, sometimes more so than Python.

Bad modules isn't a problem inherent to JS. NPM has its faults, but the JS community is the largest, and the fastest moving of all. Everything you need already exists, and it's probably actively maintained, if not accessible for you to submit a PR.

PHP? Lol, no. JS > PHP.

I think the same argument could be applied to PHP though. If you've never used or seen Laravel, it's quite nice: https://laravel.com

If you need concurrency, Facebook's Hack has support for async/await and some other nice things.

I'm not saying this is necessary better, just that PHP has a bad rep that it may not deserve at this point (which is pretty similar to JS imo)

You mean the so-called "Standard" code style? Not many people use it. Why even list it...and first? Airbnb style is the most popular one by far.

This bears repeating whenever the so-called "Standard" js style is mentioned, lest any readers think that it's actually a standard that people use. It's not. Every time it's been introduced on HN, it's been roundly criticized for the name and the lack of semi-colons.

I'm not here to argue about semi-colons. But again, for anybody who missed it - the so-called "Standard" js style is NOT a standard, it's not even a de-facto standard and it's not even popular at all. Don't use it.

Standard is a very nice style and makes for very readable code, especially for those with more of a functional background. (Standard makes JS [and TS too with tslint-config-standard] feel a lot more like the OCaml relative that it is.)

Just because you don't like the name, don't think it is "popular", doesn't mean that no one is using it or likes it. (I like it a lot, personally.)

I know for a fact that it's not popular.

I don't agree with this. For example I can get things done using Clojure incredibly fast. The development speed with it is simply unparalleled. And since they introduced clojure.spec you get the best of both worlds (static, typed / dynamic). Bad modules is not inherent to JS but it __is__ a problem currently. Compare it to Maven Central for example: scandals like the one happened with kik is simply impossible. What I see is that there are a lot of libraries in JS which are made obsolete within a few weeks when something new and shiny comes out but there is no depth to it. For example I had to develop a topological sorting algorithm for a frontend project and I did not want to implement my own Graph library so I picked one which had the most Stars. Needless to say that the asymptotic complexities of its operations were not documented and in the end it turned out, that an operation which was supposed to have an O(1) complexity had O(n) and the whole application blew up. The point is that most libraries are sloppy and you end up reimplementing something when all your options fail. I'm used to the Collections framework in java which is well documented and performs admirably. Another problem is that javascript carries a lot of baggage which is a result of the poor design of the language itself and you end up using a lot of transpilers which extremely slows down the compile process. An application reload for example in Clojure (if you use Mount) takes less than a second.

"Best thing about JavaScript is the speed of development. Once you master it, all other languages & ecosystems feel verbose, archaic."

That is pure opinion.

I'm a little skeptical that you have mastery of "all other languages" such as to compare.

This might be true for C++ or Java but definitely not for any LISP dialect. Have you heard of the blub paradox?

I used Clojure for three years before realizing that all of the dynamically typed languages you listed still have the same hard problems: making large code changes and reasoning about existing code. I also realized that in the real world, technical superiority is overrated, and the difference between these languages is overestimated.

Javascript is ubiquitous, runs in the browser + server, everyone I meet in the wild has to know it, and it has static typing options. It's not easy to shove those aspects under the rug to justify another language. It takes something else, mostly depending on just who I'm working with and then on what we're building.

For me, it's first class function support. Of course, there are other "real functional languages" like Scala, Haskel or whatever, but they very uncommon. JS is the only commonly (Clojure is very uncommon) used language with real first class functions and not some silly hack like Ruby/Python lamdas, procs, or blocks.

To be fair, it seems that Java 8 has first class functions. I can't say much about it since I didn't get a chance to play with it yet.

How are they a hack in Python?

lambda bodies can only be a single expression

There is more to functional programing in python than lambda functions. Normal functions can be created and passed around.

Sure, but I think that is the point. You can do that, but its not as convenient and becomes harder to read. And besides, those are free functions you speak of, not closures. To emulate multi-line closures becomes even more obtuse.

I find it more readable than lambda function syntax personally. And still way nicer than messing around in JavaScript.

Sorry, I edited my comment and you may have missed it. How would you emulate multi-line closures in Python? A free function which you can pass to a higher order function is not a closure. I think you would need to create a functor, and that becomes even more verbose.

What do you mean by closure in this case?

Closures are functions that can capture values/references visible in the scope where the function is defined/instantiated. They are basically a short hand way of creating function objects, functions which have data members.

I believe all functions are object in python, so you can add attributes to them, but you'd be better of creating a class with a __call__ method. Relevant scope can be captured in the class __init__.

Classes themselves can hold multiple functions/methods, and if you want a function that carries state, maybe a generator would be useful?

I think this is the point. You can do all these things, but they are all extra hoops you have to jump through when all you want/need is an anonymous on-the-spot closure.

I'll grant you that a class isn't an anonymous function, arguably it's the same with lambdas that aren't as powerful as proper function defs.

But I'm not sure this is a problem. In fact, in some ways it may be advantageous e.g. static analysis.

I'd need a use-case for the anonymous closure, but a generator is a basic concept in python, so I son't think it's any trickier than a js function.

I know how in js there is a degree of 'binding' scope and hiding functionality in closures - I think in python (for better or worse) things would by convention be implemented differently.

As an aside, would you say js scope/closure approach is a bit similar to the approach in R?

"lambdas that aren't as powerful as proper function defs" I don't really follow this. I think we should use the right tool for the job. I don't need something that is "more powerful" but comes with extra verbosity and requires me to jump around the source code if I'm not using the extra power.

"In fact, in some ways it may be advantageous e.g. static analysis." Curious why static analysis can't handle closures? Also, I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle. There may be cases where you are tied to a certain language and analyzer, but in the general case, I don't follow this argument.

"I'd need a use-case for the anonymous closure." I don't want to delve too much into the usefulness of closures, but they definitely exist for a reason. They are useful as parameters to metafunctions for example, which are used extensively in certain programming styles (ie, more functional styles). Closures are basically syntactic sugar. You don't need them, but they can really make things cleaner/simpler in some cases, and are natural constructs to use in certain paradigms. They can also be used in factory functions as a more succinct way to create an object (point might be lost if you are not familiar with this style).

"I know how in js there is a degree of 'binding' scope and hiding functionality in closures." I'm not really talking about this, or JS in particular. I'm really just talking about the concept of a closure which you can find in many languages. Python already has closures (lambda), but why they can only be one expression instead of multiple lines seems somewhat arbitrary, besides maybe ease of implementing the language/problems specific to Python implementation (can you explain this one?). From a purely programming perspective, I shouldn't care about what a language has trouble with, I care about using high level and expressive constructs, I don't want to limit my expressiveness because of some technical issue in a language. Many languages implement closures efficiently.

"As an aside, would you say js scope/closure approach is a bit similar to the approach in R?" Haven't really used R, but in the languages I have used with closures, they all are basically the same. Really the wikipedia article on closures captures this.

> jump around the source code

A named function should be easier to track due to it being named, and properly defined in one place.

I believe debugging can be harder when you see some random anonymous function and have no idea where it is defined (because, I think, lambdas don't hold their definition line-nos?)

Since we're talking about multi-line functions, the added verbosity wouldn't be a lot. Additionally, you would be forced not to nest functions too much.

> why static analysis can't handle closures

Would it require tracking run-time state/modifications to the closure?

> I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle.

You could argue the same for any language with types - why should I be limited by the constraints of the type system?

Because it's easier to verify the code, and it doesn't actually limit what's possible to develop, only how it must be developed (in a more explicit style).

I see it as putting an extra burden on the developer, which makes it harder for sure, much as writing tests puts an extra burden on the developer.

> why they can only be one expression

http://www.artima.com/weblogs/viewpost.jsp?thread=147358

Seems like it is mainly a technical decision.

> I don't want to limit my expressiveness because of some technical issue in a language

I feel this is a problem with js (versus, say, Java) - faster to write, harder to analyse. What's so important about expressiveness that you wouldn't want the code easier to maintain?

> Many languages implement closures efficiently

I can't really complain about this wrt Python when I'm not sure what it would add. Even if lambdas could be multi-line, I would not want to use them for sake of their parameter-binding semantics - in fact, I consider it a python gotcha. I

Java is a different best. It is used for a lot of enterprise projects but you don't want to use it on your own hobby projects. You can't get things done in time.

This is the lambda syntax in Ruby:

Defining a lamba `foo = ->(x) { x * x }`

Calling it `foo[10]` or `foo.call(10)`

I don't see anything hacky about that at all.

Being able to reuse the code you wrote for the server in your client code and vice versa, is in my opinion not just a small feature, it can save you a lot of time and money.

I joined a company where the backend was written in PHP and the frontend in javascript. There was a ton of duplicate code, just because the backend and the frontend had been written in different languages. By using UMD modules and switching our backend from PHP to nodejs by building a custom isomorphic framework saved us a lot of time. We now don't have two development teams but just one, it's really great having everyone write (speak) the same language and makes hiring, sharing knowledge and training much more efficient.

Yeah javascript is not perfect, but I disagree that is totally bad and that you can't write good code with it.

We also use typescript because it is not just about types it does much more for us. For example allows us to write our code in ES6/ES7 (with core-js) and transpiles it on the fly (on save file) to ES5 UMD modules. Visual Studio and the nodejs tools make it easy to debug our backend code.

The code duplication is not necessarily the result of using two different languages. On the other hand you can use for example clojure for the whole stack (Clojure for backend ClojureScript for frontend).

Well, the fact that it's a VM that is installed on practically everything is really cool but beyond that I can't see why you'd prefer to use it.

Well you don't have much choice for frontend for one. Typescript offers much stronger typing than Ruby, Python, Clojure and PHP as well.

If I were to start a new project today, I would use Elm[1] for the front-end. It's a very well-designed language (reminiscent of Haskell), specifically designed with HTML and DOM manipulation in mind.

[1] http://elm-lang.org/

Is using elm really worth it? I have not yet tried elm, but I wonder if it's advantages really justify the increased costs that this choice might bring? Isn't elm a little bit too young?

I mean is the time you and your coworkers will need to learn it, the increased difficulty to hire skilled elm developers, the increased difficulty to find good training courses for new junior developers you hire, the increased difficulty to debug the code compared to js, the lack of third party libraries ... really worth it?

> the increased difficulty to debug the code compared to js

Elm has an amazing time-traveling debugging system: http://debug.elm-lang.org/ This is a cut above pretty much every other front-end JS framework, and languages that transpile to JS.

> the lack of third party libraries

It has JavaScript interop that's based around message-passing. The JS library is treated sort of like a service, and thus the Elm code is kept isolated from it: https://guide.elm-lang.org/interop/javascript.html

> the increased difficulty to find good training courses for new junior developers you hire

The official docs are pretty good. A good programmer shouldn't have a trouble picking it up. The architectural benefits of using Elm (that lead to a high-quality, almost zero bugs website) is IMO worth it.

IMO actually decreases costs because of the amount of errors the type system catches and the ease of refactoring.

Elm also guarentees to NOT produce ANY runtime errors, that's quite a guarantee.

Sounds interesting and I'd love to code in a real functional language instead of functional style in an imperative language. I haven't looked into Elm but isn't this going against the grain too much? TypeScript seems to be gaining traction such as with Angular 2. I mean I could code in OCaml with a transpiler to JavaScript if I wanted to but it probably isn't worth the friction.

Surely by using Elm you may improve the quality of your program, but you restrict your staffing choices down to the <1% of frontenders who either know it already, or are capable of quickly picking up a Haskell-esque language.

Either that or you commit your client to huge up-front training costs.

Or how about the scenario that goes like: "The contractor who wrote our web app in Elm left last month, but we need some bug fixes or complex feature adding. Can someone fix it? Anybody? No?"

How do you sell that to a client?

For me frontend == native, so I have plenty of choices.

Stronger typing than clojure? You gotta check out clojure.spec which is built into the language itself.

Ah, I'm not that familiar with Clojure. Is that commonly used? Are there any good examples of complex properties you can capture with its type system?

See for yourself, Stuart Halloway (clojure committer) can explain it much better than me: https://www.youtube.com/watch?v=VNTQ-M_uSo8

You have actually. For example ClojureScript compiles to JS.

When you compare pip to npm, it's a no brainer, npm wins that battle. Pip is getting better but so is npm.

Js code looks a lot like python to me now as well, especially when referencing generators.

The speed of development is it's strongest advantage. However I do think that from an architecture point of view something like golang could be considered more sound.

>> All I see is a slow tangled mess of dependencies and broken libraries with a package manager which lets you change already released modules...

Ah yes, let's blame the tool for the bad things people do with the tool.

It does not make a difference whether the language is bad or the tool is bad because if in this case npm is a de facto tool for the ecosystem you will have to use it. Same with java: it is not the language which is problematic but the "enterprise" projects which need all kinds of factories/builders/etc which make development incredibly slow.

Oh, I'm sorry, I didn't get the memo that says if you work in Javascript you have to use npm. Did that become mandatory in ES2015 or ES2016?

But again, you are blaming the tool for the bad things people do with the tool.

Are you using npm? How many js developers use it around you? 90%? 95%? As I said in my previous comment it does not make difference in the end whether the tool is bad or the language. If I have to use that tool to leverage the good parts of the ecosystem (eg. use all the libraries in nmp) I can either choose not to use it and lose the the advantages of it or choose to use it and have a crap software which is in the hands of a private company and who can take over my packages (even which I have published years ago) without question.

Yes, I use npm every day. So what? You are still blaming the tool for the bad things people are doing with it.

As for the taking over packages problem, that's an easy thing to prevent. You can use the tools from npm without allowing that private company from messing you up. Download and use them locally.

Reply on news.ycombinator.com