1. 19

  2. 6

    Although there are some valid points in the article, I don’t think the situation is that bad, nor that it’s necessarily getting worse. There are very interesting projects in the field solving some of the problems – first that come to mind are the likes of Ur/Web, Ocsigen, ClojureScript, GHCJS, Idris' JS backend… They mostly assume you’re OK with JavaScript being the “intermediate language”, something the author clearly isn’t too comfortable with. I don’t think it’s probable we’ll eliminate that assumption anytime soon, though, but there are projects – like asm.js – to make it more viable. That one even has potential to become successful (especially if you squint a bit).

    None of these are without their challenges, one of the primary ones being the fact that the stability and maturity of the platforms leaves much to be desired. That’s not too surprising considering we’ve only relatively recently discovered the need for a decent way of writing web apps, and that we’re trying to fit fairly advanced concepts onto a platform which was originally designed to make animated GIFs bounce around on a web page.

    An even bigger problem is that it’s simply too easy to go with the flow and write your next app in JS, PHP, or whatever the current seemingly-suboptimal-platform-du-jour is. There’s too much existing code, too much documentation, too many integration examples, and inertia does its thing – at least I know it often does in my case. We’ve yet to see a “Real World Ocsigen” or “Real World Ur/Web”, but it seems there are enough smart people out there working with these new technologies that it’s reasonable to expect we will.

    All in all – I do think things are looking up, and that there will be a shift in the way we’re writing software. It definitely won’t happen overnight. While it can seem frustrating, I sometimes find comfort in the fact that people have been writing amazing software with far worse and/or more primitive tools than the ones we use today (even the ones we whine about all the time). :)

    1. 8

      While the Idris JavaScript backend is great, I think PureScript is a really great solution to the JavaScript problem and it is getting very close to being practical. I know some people are coming close to putting it into production. Exciting!

      1. 4

        Right, PureScript is very interesting! If you could talk those people into writing up their experience with using it in production, I’d definitely be quite interested to read it! :)

        1. 2

          i’m very excited about purescript, and particularly about using it as the “hard layer” with a clojurescript-based ui layer on top of it (i vacillate between preferring ml-based or lisp-based languages to write ui code in, but right now i’m leaning towards the lisp side because i like the feeling of being able to move blocks of code around freely while experimenting and then baking the pattern into a more rigid function or macro once i’m done)

      2. 5

        For example, look at this nodejs module, exit. All it does is exit a node application in the way one would expect, after flushing standard streams like STDOUT. It’s a 41 line node module. A THIRD PARTY MODULE AND FORTY-ONE LINES TO EXIT CLEANLY!!

        How can we ever talk about declarative programming when we can’t even abstract the basics away?

        Isn’t using libraries an abstraction? Importing code is one of the best abstractions we have in programming: functions that hide immense function-ality behind simple calls.

        Most modern languages have that kind of capability these days. In fact, if there’s any “code that is not specific to [your] application/domain,” you should be able to abstract it away without having to change the language spec.

        If I’m tired of getting the port from my env in Go, I can just write a reusable function. If you’re re-writing too much code, find a good library or write your own :)

        port := os.GetEnv("PORT")
        http.ListenAndServe(port, nil)


        func ServeOnPort() {
            port := os.GetEnv("PORT")
            http.ListenAndServe(port, nil)

        As to being locked in to JS for front-end work, it does look pretty bleak right now. asm.js is looking really promising though! Check it out! Anything that can compile to the LLVM can compile to asm.js. This includes Go, C, C++, Python, and many others.

        1. 4

          That is why I made Fire★. The web is great for publishing, but horrible for interactive applications.

          1. 4

            I think we need to embrace the compile-to-JavaScript languages. This gives us the optimal balance between using the languages we want, and divorcing ourselves from JavaScript the language. Once we’re no longer writing code in JavaScript the language, then we can start thinking about JavaScript the VM. This means we all don’t need to update our code bases, only the compilers need to be updated (which is a significantly smaller number of code bases) as JavaScript the VM is improved. JavaScript the VM can evolve differently, with different goals mind, than JavaScript the language.

            I’d argue that it’s harmful for people to continue using JavaScript the language for their projects because then it’s harder to have it evolve into JavaScript the VM. Ultimately, it probably wont matter because over time the comple-to-JavaScript languages will become more enticing.

            I can’t help but believe that we’ve ran into a similar problem before… like when compilers were invented.

            1. 3

              I think web development has divided into two camps:

              Camp A: Full-stack JavaScript

              With the advent of Node and the MEAN stack developers no longer have to switch contexts during development; it can all be JavaScript. Sure, JS might not be the best language but 1) it’s the language that the current generation of developers have grown up hacking on, and 2) its the least common denominator so it kind of has to be JS.

              Camp B: JavaScript is a tumor.

              JavaScript is a half-baked language spun out of control and if developers don’t bandage the wound it will fester. Developers have two options here. Pragmatic: Standardize on 1-2 compile-to-js languages for anything in the browser. Stretch: Replace JS with another language in the browser.

              Recently I’ve found myself agreeing with people in Camp B more. I don’t think Camp B’s stretch goal is realistic at all, however, so I’ve been seriously looking into languages like Dart or CoffeeScript.

              1. 3

                I can see where he is coming from. I’ve been writing web stuff for a long long time and I’m actually enjoying things right now. Sure things are changing, sure the targets are different… but when it comes to solving a problem I think the solutions these days are fairly reasonable. When you look at the tools that have come about they all address a certain deficiency in the chain. I suppose you can hyper analyze everything and say bad things about everything, but I really do think it’s easy to build something useful on the web without too much effort. My boss was asking me just the other day why we’re able to build and prototype things so much more quickly. The answer was simple, “Five years ago those things just didn’t exist!”

                1. 2

                  So the reason we have so many languages on the backend is because as developers we have 100% control over the backend. We own the server-side so we have luxury of doing what ever we want on that domain.

                  We don’t own the client-side, Microsoft/Google/Opera/Apple/KDE/etc own the client-side. So imagine if we had this plethora of client side languages that varied between each browser/system vendor and each had their own different implementation quirks? We’d end up screaming out for a common language between all the browsers, we’d end up screaming out for Javascript. Sure it may be dirty and quirky but I love Javascript because it’s the standard open client side language.

                  1. 4

                    We wouldn’t have different interpretations of languages if we had a common VM. Browser vendors wouldn’t interpret the different languages; only the intermediate format. Similar to the JVM and CLR; these seem to work well.

                    (Though I don’t underestimate the effort involved in this, even before you consider having multiple companies involved!)

                    1. 1

                      So we’d have to standardise on the intermediate language for the VMs? I think you’d see the similar situation that currently plagues Mono, it’s playing catch up to Microsoft’s CLR. Imagine if we had Microsoft/Apple/Google on different levels of the VM implementation?

                      1. 3

                        So what? We have Microsoft/Apple/Google on different levels of JavaScript implementations currently, too. Having a VM would improve a lot of things, while making existing things not worse than they are.

                        1. 3

                          This is no different to JavaScript; but at least with a dedicated VM, it’s decoupled from the language, so it wouldn’t need to change every time someone wanted a new feature; it would become stable! :)

                          1. 1

                            Excellent point, I think I got carried away. I agree a VM approach would be an excellent solution, I’m just concerned with a cross platform VM that isn’t controlled by one company.

                    2. 1

                      The client side bits remind me of Java applets and liveconnect. Like if you compiled any language into java bytecode and just made it interface with the DOM/BOM through plumbing. That’s a “common” VM and intermediate format.

                      I think the problem with the argument (and not to pick on the author… it’s a broadly discussed topic) is that implementers would have their own versions of this common vm. Their own versions of this plumbing. “Write once, run anywhere” fell short of its vision partly because of so many implementation differences.

                      If the big thing is to get typing into the client, or not depending on what makes sense for your app maybe the thing is to get a future version of javascript to have typing, or not. Kinda like strict or not… albeit with a much huger dev push behind it to pull it off.

                      1. 1

                        It’s not just about typing; it’s also about choice and sharing code.

                        Choice: On the server we have choices, and people pick different languages - there are merits to them all, whether they’re technical, based on familiarity, or even just available libraries.

                        Sharing: Often we have to repeat logic in both the client and on the server. If our server is running language X, why must we re-implement that logic in JavaScript, or worse still, send the data back to the server for processing?

                        I don’t think different VM implementations would be a big problem. Mono seems to be doing pretty well; and you never know, people might share code (until recently, Chrome used WebKit for rendering)!

                      2. -1

                        If I’m writing a huge app with millions of lines of code and I want something that can be safely type-checked and refactored, it’s tough.

                        I should be able to pick my programming language

                        It’s interesting that “web” development is considered by default to be limited to web browsers. If you don’t want to write javascript and have the resources to invest writing your application in another language, go for it. There is plenty of choice and cross-platform frameworks if you really need everything abstracted away. It’s annoying that people try to write applications with a document viewer at all; if your needs are that demanding in the first place, you probably shouldn’t have started with a web browser. If you’re using the web browser as it is, a document viewer, there shouldn’t be much code in the first place.

                        Javascript is a great DOM manipulation language. Growing from LISP-like roots, the functional workings of the language is very fitting for what web browsers need from a scripting language. Most complaints about javascript are either situated around confusing functionality brought upon implementations by a growing spec (this is definitely a problem and it happens with many languages) or they’re situated around the fact that javascript (a weakly typed, dynamic, functional language) is difficult to write large applications with because it’s (surprise!) weakly typed. This could be a benefit if developers stopped bastardizing the language with absurd use-cases and they’d stop crying about it being difficult to manage on their blog, too.

                        1. 2

                          Growing from LISP-like roots, the functional workings of the language

                          So. Much. Wrong.

                          1. 1

                            How? Despite not being homoiconic, it’s simple, imperative, and is the only truly mainstream untyped lambda calc language other than lisp. As Douglas Crockford once said:

                            Deep down, JavaScript has more in common with Lisp and Scheme than with Java. It is Lisp in C’s clothing. This makes JavaScript is remarkably powerful language.

                            1. 6

                              I get the feeling Douglas Crockford says that in order to feel good about the fact that he’s sunk a lot of time and effort into JS.

                              1. 2

                                Arguably, homoiconicity is the whole point of a Lisp. JavaScript has more or less nothing in common with CL, still less so with Scheme.