12 ms·

The JavaScript Problem

126 points by falava 12y ago

jnbiche 12y ago
I'm surprised that Elm is not mentioned: http://elm-lang.org/edit/examples/Reactive/ZipCodes.elm 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 12y ago
  It's a wiki. You are free to add this information. =]
  - jnbiche 12y 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.
    - chrisdone 12y ago
      Good point, it was full of spam and registration was closed. I forgot about that. It was because we had a really old MediaWiki version so it was actually unsafe to allow anyone untrusted to post on it due to exploits possible at the time. I say “we”, I don't have access to manage haskell.org. I'mma ping the mailing list to see about fixing this.
      - jnbiche 12y ago
        I think that's an excellent idea. Well-done.
    - kluge 12y ago
      I think spam was exactly the problem. It's a shame and seems to really hurt. There's a lot of outdated information in the wiki and I suspect the obstacle to making fixes is a big contributor.
- coolsunglasses 12y 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-types.html http://bitemyapp.com/posts/2014-04-11-aeson-and-user-created...
  - jnbiche 12y 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).
    - coolsunglasses 12y ago
      Do not underestimate how powerful and useful HKTs and typeclasses are until you've used them in anger. I have a guide to learning Haskell here: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525 You should give it a whirl. Just use PureScript if you're fortunate enough to know alternatives to JS exist :)
      - skrebbel 12y ago
        Why are you intentionally ignoring half of the parent's comment, twice? You're not contributing to the discussion at all.
WoodenChair 12y 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 12y ago
  The page is about JS. TS is a superset of JS, and Dart is an entirely different language.
  - jbdeboer 12y ago
    The article starts with the assertion "We need Javascript". Adding Dart to the mix makes that assertion less obvious.
  - jasonlotito 12y ago
    It mentions Coffeescript.
  - mseepgood 12y ago
    All other languages listed on that page are entirely different languages as well.
dpratt 12y 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.
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
girvo 12y 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?
- WoodenChair 12y 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.
  - girvo 12y 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 :(
    - WoodenChair 12y ago
      You're not going to get anywhere with the ninjas. Suggest a system that's similar to what you do your backend in. Is your backend in Java? Suggest Dart. Is your backend in C#? Suggest TypeScript. Is your backend in Ruby? Maybe you can at least get some CoffeeScript going.
- md224 12y 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.
platinumdragon 12y ago
Pure FUD. Obviously meant for the Haskell fanboys. Not worth the read otherwise.
owenversteeg 12y 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.
- deleted 12y ago
  [deleted]
- nilkn 12y 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-mean-dynamically-typed-in-the-academic-cs-world http://stackoverflow.com/questions/9154388/does-untyped-also...
  - owenversteeg 12y 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 12y 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.
stplsd 12y ago
Oh, article with attitude.
pcwalton 12y 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/ http://restrictmode.org/
- teacup50 12y 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.
  - djur 12y 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".
    - copergi 12y ago
      >It's sad that we should expect Haskell users to be chauvinistic about static typing. We don't expect that. We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. >I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw". Try looking on the internet. Every "static vs dynamic" argument has 99% of the dynamic side arguing that static typing is bad because java's type system limits them and doesn't prevent any bugs.
briantakita 12y 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.
- WoodenChair 12y 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".
  - briantakita 12y 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.
pan69 12y 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 http://haxe.org/doc/features
- chrisdone 12y ago
  Oh, interesting. What's it like to use? Please add it to the article. I'm adding Opa now.
jurassic 12y 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.
- kenjackson 12y 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.
  - jmspring 12y 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.
michaelsbradley 12y ago
Seems a bit strange that there is no mention of ClojureScript in the "FP -> JS" section.
fiatmoney 12y 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.
- michaelsbradley 12y 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/ http://swannodette.github.io/mori/ https://www.npmjs.org/package/mori https://www.npmjs.org/package/mori
- camus2 12y 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.
  - michaelsbradley 12y 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/ http://leiningen.org/ [2] https://github.com/emezeske/lein-cljsbuild https://github.com/emezeske/lein-cljsbuild [3] https://github.com/swannodette/mori/blob/master/package.json#L41 https://github.com/swannodette/mori/blob/master/package.json...
    - jkrems 12y ago
      Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.
hrktb 12y 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.
- chrisdone 12y 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 12y ago
I feel like "The Birth & Death of JavaScript" by Gary Bernhardt is appropriate for this discussion. https://www.youtube.com/watch?v=Nr7ZEXLJHtE 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 12y ago
Scala.JS is doing well for me.
- chrisdone 12y ago
  Please add it to the article and report your findings! =)
Kiro 12y 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 12y 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!
  - chrisdone 12y 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.
  - LunaSea 12y ago
    Most large projects use AMD and it works just fine.
chrisdone 12y 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#Others 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/View/Script.hs 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 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 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 http://chrisdone.com/posts/uhc-javascript) and HJScript. Eventually, unsatisfied, I wrote the Fay compiler: https://github.com/faylang/fay/wiki 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/ 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/ http://ocsigen.org/js_of_ocaml/ (also an inspiration for my endeavors) and the Clojure community with https://github.com/clojure/clojurescript 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 12y 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.

126 points by falava 12y ago

I'm surprised that Elm is not mentioned: http://elm-lang.org/edit/examples/Reactive/ZipCodes.elm 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 12y ago
It's a wiki. You are free to add this information. =]
- jnbiche 12y 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.
  - chrisdone 12y ago
    Good point, it was full of spam and registration was closed. I forgot about that. It was because we had a really old MediaWiki version so it was actually unsafe to allow anyone untrusted to post on it due to exploits possible at the time. I say “we”, I don't have access to manage haskell.org. I'mma ping the mailing list to see about fixing this.
    - jnbiche 12y ago
      I think that's an excellent idea. Well-done.
  - kluge 12y ago
    I think spam was exactly the problem. It's a shame and seems to really hurt. There's a lot of outdated information in the wiki and I suspect the obstacle to making fixes is a big contributor.
coolsunglasses 12y 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-types.html http://bitemyapp.com/posts/2014-04-11-aeson-and-user-created...
- jnbiche 12y 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).
  - coolsunglasses 12y ago
    Do not underestimate how powerful and useful HKTs and typeclasses are until you've used them in anger. I have a guide to learning Haskell here: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525 You should give it a whirl. Just use PureScript if you're fortunate enough to know alternatives to JS exist :)
    - skrebbel 12y ago
      Why are you intentionally ignoring half of the parent's comment, twice? You're not contributing to the discussion at all.

WoodenChair 12y 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 12y ago
The page is about JS. TS is a superset of JS, and Dart is an entirely different language.
- jbdeboer 12y ago
  The article starts with the assertion "We need Javascript". Adding Dart to the mix makes that assertion less obvious.
- jasonlotito 12y ago
  It mentions Coffeescript.
- mseepgood 12y ago
  All other languages listed on that page are entirely different languages as well.

dpratt 12y 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.

deleted 12y ago
[deleted]

deleted 12y ago

[deleted]

girvo 12y 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?

WoodenChair 12y 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.
- girvo 12y 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 :(
  - WoodenChair 12y ago
    You're not going to get anywhere with the ninjas. Suggest a system that's similar to what you do your backend in. Is your backend in Java? Suggest Dart. Is your backend in C#? Suggest TypeScript. Is your backend in Ruby? Maybe you can at least get some CoffeeScript going.
md224 12y 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.

platinumdragon 12y ago

Pure FUD. Obviously meant for the Haskell fanboys. Not worth the read otherwise.

owenversteeg 12y 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.

deleted 12y ago
[deleted]
nilkn 12y 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-mean-dynamically-typed-in-the-academic-cs-world http://stackoverflow.com/questions/9154388/does-untyped-also...
- owenversteeg 12y 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 12y 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.

stplsd 12y ago

Oh, article with attitude.

pcwalton 12y 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/ http://restrictmode.org/

teacup50 12y 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.
- djur 12y 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".
  - copergi 12y ago
    >It's sad that we should expect Haskell users to be chauvinistic about static typing. We don't expect that. We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. >I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw". Try looking on the internet. Every "static vs dynamic" argument has 99% of the dynamic side arguing that static typing is bad because java's type system limits them and doesn't prevent any bugs.

briantakita 12y 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.

WoodenChair 12y 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".
- briantakita 12y 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.

pan69 12y 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 http://haxe.org/doc/features

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

jurassic 12y 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.

kenjackson 12y 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.
- jmspring 12y 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.

michaelsbradley 12y ago

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

fiatmoney 12y 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.

michaelsbradley 12y 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/ http://swannodette.github.io/mori/ https://www.npmjs.org/package/mori https://www.npmjs.org/package/mori
camus2 12y 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.
- michaelsbradley 12y 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/ http://leiningen.org/ [2] https://github.com/emezeske/lein-cljsbuild https://github.com/emezeske/lein-cljsbuild [3] https://github.com/swannodette/mori/blob/master/package.json#L41 https://github.com/swannodette/mori/blob/master/package.json...
  - jkrems 12y ago
    Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.

hrktb 12y 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.

chrisdone 12y 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 12y ago

I feel like "The Birth & Death of JavaScript" by Gary Bernhardt is appropriate for this discussion. https://www.youtube.com/watch?v=Nr7ZEXLJHtE 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 12y ago

Scala.JS is doing well for me.

chrisdone 12y ago
Please add it to the article and report your findings! =)

Kiro 12y 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 12y 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!
- chrisdone 12y 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.
- LunaSea 12y ago
  Most large projects use AMD and it works just fine.

chrisdone 12y 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#Others 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/View/Script.hs 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 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 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 http://chrisdone.com/posts/uhc-javascript) and HJScript. Eventually, unsatisfied, I wrote the Fay compiler: https://github.com/faylang/fay/wiki 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/ 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/ http://ocsigen.org/js_of_ocaml/ (also an inspiration for my endeavors) and the Clojure community with https://github.com/clojure/clojurescript 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 12y 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.