The JavaScript Problem

http://www.haskell.org/haskellwiki/The_JavaScript_Problem

by falava • 12 years ago

126 171 12 years ago

jnbiche4• 12 years ago

I'm surprised that Elm is not mentioned:

http://elm-lang.org/edit/examples/Reactive/ZipCodes.elm

True, it's not Haskell, but it's clearly highly-influenced by Haskell. Besides, they mention Fay, which isn't Haskell, either.

If the Haskell wiki didn't require a log-in and registration that requires special, personal permission, I'd add it myself.

strager• 12 years ago

It's a wiki. You are free to add this information. =]

jnbiche4• 12 years ago

Did you not read my last sentence? I'm actually not free to add the information. There's a special registration process that requires human intervention.

If the Haskell Wiki didn't require me to e-mail somebody personally and ask for permission to register, I'd be much more inclined to provide a one-of edit. By the time this person gets back to me (he's probably in Europe), I'll have neither the time nor inclination to make a one-time edit to a wiki that I've only visited on a handful of occasions.

I gnome-edit wikis all the time -- at least the ones with user-friendly sign-ups. Was the Haskell Wiki so beset by viagra spammers that it had to institute a human-mediated registration process? Maybe it was, but the downside is that then people like me are less likely to register for one-off edits.

coolsunglasses3• 12 years ago

I don't recommend Elm because it's not Haskell and it's too boxed into its way of doing things. Elm is really, really far from being an acceptable substitute for Haskell. It's a gap comparable to that of what Java and Scala can do.

PureScript is a better choice for a Haskell'ish language that is generically applicable to both browser and node-backed JS.

Importantly, you can decide how you want to do FRP/callbacks/whatevers according to the needs of the libraries/app/problem you're working with.

Also, PureScript has typeclasses, higher kinded polymorphism, the works. It even has some cool stuff that Haskell does not built in!

See this post for example of why higher-kinded polymorphism is important: http://bitemyapp.com/posts/2014-04-11-aeson-and-user-created...

jnbiche4• 12 years ago

I would agree that there are probably more "Haskellish" compile-to-JS languages, but the wiki mentioned CoffeeScript and TypeScript. Surely Elm ranks above them in your book?

Besides, Fay doesn't have typeclasses, either, and it's mentioned.

I wasn't making the claim that Elm was somehow better than those options, just that I was surprised it wasn't included. I've just played around with Elm, nothing serious.

You're correct that Elm seems more like a DSL in some ways with its required FRP, and I agree that typeclasses and HKTs are nice, but if I could choose between doing my day job in Elm or staying with JavaScript, I know which I'd pick (hint: it's not JS).

WoodenChair4• 12 years ago

Pretty strange to mention TypeScript and not Dart... which solves a lot of his criticisms and is arguably more popular. I respect the functional guys a great deal but the use of Haskell for front-end dev is realistically going to only be an interesting option for those already using it for the backend. It has nothing to do with the merits of the solution and everything to do with people's comfort zones.

dfkf• 12 years ago

The page is about JS. TS is a superset of JS, and Dart is an entirely different language.

jbdeboer• 12 years ago

The article starts with the assertion "We need Javascript". Adding Dart to the mix makes that assertion less obvious.

jasonlotito• 12 years ago

It mentions Coffeescript.

mseepgood• 12 years ago

All other languages listed on that page are entirely different languages as well.

dpratt• 12 years ago

I'm going to chime in to the chorus of "Why wasn't X mentioned" and throw out Scala.js.

It would seem that Scala solves quite a few of the article's complaints about Javascript, and in a manner that is accessible and usable for the masses. I love Haskell as much as the next guy, but I'd rather use Scala if i need to get stuff done.

girvo2• 12 years ago

I've been trying to convince my workmates to try something other than pure JS (with Angular), but am not having much luck. TypeScript seems to have the most buy-in, but most of the guys in the office aren't convinced of the benefits of a proper type system, the just see it as more work for them for little upside. Any ideas?

WoodenChair4• 12 years ago

What kind of office are you in? If it's filled with a lot of front-end JavaScript "ninjas" I doubt you're going to make much headway. I hate to be pejorative, but I do mean the ninja part pejoratively.

My best advice would be to try to start by convincing the guys with the most dev experience in other languages/serious dev experience/(dare I be controversial and say )guys with the most formal CS education first.

girvo2• 12 years ago

Mostly back end guys who have to do front end, and the genuine front end guys are indeed "ninjas" (though, I must say they are very good at wrangling JS and debugging the problems we inevitably run into). My boss is convinced at least, and I recently just convinced the team to move to proper testing + CI system (which the boss had wanted to do for 12 months but never had enough buy In from the team, so he was pretty stoked when I brought it up), so perhaps it'll just be a waiting game.

I'm tempted to reimplement a part of the system I'm currently working on in TypeScript to demonstrate it. I do worry that I'll come across as trying to show the team up though, as I'm still pretty new here :(

md224• 12 years ago

Is it that they don't properly understand the benefits of switching on their productivity, or that they just don't think the productivity gain will be large enough to justify the switch?

If it's the former, then yeah, a logical explanation might help, but the latter seems a bit more subjective, and it's possible they just see their current workflow as completely adequate. Quantifying productivity gains is tricky, and the "if it ain't broke, don't fix it" philosophy has some merit.

rdtsc2• 12 years ago

It is hard, if you look at the article, it even says "but we are stuck with it". With Angular JS there is just not that much JS to make it a big issue. So I am not sure if that is the best framework to switch to a new language (they'd have to re-map all the tutorial and documentation and everything they learned to this new language).

Coffeescript was a very popular on HN some year or two back. Then there was kind of a backlash against it and I haven't heard much since.

Now I am looking at Dart, I think that one of the few viable alternatives coming up. They are moving to make it a standard. There is already a performant VM for it (Dartium) that can run in Chrome. It compile to JS and what what you want but it has Google behind it. So it has some chance. Dart+Angular integration is going very well. They even added IDE completion for it. So if I gave you any advice I would say look that.

camus24• 12 years ago

Typescript is hard.

It's module system is a mistake(it should be module system agnostic,not AMD or CommonJS),and very confusing.

The biggest problem is javascript is so dynamic you cant create type definitions for every library outthere and expect the typesystem to work.

Typescript is good if you are porting something from AS3/C#/Java to javascript,or if You want to model a complex domain,without touching the DOM api(or node api).

It sucks as soon as you try to use jQuery with it.You end up with any everywhere which defeats the purpose of that language.

In my opinion,if you need to pick a js alternative,choose Traceur.

ehsanu1• 12 years ago

Umm, no experience with typescript here, but can't you use the type annotations from the DefinitelyTyped project [1] to avoid everything becoming `any`? There are open source type annotations for all major (and many minor) libraries, including jquery [2].

[1] https://github.com/borisyankov/DefinitelyTyped

[2] https://github.com/borisyankov/DefinitelyTyped/tree/master/j...

pingec• 12 years ago

I could not agree less with your post. I ported a 12k loc JS project to TS and it usese JQuery heaviliy. The result was that the static type system could point out 6 bugs from my original code that unit tests did not find and now I have statement completion and powerful refactoring tools for everything as well. It plays really nice with JQuery if you have the right type declarations and I am more productive now with all the code intellisense I get from the IDE.

Also the module system is module system agnostic and it can compile either to commonjs or amd, it depends on a compiler switch. I am using mostly requirejs and it works well.

owenversteeg4• 12 years ago

I take issue with the paragraph about how Javascript sucks:

* Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) and I don't see that as a problem.

* Being an entirely interpreted language, JS cannot have static type checking. This has not been an issue in my experience.

* I think the syntax argument is laughably ridiculous. Programming languages that live in glass houses shouldn't throw stones. Just today, I've seen three links to guides "to learn basic Haskell syntax", two of which contradicted each other.

* I agree with their statement on `this` behavior. This (pardon my pun) is one of the places where JS's well-intentioned DOM-manipulation features cause problems with it as a language.

nilkn• 12 years ago

untyped means no type declarations, not that it has no types

I found this to be a very bizarre statement, given the existence of dynamic typing. For anyone else confused, this is the best discussion I could find of the issue:

http://stackoverflow.com/questions/9154388/does-untyped-also...

owenversteeg4• 12 years ago

There seem to be a few different viewpoints on the matter. This is the one I go with (as well as Brendan Eich and other high-profile JS people.)

seanmcdirmid• 12 years ago

The programmer theorists view of what a "type" is will always differ from a programmer's view. If I'm talking to a bunch of theorists, I know that types are absolutely static entities, and everything else in the dynamic world are actually tags. If I'm talking to programmers and am careful to make this distinction, they will find me to be overall pedantic and verbose.

So unless one is having a discussion with someone like Bob Harper, dynamic typing absolutely makes sense and is not a misnomer.

Untyped, however, is a bag of worms that you can't really get out of. To some it means no type declarations, in which case Haskell is untyped to some extent with its excellent support for type inference. To others, untyped means the complete absence of types and type checking (static or dynamic)...like doing something completely unchecked at run time with a void* in C. The views are diverse among programmers, let alone theorists! So I just avoid this term in any case.

dubcanada• 12 years ago

* Being an entirely interpreted language, JS cannot have static type checking. This has not been an issue in my experience.

This doesn't mean it isn't an issue, just you haven't encountered a situation where it is.

And you've never seen three guides to "learn basic Javascript syntax" which contradict each other?

You can argue it both ways, as far as I am concerned. Javascript like any other language has issues, what exactly those issues are... depends greatly on what you use Javascript for.

owenversteeg4• 12 years ago

This doesn't mean it isn't an issue, just you haven't encountered a situation where it is.

You're right, but it seems to be fairly rare. I've only once ever seen static type checking help find bugs in rarely-used code paths, and that was a single occurrence five years ago.

And you've never seen three guides to "learn basic Javascript syntax" which contradict each other?

No, I haven't. The only things I can think of off the top of my head that a JS newbie would find contradictory are semicolons and declaring arrays with [], both of which are used by the vast majority. I've only seen one codebase ever that used new Array(), and only a handful that didn't use semicolons unless necessary.

You can argue it both ways, as far as I am concerned. Javascript like any other language has issues, what exactly those issues are... depends greatly on what you use Javascript for.

Good point. Claiming Javascript is issue-free is as ridiculous as claiming that (to quote this guide) "Javascript sucks".

hippich2• 12 years ago

Could you clarify on `this`? I find how it works very obvious and natural to me, therefore not quite sure why everyone consider it broken and not 'different'?

hamburglar2• 12 years ago

I assume it's referring to the fact that 'this' changes in a given piece of code depending on how it's called, whereas other vars are lexically scoped, so you are often forced to work around the issue by making your own lexically-scoped equivalent, aka the old "var self = this;" trope.

masswerk6• 12 years ago

The problem appears to be, some tend to get confused, who is the caller and who is the callee. For this, please just consider that the DOM-interface is not part of the language, but just -- as the name suggests -- an interface to a separate environment. From the point of view of the DOM, the element is the callee, which applies itself to a callback function (the event-handler). Makes quite some sense.

In case you've issues with this, you may just use `Object.handleEvent()`, and the this-object will be your object (or function). Why is everyone complaining about this behavior, but no one is using the built-in feature that would be the perfect solution to the problem?

wvenable• 12 years ago

Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types)

I've never really heard the term untyped before -- I guess I'm old school and still call that dynamic typed. But JavaScript is also weakly typed. It will automatically convert strings to numbers, etc. Some languages, like Python, are dynamically typed but also strongly typed: No type declarations but no automatic conversions.

_xczx• 12 years ago

It's been popping up lately. It's meant as a smear on dynamically typed languages, because dynamic has a positive connotation and untyped is decidedly negative. Pretty similar in intention to uni-typed.

http://stackoverflow.com/questions/23282683/is-clojure-uni-t...

Edit: Sorry, learned something new just now. I'm very, very wrong.

Untyped is where operations are valid on everything because it's all a sequence of bits.

Dynamic is completely different and refers to when the type is discovered.

Sorry. However, Javascript is definitely dynamically typed.

pags• 12 years ago

This is well put, but I can't offer the same concession about "this" ... what exactly is the problem? It provides access to the state of the object on which you are working, if utilizing OO paradigms within JavaScript. Sure "this" values when executing pure functions in some runtimes make little sense but if you understand what "this" means with respect to OO, you wouldn't be trying to access it in that situation in the first place.

coolsunglasses3• 12 years ago

Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) and I don't see that as a problem.

That's not what any of that means.

"No type declarations" only means just that. Haskell has no obligatory type declarations due to global type inference and nobody is calling Haskell untyped.

Untyped means untyped. None of the APIs or code are built around types, structurally or by name. It's just a one big union type of possible JavaScript values all over the place even if that's not what you meant when you wrote the function.

Being interpreted has nothing to do with type-checking. Haskell's REPL is an interpreter. Using a library (Hint) you can eval arbitrary Haskell from strings in a type-safe manner.

You can even parse arbitrary data from strings in a type-safe manner without resorting to an interpreter:

    -- throws error
    read "blah" :: Int 

    -- returns 1
    read "1" :: Int

via the magical joy that is Haskell typeclasses. Trivial but still very nice stuff.

Type-checking requires statically derivable information. You won't get any of the niceness unless you design your language around it.

I don't care about syntax either. It don't think it really matters and it takes all of an evening to get used to syntax from any language.

Yeah, `this` is freakin' ridiculous.

copergi3• 12 years ago

Javascript is weakly typed. And untyped does not mean no type declarations. It means no types, just like it says. Assembly is untyped. Javascript is dynamically typed. Very different. http://en.wikipedia.org/wiki/Programming_language#Typed_vers...

Javascript does not define the implementation details. It does not have to be interpreted, and in fact I don't believe any modern implementation is interpreted. Javascript is generally compiled to byte code which is then run in a VM, or native machine code (V8 at least does this). There is no reason javascript could not have a static type system, there are statically typed scripting languages. It is dynamically typed by deliberate decision, not "we can't do it any other way".

masswerk6• 12 years ago

On the `this` feature: This is mostly a "problem" with the DOM-interface, which is not part of the language. But there is even a solutions for this in JS: Object.handleEvent() -- Why is everyone complaining on the lack of a feature that is in fact already built in? Just start using it ... Also, since functions and objects are first class entities, you may just store references and make use of them as you like. (But, please, don't use "var self = this;", since `self` is already a predefined variable pointing to the global object.)

owenversteeg4• 12 years ago

I guess the Haskellers noticed this HN thread. One moment my comments were at 2 points, the next they are at zero. It seems to be the same for other non-anti-Javascript comments.

If you're trying to solve the perception of being snooty and unpleasant (as mentioned in this thread), downvoting everything isn't going to get you far.

stplsd2• 12 years ago

Oh, article with attitude.

pcwalton• 12 years ago

lack of module system

ES6 fixes this with, well, a module system.

weak-typing,

Yup, this is a problem.

verbose function syntax,

ES6 fixes this with arrow functions.

late binding

Does this just mean dynamic typing? Well, yes, JavaScript is dynamically typed, but I wouldn't call that a language flaw. Static vs. dynamic typing is a tradeoff.

which has led to the creation of various static analysis tools to alleviate this language flaw

The footnote talks about JSLint and friends, but none of those impose a type system, which means that they do nothing about dynamic typing.

but with limited success (there is even a static type checker)

Well, yeah. It's very hard (read: "research problem") to impose a good static typechecker on a dynamically typed system, though.

finicky equality/automatic conversion

Yeah, this is bad. I really wish tools like restrict mode [1] had caught on: together with ES6 they eliminate a lot of what people dislike about JavaScript.

this behaviour,

Fixed in ES6 if you use arrow functions (finally!)

and lack of static types.

Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff.

[1] http://restrictmode.org/

teacup5014• 12 years ago

Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff.

This is the Haskell wiki. I would expect most participants to view having a single global implicit union type to be a flaw, not a trade-off.

djur5• 12 years ago

It's sad that we should expect Haskell users to be chauvinistic about static typing. I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

_random_2• 12 years ago

Best languages allow both type systems with dynamic being opt-in.

briantakita5• 12 years ago

I accept that I will be downvoted for this.

My impression of the Haskell community is its full of snobbery and complaining.

This has got to be the 4th javascript ducks post on hn in the past week.

I like hearing the positive aspects of Haskell. However, the language x sucks posts are tiresome.

Develop an imagination. Javascript can be wielded very effectively. It's just different. I hope that I or someone else wires posts on what can be done to be effective with javascript and weakly typed systems.

There are advantages to using weakly typed languages, mostly centered around flexibility and rapid iteration. The disadvantages are alleviated by comprehensive functional or black box testing. Skip the unit tests.

I feel liberated by not having a strong type system restricting my options. Ymmv. People have different styles and preferences.

WoodenChair4• 12 years ago

Here's the problem with your post - and it has nothing to do with what you think it does. It attacks two things at once and quite distinctly. On one hand you're defending JavaScript - and that's separate from your attack on the Haskell community. It's just unfocused and confusingly conflated. I'm not going to down vote you, but you need to organize your thoughts a little more coherently if you don't want to get down voted.

PS The reason there are so many JavaScript sucks posts is because JavaScript, a language designed for very menial things in 10 days in the mid 1990s, has become the lingua franca of the world and is used for sophisticated applications outside of its wheelhouse. A lot of very respectable people believe it's a poor tool for the complex applications that it's being used for and the less respectable people just reiterate this as "it sucks". It's not that it sucks for making a photo gallery, it's that it sucks compared to other languages for making a rich, modern, immersive, large application. They key word there is large. All of the reasons they reiterate about the "why" it sucks are only relevant when you couple it with the "large".

briantakita5• 12 years ago

Apologies about the lack of cohesion of my post. It's tough to make posts on a phone.

I have to confess that my interactions with the Haskell community have not been positive as I would like. My development preferences are not respected by Haskell fans. I'm ok with disagreement. However, if I do "defend" javascript, I'm attacked as being ignorant because I don't see things the same way.

My point is javascript can be an amazing experience, and very scalable, if approached in certain ways.

I acknowledge that Haskell is amazing too.

It's not that it sucks for making a photo gallery, it's that it sucks compared to other languages for making a rich, modern, immersive, large application. They key word there is large.

Very large apps have been made in c. I'm making a fairly large app in javascript. It's been pretty fun. I'm confident that the app im working on can be scaled to be considerably bigger.

A problem is most people try to use techniques that are more appropriate in other languages.

masswerk6• 12 years ago

But by doing so, the post marks a real problem: The critique of JS seems to be mostly based on the prestige the languages is enjoying -- or rather the lack thereof -- in a community. Any of those features is to be found in highly respected languages, too. Most of the rants are about respect and not being willing to respect the specifics of the language. Why has JS to be built to suit test suites and tool chains originally designed for C/C++? Why not adapt those tools for the use with JS? Isn't this, what a universal machine is for? "Sucks" may be an easy answer, but it shouldn't be a general one.

Edit: There are only few high level languages which would adopt to such a wide range of programming patterns like JS does, or which would allow to be redefined by such large an extent. (This is mostly for the much frowned on late binding.) Isn't this rather adorable than awful?

Other reasons, why JS would "suck" seem to be quite deliberately: Curly brackets -- what about C or Java? Semicolons -- In the beginning, JS was critiqued for not requiring them and using them rather as a separator (in the first syntax version). Verboseness -- isn't the lack thereof why APL used to be quite a horror? Type coercion -- Isn't this, what made Perl that useful as a glue-language? The critique is quite à la mode.

wyager3• 12 years ago

My impression of the Haskell community is its full of snobbery and complaining.

Probably because the Haskell community is used to having a programming language that is, in and of itself, very good. They complain because they know what they're missing when they have to use inferior tools.

Develop an imagination. Javascript can be wielded very effectively. It's just different.

The same can be said of x86 assembly. That doesn't mean we don't complain about programming in it, and we don't try to find better alternatives. The entire field of programming language development is about finding tools that are better than the old ones, even if the old ones work OK.

The disadvantages are alleviated by comprehensive functional or black box testing.

If you think "more testing" alleviates all the problems of weakly typed languages, you have no idea what you're missing.

I feel liberated by not having a strong type system restricting my options.

If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.

"I like assembly because it lets me do any operation on anything."

Solarsail2• 12 years ago

If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.

Only a perfect type system is capable of preventing only wrong things, and allowing all correct things. In the mean time, we're left with things that are slightly less perfect. Like OCaml, Haskell, SML, Java, Smalltalk, Ruby, Javascript, Python, PHP, Prolog, and everything else that even attempts a type system.

gordaco• 12 years ago

>I feel liberated by not having a strong type system restricting my options.
If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.

I'm always baffled about how people say that using a dynamic language feels "liberating". I feel completely the opposite; I have to be extremely more careful with a dynamic language since either there is no compiler or it can't detect many errors, so I have to do it myself (because, and this is a very important lesson for absolutely everyone without exceptions: you will commit mistakes, no matter how good you are or how good you think you are). Getting rid of static typing feels to me like, above all, getting rid of a lot of very useful guarantees.

teacup5014• 12 years ago

People have different styles and preferences.

In terms of Haskell, it's not a question of style or preference, but provable correctness of the underlying theory.

I don't think programmers should have to be category theorists to 'effectively wield' a language, but category theorists sure as shit ought to be involved in designing the language being wielded.

I'm not a Haskeller, but I very much respect the research they've done, and continue to do -- and how it significantly improves the languages I do use.

However, the design and culture of languages like JavaScript are very much mired in inconsistent misguided design and cultural anti-intellectualism; they do not and can not benefit from the advancement in the state of the art, and are the programming equivalent of building bridges and skyscrapers without consulting structural/material engineers, based on a back-of-the-napkin sketch.

Personally, I don't prefer static typing -- I simply don't know of any other mechanism by which I can actually have a hope of understanding software I'm writing of any appreciable level of complexity.

I don't see where "preference" fits in here, other than "preferring" to not actually fully understand the system you're building.

somebehemoth2• 12 years ago

Bold claims and strong language do not make up for a lack of citations. You prefer static typing because you admit it is the only hope you have of understanding your complex code. However you dismiss other peoples' preferences by claiming they are ignorant of the systems they are building. Are you, perhaps, the one true Scotsman?

copergi3• 12 years ago

I accept that I will be downvoted for this.

Why would that happen? Ignorantly bashing haskell strawmen is pretty common here. Btw, while you hit two of the biggest ones, you did forget to complain about it being "academic" and thus unusable for "real world" programming. That should be pretty much standard by now.

masswerk6• 12 years ago

Just upvoted the post, sorry. ;-)

These rants really seem to be based on the degree of respect some languages are enjoying in a certain community. Take weak typing / type coercion for an example: This is a common feature of scripting languages of the time, e.g.: Perl. I never read Perl being complained on for the same issue, which might well be, because it is a "serious" system language and because you might have to "really" learn it for any advanced use. (Even the boolean testing of int return types in Unix and C could be considered as some kind of premature type coercion.)

Late binding is probably most powerful feature of the language. (The language is built around it.) If it doesn't go with your test suites, considering that both the language and the language the tests are built with are Turing complete, adapt the tests rather than the language. This is a bit like ranting on C not being Logo and for it having other output facilities than a turtle.

Why not just develop in JS -- read: think JS --, for a change?

chrisdone11• 12 years ago

Horses are okay, but they're expensive, require much more maintenance, can only go about 40mph for a brief period of time, and can only seat two people, uncomfortably. And you're telling people who want to build roads to put cars on “why not just think in horses for a change?”

chrisdone11• 12 years ago

This wiki page is 2 years old, I assure you the Haskell community settled this debate years ago and have moved on with our lives. We've since implemented a bunch of compilers to JavaScript. I suspect, rather, that you are criticizing the part of the HN community that submits links and those that upvote them.

For what it's worth, for someone calling people “snobbish” and “complaining”, it's quite rich to make a comment which is complaining and to say “develop an imagination.” :-)

pan69• 12 years ago

I'm surprised that Haxe isn't in the list of alternatives. It's been around for quite a long time and it's very mature:

http://haxe.org/doc/features

chrisdone11• 12 years ago

Oh, interesting. What's it like to use? Please add it to the article. I'm adding Opa now.

jurassic• 12 years ago

The people who hate javascript the most are the ones who wish it was something else. I used to be one of those people. Once I decided to accept it as it is and read a few top books on the language to learn the "javascript way", my life got a lot better. It's really not that bad. I actually like it a lot, but there are still a lot of ignorant people who will look at you as if you're not l33t enough to know that foo language is better if you tell them you have a favorable view of js.

Of the things on his list, the only ones that really resonate with me at all are verbose function syntax and silent coercion. Typing function () {} gets old fast, but then I set up snippets and it ceased being a problem. That really just leaves the type coercion problem, which you adapt to pretty quickly if you're using the language in earnest.

What it boils down to is choosing to be a pragmatist who gets down to work with what's available instead of a naval gazer who swears everything will be awesome as soon as they have their preferred tool|language available. There are tons of compiles-to-js alternatives, but I don't see a huge difference in the productivity of people working in these not-JS alternatives. Where are the killer apps that were developed through a niche JS transpiler? If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate.

kenjackson3• 12 years ago

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate.

We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a single language and seemingly little real effort to build a Multilanguage abstraction.

If you told me 20 years ago about what the web would become, I'd be amazed. If you went on to say that all programming would be in a single language -- I'd think you were crazy, yet here we are.

The web should have added 1st class support for plug-ins, rather than the direction we went to effectively abolish plugins from browsers.

jmspring2• 12 years ago

Browsers should not be multi-lingual -- more bloat.

The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

cbhl2• 12 years ago

The web was multi-lingual, it's why script tags have a "type" parameter.

I personally think that the death of plugins came about as the result of the iPhone, because x86 binary plugins won't run on an ARM-based phone.

Swizec• 12 years ago

Javascript's real problem is unfamiliar semantics hidden behind familiar syntax. It throws people off and they hate the language because they think it's weird. Really, they just haven't learned how to actually use it.

gutnor• 12 years ago

Javascript is a tiny language, but it pack a serious amount of gotcha.

If you learn the javascript way, you just realise that the core language provide little to no tooling around it. Like if you really want to fully utilise the prototype based inheritance, or the functional aspect of the language, you will basically have to write a whole set of utilities and extension on your own.

Of course, javascript run in the browser, is small and super simple, so it packs a lot of fun. To me it oddly reminds me toying with assembly in the old DOS 16 bit days and I like it despite its flaws ( and well those flaws are being addressed in latest iterations ) But the flaws are real, and if you need to use it on a big project with a regular team, and not complete freedom of choosing the browser you support, javascript will make you cry more often than smile.

baddox2• 12 years ago

Doesn't that argument get weaker as JavaScript gets more widely used? It's already one of the most prominent languages in the world, and is probably increasingly the first programming language encountered and learned by beginners.

teacup5014• 12 years ago

Where are the killer apps that were developed through a niche JS transpiler? If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate.

You're right about one thing: JavaScript is awful, but trying to avoid JavaScript while targeting a web browser is worse.

I simply don't write software for the web. HTML/CSS/JS is too much of a train wreck of bad design for me to find any pleasure whatsoever in the task, and I'm content leaving the job anyone that can stomach it.

However, if we followed your argument to its conclusion, we'd never escape the atrophied staleness of a browser technology core that somehow has never moved past 1995-era Netscape.

rdtsc2• 12 years ago

I think it comes down to two things.

* Acknowledging that it has many many warts. Weak types, modularity, every number is a double, etc. some of those warts are there. Explaining why they are there historically doesn't make them go away either. "Oh but it was only written in 1 month so.." -- "Yeah it is still broken".

Many things can be chucked to "not broken but different". But, some are just broken, no sane language released after 1990's should not be this broken unless it was on purpose (brainfuck).

* Realizing that in practice, currently, there are not too many alternatives and just learning to use it. Like you say just getting down to being pragmatic. One can talk about functional purity but that doesn't usually bring food to the table. A finished site does.

But you see how the two are different. Many confuse them. For example, saying the language is fine and great just because they learned it and are using it. Yeah, at some level we want to feel good about the tools we use, so it is harder psychologically to say "this stupid thing I have to use every day". It goes the other way, just because the language is broken and there is some pure language, re-writing the site into might be very risky.

I personally am looking at Dart with excitement but at the same time won't be urging anyone yet at work to switch to it yet. Kind of a chicken and egg problem, I understand, we just can't afford to take that risk yet. But with time who knows.

Peaker3• 12 years ago

IMO the biggest problem, even worse than type coercions, is the error silencing regarding wrong argument counts.

This can easily hide so many bugs, it's amazing it is acceptable to anyone.

Kiro4• 12 years ago

Do you have an example?

briantakita5• 12 years ago

In practice, this issue is rarely (like 1-2 times a year) encountered. And then functional tests catch the error. It would not be acceptable if it was a constant thorn.

camus24• 12 years ago

The people who hate javascript the most are the ones who wish it was something else.

Ask yourself,how can a single language can fit every use cases,for every developpers? We cant agree on what we should use on the server,but we are basically forced to use 1 language in the browser,of course some people are going to hate it.

I shouldnt have to adapt javascript,javascript should adapt my coding style.But aint gona happen.

Weak typing and Type coercion are imho the biggest flaw of javascript,I can live with the rest,but not that.

Proxies will help a bit though.Devs will definetly abuse them.

Aardwolf• 12 years ago

verbose function syntax

I didn't agree with that one myself. I mean, ok, now we have C++11 and can just type [](){} for inline lambda functions, but before C++11 you needed a huge amount of boilerplate to pass a function to something. JavaScript's way to just type "function something" inline was so non-verbose and convenient compared to that.

So what is it being compared to instead here? Functional programming languages?

michaelsbradley5• 12 years ago

Seems a bit strange that there is no mention of ClojureScript in the "FP -> JS" section.

fiatmoney• 12 years ago

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinating dependent updates to a UI based on events happening to a base state - for a concrete example, the Om wrapper around React is very slick, performant, and idiomatic.

michaelsbradley5• 12 years ago

And if you want to leverage those functional data structures in a vanilla JavaScript context, there's a pre-compiled ClojureScript library for that!

http://swannodette.github.io/mori/

https://www.npmjs.org/package/mori

camus24• 12 years ago

clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.

michaelsbradley5• 12 years ago

Would you articulate why it's a "no go" for you?

Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing.

It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3] to David Nolen's mori library.

[1] http://leiningen.org/

[2] https://github.com/emezeske/lein-cljsbuild

[3] https://github.com/swannodette/mori/blob/master/package.json...

auvrw• 12 years ago

wouldn't it make more sense to implement the clojurescript compiler in clojurescript so it can run on node?

i get disliking having to fire up the jvm versus a light runtime like python or node if that's where you're coming from, but i don't mind twiddling my thumbs for a moment when i first sit down to write clojure, because not just the language but also the libraries and tools are more fun/interesting to use than a pure node (or pure python, for that matter)두environment.

in short, and not to be snide, perhaps you've already written some clojurescript, but to anyone else reading over: try writing some clojure/clojurescript. you might not like it for whatever reason, but at least then it'll be a case of "no return" instead of "no go."

chrisdone11• 12 years ago

Really the only thing missing from Clojurescript, as all Lisps, is static types.

cordite• 12 years ago

This is especially a problem (which can only be discovered at runtime) with newbies. It has some nice constructs but my friends and even sometimes myself end up with problems like trying to deref an atom that is already dereffed, or not dereffing in the first place.

hrktb• 12 years ago

The things that gave most of javascript quirks were auto comma insertion, this, and global variable declaration. It's the same as how HTML has horrible parts because from the start it bending backward to be as fault tolerant as implementable.

That's why it succeeded and why a strong staticly typed language with very strict error enforcement wouldn't have made it in the first place. Some things are added bits by bits later (e.g modules, strict mode). The rest is a matter of taste and use case: late binding allows different things, all numbers as float is tasteless but it's not handicaping and there are ways around it, syntax is a matter of tooling.

I think anyone wanting to write serious applications for a platform should try to be the closer to the native environment, and adding an abstract layer on top of javascript because 'it sucks' feels childish.

chrisdone11• 12 years ago

Using words like “sucks” is a bit of fun. Seeing obvious deficiencies in a language and putting up with it for years instead of doing some work and using a better one is childish.

vqc• 12 years ago

I feel like "The Birth & Death of JavaScript" by Gary Bernhardt is appropriate for this discussion. https://www.youtube.com/watch?v=Nr7ZEXLJHtE

In fact, the talk seems appropriate for every discussion regarding, but not limited to, how terrible JS is or how it should die.

benjaminjackman• 12 years ago

Scala.JS is doing well for me.

chrisdone11• 12 years ago

Please add it to the article and report your findings! =)

Kiro4• 12 years ago

I'm surprised that lack of module system is the first thing brought up. Is that really such a big deal? It's very much just a nice to have for me and has plenty of third-party implementations if you want it.

zoomerang• 12 years ago

It's just another annoying thing on the list of warts with Javascript that make maintain a large codebase a pain in the arse.

Plenty of third party implementations is half the problem. Want to import a module by somebody using a different module format? More pain in the arse!

chrisdone11• 12 years ago

It's similar in the Scheme community. It's easy to write your own module system. So every compiler and every second Schemer has their own module system with its own quirks and assumptions.

LunaSea2• 12 years ago

Most large projects use AMD and it works just fine.

chrisdone11• 12 years ago

I wrote (the start of) this page. Please bear in mind this is the Haskell community. We like our static types. This page is also kind of old news (2 years old) for us, the discussion is over, really. But I'll describe the history of it for those interested.

So I wrote this paragraph (http://www.haskell.org/haskellwiki/The_JavaScript_Problem#Ot...) in 2012 in a reply to a reddit comment. Around that time the Haskell community was growing in its web dev circles, and we as a community were cultivating a sense that writing our web apps was not fun in 50% of the task, which was the front-end.

There were actually a bunch of alternative attacks.

* Using so-called widgets which are compiled by Haskell and contain very minimal pieces of JavaScript that the user of the library never sees. This is okay. But if you're developing something more complex, you start to wish you were back in Haskell.

* Some were also thinking, perhaps it's just the framework that makes this work awful, we just need to pick the right reactive-MVC kind of framework.

* Use HJscript, an EDSL of JavaScript embeded in Haskell. This is not bad, I used this in hpaste and it's still running today: https://github.com/chrisdone/lpaste/blob/master/src/Hpaste/V... However, you're still left with the semantics of JavaScript, it doesn't really improve upon it. Although, if you're interested in this approach, definitely checkout Sunroof https://github.com/ku-fpg/sunroof-compiler which is like a new and improved version which has continuations out of the box.

* Some thought maybe CoffeeScript was enough, but it quickly becomes obvious that the problem is nowhere near syntax-deep.

In the end, I think everyone pretty much agreed just using Haskell would be better. But there were no viable transpilers, so we were continuing with JavaScript feeling that things could be better.

After that I decided to start trying out the bitrotted crop of compilers. I tried GHCJS first, and reported my findings: http://chrisdone.com/posts/ghcjs The first couple paragraphs are now on the wiki. I thought this community "feeling" should be documented, and copying “The Expression Problem”, thought it would be catchy to make a “The JavaScript Problem” post that is concise, opinionated and comprehensive. Ask any random Haskeller and they will pretty much agree with both paragraphs. It's easy to point someone to a wiki article to have a common understanding of the problem.

I'm not one to simply whinge about things, however. I wrote down alternatives and tried a few out myself. I experimented with GHCJS (above) and UHC (here http://chrisdone.com/posts/uhc-javascript) and HJScript. Eventually, unsatisfied, I wrote the Fay compiler: https://github.com/faylang/fay/wiki which was inspired by the simplicity and small output of Roy and the FFI in UHC, and was a success (to some degree) because it was super easy to setup and its output was understandable. We're using Fay at FP Complete for the IDE, we have about 16k lines of code in Fay.

In parallel, the GHCJS codebase got a new set of very active maintainers, the Haste compiler appeared http://haste-lang.org/ and generally the community started to feel “hey, not only is compiling to JavaScript practical, but we're starting to feel this should become standard web dev in Haskell.” If you look at the crop of Haskell web frameworks (big three are Yesod, Snap, Happstack) they all support compiling via Fay and I'd expect haste, too.

I see some comments in this submission that the Haskell community is "snobbish" and "complaining". We're apparently among the people who “wish JavaScript was something else” and we shouldn't be one of those people, that we just don't really “get” JavaScript and how to write it properly. We want a car because we don't appreciate how to ride a horse properly. I'd say the opposite. Here we saw the problem (as we saw it), and started working on practical solutions and now people are getting paid to write Haskell that runs in the browser. If that's not putting money where your mouth is, I don't know what is.

Also look at the OCaml community with http://ocsigen.org/js_of_ocaml/ (also an inspiration for my endeavors) and the Clojure community with https://github.com/clojure/clojurescript They identified the same problem and got to work. :-)

Since I added that wiki article, a bunch of new compilers and languages have been added to the page (or invented). For the chorus of people asking "why isn't X listed?", it's simply because users contribute to the article, it was much smaller. So if you've heard of another approach, and, importantly, if you've tried it and can report practicality, please go ahead and add it. I think I'll add Opa to the list, it's like Ur in that you write front-end and backend code in the same language.

z3t4• 12 years ago

The problem you see is what I like about the language.

The javascript languages is great because I'm not forced into other peoples way of thinking. With javascript I can choose my own paradigms.

module system: You can implement your own. Node JS has one built in.

verbose syntax: Use an editor that support macros. But compared to dot net and Java, the JS syntax is not verbose at all.

getters and setters: I actually love not having to to write getters and setters every time I want to add a property.

One important part in JS though is good naming. You can't get away with naming everything x, y, z, a, b, c, etc.

Once you figure out that everything in JS is objects, it will be much easier.

The JavaScript Problem

Related Stories