Comment by Elrac | Hacker News Reader

Comment by Elrac | Hacker News Reader

Parent Full thread

Elliott certainly knows a lot about programming JavaScript, but reading his piece I have no way of knowing whether he knows a lot about programming in general, or architecture.

He tells us, again and again, that it's best to avoid trying to emulate inheritance in JavaScript, because that often goes horribly wrong - in JavaScript. I'm not sure it's valid to extrapolate his experience to outside JS. I get the impression he's teaching us how to avoid problems that we wouldn't have (or less so) if we weren't saddled with JS.

His enthusiasm for JS, meanwhile, seems a little misplaced. A language riddled with many horrible gotchas that inspired Mr. Crockford to write a book on how to avoid them? Why should we need to tiptoe around the fact that "this" means different things in different contexts? The "prototypal functions that happen to contain data" idiom is refreshingly different and interesting, but does it really offer advantages not found in "conventional" OOP or FP?

JS commands a huge following. But as Elliott hints at the beginning, its popularity is not a matter of choice. Netscape saddled us with a legacy where the API of every browser is necessarily JS. JS is the best language for programming browsers simply because it's the only one. That it's not a universal favorite is evidenced by the many projects that offer a "cross compile to JS" option. The users of those products would rather code in a different language.

All that said, a disclaimer: Though I've read _The Good Parts_ and other JS books, I avoid JS, I barely know JS, I have next to no experience with it and I suck at programming in it. So the foregoing is an opinion not backed by a wealth of knowledge and experience. I submit it as a kernel for discussion, hopefully by more knowledgeable people.

I'll throw my opinion that this is an excellent article and the author also says some incredibly important things about the direction some people are trying to take JavaScript (towards "OOP") mostly because they seem like they don't want to understand how this versatile language is constructed and would rather swim against the tide trying to implement familiar paradigms on-top of a solid technology.

I've been focussed primarily on JavaScript development for the past 6 years (before that I was full-stack in previous positions) with some of my time spent helping out with the other tiers. This article echoes all my thoughts and experiences developing large, complicated and slick web apps using pretty much every JavaScript framework under the sun.

As others have pointed out, you can run your arbitrary code from another language with a polyfill so no one is "stuck" with JavaScript. At this point, the ubiquity of JavaScript is not something anyone should be be-moaning as it is not a negative, only a plus.

It's a great language and I would urge you to learn more through direct experience (functionally and not OOP-style). It's an easily accessible language to teach aspiring programmers: we just need to teach them the functional way and forget the ludicrousness of deep inheritance applied via prototypical inheritance.

JS, while flawed, has some beauty to it that you don't really find in most more established languages.

It doesn't require memorizing a huge number of language features in order to write the majority of your code. You don't need to know the nuances of equality by reference upfront, or details about OOP. You have your operators and basic control flow, and you can go to town with them & be quickly rewarded. As you get into more complex needs, the language doesn't get in your way for the most part. It still offers a mechanism of OOP via prototypical inheritance, and functions are first class citizens so you can pass them around and meet your functional programming needs.

JS is not without its flaws - however, it is the easiest major language to get people productive in without a programming background, and slowly bring them along at their own pace in order to build a solid foundation.

it's depressingly good at deployment though isn't it. there's nothing easier to "port". it's the write once run anywhere that's been promised so many times. i just don't feel like writing anything in it!

i don't think that this is a great article because there's a lot of bloat around the content to wade through and filter.

> it's the write once run anywhere that's been promised so many times.

It has yet to even obtain Java-level "write once, debug everywhere". Most of the people talking about "isomorphic JS" and "JS is everywhere" use, and expect, a single javascript VM implementation (V8).

i was under the impression that jQuery had taken care of that, perhaps i was mistaken. certainly a url is quicker to deploy than a jar.

with the exception of jQuery: i appreciate your point, even within the same browser, different js engine versions have wildly different behaviour.

People are not forced to use JS. You can make any language available in a script block and have it interpreted using a polyfill. If JS sucked as bad as some people think, this would have taken off - it hasn't.

You can't solve the problems of using OOP in JS. JS is functional at its core. OOP style class inheritance is completely inappropriate, and bolting it onto JS was bad overall for the language as wandering off the functional style creates some confusion and now the language inherits the problems of class inheritance.

Separation and extensibility are the great things to get. Separation you get in function scopes. Extensibility isn't obvious, so they bolted on OOP. It can be achieved but you have to go deeper into the functional world and people started demonstrating class inheritance as the answer. Was unfortunate.

> You can make any language available in a script block and have it interpreted using a polyfill. If JS sucked as bad as some people think, this would have taken off - it hasn't.

That's not trivial.

People are cross compiling to javascript as part of a build process though, so you're wrong that it hasn't taken off. Coffescript, Typescript, ClojureScript, Elm, etc.

https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Taken off = more than very few than use Coffescript et al.

Clojure itself barely registers in language popularity indexes -- much less Clojurescript.

> I barely know JS

That much is clear. Your comment is essentially based on hearsay and is far from accurate.

You really should learn Javascript, and listen to the original article.

The "two pillars" of prototypical inheritance and lambdas with closures are actually two extremely powerful foundations that are rarely found together in any language, let alone a language with such ubiquity.

It is actually a much better language than it gets credit for. If you don't like the prototypical inheritance; you may safely ignore it and treat JS as a first-class functional language. If you don't like first-class functions with closures, then treat JS as a beautiful object-oriented language. It is so flexible it's almost absurd.

Are there gotchas? Sure, perhaps more than would be ideal, and in order to have both of these pillars in the same language, some odd stuff does pop up. But if you actually use it for a while, you'll come to realize the balance is in its favor.

Reply on news.ycombinator.com