I Was Wrong About JavaScript and Responsive Design

Earlier this year I wrote a blog post about JavaScript and why I thought it was doomed; I also wrote a blog post about responsive design and why I thought it was a waste of time.

To be fair, I didn’t completely bash either technology, but I also didn’t have very many kind words to say about JavaScript or responsive design either.

It turns out that shortly after writing those articles, I found myself, ironically, working much more with JavaScript and having to use websites from my mobile device that were not created with responsive design techniques.

I consider myself to be pretty open-minded, especially when it comes to technology, but in both of these cases, I was being a bit narrow-minded and I think it is important to be willing to admit when you are wrong.

Man made a mistake

First let’s talk about JavaScript

Dear JavaScript, I’m sorry I said that you were ugly and that you would die soon.  I realize that you might not be the most attractive programming language ever created, but like troll dolls or the furby, you have a special kind of beauty that I’ve since learned to appreciate.  And, as for predicting your death, well, it does seem that you are still in the prime of your life, and while everything eventually dies, even programming languages, it isn’t nice to remind people of their mortality.  So, for both of those offenses, I am truly sorry.

On a more serious note, it seems that pretty soon after writing up that article I ended up creating several Pluralsight courses in which I was doing quite a bit of JavaScript development.

By doing this, I actually discovered that the ubiquity of JavaScript was actually very valuable and that it wasn’t as hard as I imagined to create fairly complex JavaScript based applications.

Let me explain a bit further.

After having created several applications using several different platforms and technologies with JavaScript, it became clear to me that the language itself was very flexible and JavaScript’s ability to easily treat data like code, through the use of JSON, was very useful.

At first, when I was just creating web applications with JavaScript, using it as a scripting language to do UI automation, this flexibility seemed to get in the way and make things more complicated than I liked.  I still think that JavaScript can be quite messy in a traditional web application that posts back to the server.

But, when I started using JavaScript to create Chrome plugins, and develop Single Page Applications, this flexibility became extremely useful, because I could basically create exactly what I wanted without a bunch of ceremony around it.  I started to see JavaScript as something I could use to build a more specific API that was specific to the problem domain I was solving.  I also saw that in many cases, for example Meteor, someone else was already doing this for me and I could just follow the conventions they laid out.

I still think there are some things about JavaScript that need to be improved.  But, overall, I have learned to stick to the good parts as much as possible. More importantly, I have learned that knowing the core concepts of JavaScript and programming with JavaScript has allowed me to build a good base which I can bring to many different platforms and environments.  Even though different programming environments may define their own conventions for using JavaScript to create an application or extend one, it is relatively easy to adapt to those conventions once you are familiar with some of the core parts of JavaScript that carryover everywhere.

I also have grown to like the prototypical nature of JavaScript and other prototypical languages like Lua.  I’ve always been a big fan of statically typed languages, and I still am, but I can also now appreciate some of the patterns that only a prototypical language allows which can really allow you to do quite a bit with just a little code.

Onto responsive design

I actually had a very enlightening conversation with a gentleman on Twitter, who really helped me take a second look at responsive design and why it was more useful than I thought.

One of the biggest ways that he shifted my thinking about responsive design was by helping me to realize that it isn’t just PC, mobile phone, tablet, but that there were all kinds of forms factors and kinds of devices that a web page should look good and function well on today.

Stacked old faulty mobile phones

It also seems that right after I had written that article that I ended up having to use my phone for doing web based things much more than I had before then.  I quickly became frustrated with websites that did not implement some kind of responsive design and found myself smiling when I happened upon a website that was mobile friendly and altered the UI to make it much easier to use on a phone.

When I thought about it more, it turned out that I was responding instinctively to the fad of responsive design, but not realizing the actual value that was there.  I probably have a tendency to backlash hard against technology trends that seem to be fads or trendy.  Sometimes, I do get a bit overzealous in doing so and don’t realize that even though many people are ignorantly worshipping some new technology or trend, there are many others who are wearing the latest techno-fashion, because it really is good and useful.

By the way, I found this book, to be a good resource for learning about responsive web design, if you are looking to get a bit more understanding of it.

I still don’t think it is healthy or smart to jump all into responsive design without a good reason for doing so or having a good understanding of the value it will bring.  (Responsive design is not for everyone.)  But, I do think responsive design is a good solution and should be implemented in many more cases than what I had originally thought.  I can see a large amount of value in making an existing site responsive, because it can attract more business and make it easier for existing customers to give you money or use your product.

I even find myself wishing that my website was more responsive.  This blog has a default mobile theme, but I am wondering how much mobile traffic I am losing out on, or how many opportunities to convert that traffic to customers to one of my products I am also missing out on, because I am not presenting the information on this blog in the best way I can for a smaller device.

A good lesson

It turns out being wrong about these two technologies was a good lesson for me, because it helped me realize that even though I like to think that I have eliminated most of my technology biases, there are still plenty that exist.

One of the key things that I’ve always said about this blog is that I am not going to stop from saying something because I am not 100% sure of what I am saying.  What I mean by this is that I will give my view to the best of my knowledge, but that view is subject to revision.  There really is no need to hold onto a viewpoint that is wrong, once you realize it is wrong and it is ok to be wrong sometimes.  We all have to be willing to grow and learn along our journey.  If we want to be able to improve, we have to be willing to allow ourselves to be wrong and to be ok with that.

There are so many posts that I have written for this blog that I wouldn’t agree with 100% today and that is because my knowledge and experience is changing.  I really wouldn’t want it any other way.  If I agree 100% with what I wrote about last year or the year before, I would be 100% the same person I was back then, so I wouldn’t be growing and improving.  I’d rather be wrong sometimes and grow than think I am right all the time and stagnate.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."

  • Rama Krushnudu Vadela

    i think you forgetted to mention the book name of responsiv design.

    • jsonmez

      Thanks, fixed

      • Patrice Gahide

        No, it isn’t. Or is it? Am I missing something?

        • jsonmez

          Ok, should be fixed now. I am not sure why it didn’t update the link the first time.

  • Pingback: Dew Drop – December 10, 2013 (#1680) | Morning Dew()

  • Bonyfus Martin

    This is really good. There are people who argue for the sake of proving they are right. I knew you are not one of them. So when you are adding your javascript course in pluralsight? :)

    • jsonmez

      Thanks. I’ve actually got a few courses already that use JavaScript. But, I haven’t done a full JavaScript course yet.

  • Aaron

    As a JS newbie, overwhelmed by the cryptic nature of JS, I first felt validation reading your previous post about why the language is doomed; now I feel some relief in reading this update. Knowing that I’ll have to make my peace with JS, it’s good to know it has its positive sides.

    • jasonm23github

      Our OP was just coming to the realisation, of JS being everywhere. That doesn’t mean it’s a good language, it’s not, it just means you must know it, or you’ll be the one who’s doomed.nnnMeanwhile we can and should hope / work towards something better.nnnAs a stopgap, the numerous transpilers offer a lot of options. (CoffeeScript, PureScript, TypeScript, ClojureScript … etc. etc.) These can all be source mapped, so dev tools debugging with your original source is an option, that works well.nnnBut like I say, if you don’t know raw JS, you are still adrift. You will not* get professional Web Dev work without knowing JS inside out. nnn(* unless you really luck out.)

  • Daniel W Roth

    Excellent, again! One of the things that has kept me from seriously starting a blog is fear of being wrong. I find myself being wrong so often, why put it out there for every one to see? ;) No more delay–you’ll be my inspiration for getting it done.

    • jsonmez

      Awesome, give me the link when you get it up.
      The fear of being wrong is a very common one that prevents developers from creating a blog. I hear it quite a bit. It is just something you have to get over. We are all wrong a good portion of the time. I even find that I don’t always agree with what I wrote the previous week. But, that is what makes us human and it really is how we grow. I have much more respect for a person who is wrong and puts themselves out there than someone who avoids appearances of being wrong at all costs– I’ve found most people do as well.
      Glad you are doing it, excited to see what you write.

  • billtheamerican

    John… I just saw a for each in javascript. You were right. It is a very horrible language. Keep up the good work.

  • Macuser1010010

    Yes, I really love to learn how to use one web page twice. I allways love when a RWD website has disabled the zoom-pinch functionality. I love when touch fuctions like copy’n paste makes the javascriptfilled webpage to jump around in the browser… I love when RWD developers say that the reason is “they do it wrong!”.

  • johnsmartypants

    Nah.. you were absolutely right about it the first time.. It’s an ancient language from 1999 that has ruined the internet and progress due to it’s horrific ways. It’s so bad that you have a gazillion libraries that are trying to fix the fundamental problems with it and that steamrolls into a another pile of shit where you have no idea when you get code from someone what frameworks and libraries they will be using.

    On top of that let’s not even talk about code extendibility, working with javascript in teams and complete lack of coding standard. It’s a wild wild west out there.

    The only thing that’s left to try to make Javascript actually work ok (saying how Javascript is good for mobile stuff is ridiculous) is to try to constantly put bags and bags of money into making browser JS engines like V8, SpiderMonkey and others on mobile like Nitro trying to make it not suck, but this is an equivalent of putting perfume on a turd. After all is said and done, it still smells like a turd.

    I suggest to people to stop wasting time with Javascript out of complacency and start doing real programming with real world languages that are proven and are being used for native application development as that’s what the future holds. Not responsive sites, not web sites or calling it fancy names like “web apps”.. The web is dying because it’s ancient using a 1999 scripting language to write interactivity and functionality while relying on a retarded DOM even though again we have a ton of frameworks like Backbone, Angular and others who are trying to solve this very issue that just make things worse by introducing a bunch of new frameworks for people to learn just to deal with crap technology.

    Web was revolutionary in 2000s, the world and technology is moving on and the web and everything that was used before JS/CSS/HTML is ancient and will never be able to keep up with the progress.

    Again, your initial opinion was correct. Javascript is going to eventually die. The reason why it will still be a while is because there’s a ton of stuff that depends on it so we are all stuck with this ridiculous scripting language and all the time sucking, resource wasting affairs we have to put up with it.

    The faster we move on and use something else the better it will be for everyone instead of trying to save and “improve” something that was never meant to be what everyone wants it to be.

    • Gaius

      I wonder what happens here when “Meteor” (one of a million ‘frameworks’) is abandoned?

    • aaron

      Whether something thrives or dies in the wild has little to do with whether it is a logically suitable choice

    • Sven Slootweg

      Except modern Javascript has little to nothing to do with Javascript in 1999. Perhaps you should have a go at it again, because your knowledge seems to be pretty outdated.

    • SWR

      ‘Javascript is going to die’. Not in our lifetimes… lol You’re a fucking moron.

  • William Hoblitzell

    My 2 cents: You had it right the first time. JS is an ugly duckling. It is not designed for server-side programming. JS’s notion of “objects” is an absolute joke. Node.js, years later, has now proven to be just one more in a long-line of flavor of the month script kiddie stacks.

  • persistentdeveloper

    Hi John,
    I just want to ask your opinion about AngularJS framework whether you are using it or have been attracted with it as Google made it.
    Thanks for your opinion in advance.

    • jsonmez

      I’m a fan on AngularJS. I haven’t used it all that much, but I like the design.

      • SWR

        You’re a fan of AngularJS but preach about how bad Javascript is. Do you even understand the basic fundamentals AngularJS was written on?

  • Charles

    Yeah JS is amazing WHEN YOU ARE THE ONE BUILDING IT….try inheriting a complex JS project built by purely web developers on contract with no understanding of OOP…..everything is implicitly coupled to where I am at the point where I’d walk out of the job if I had the money to do it.nnTakes me 2 minutes to implement telerik’s ASP .NET Rad Scheduler, get it loaded up with data, and have it running and integrated into our site.nnTaken me 5 hours and counting just trying to navigate the spider web that is our front end JS to implement their kendo HTML 5 JS version, because someone decided our web service caller needed to be tightly coupled with god knows what instead of stand alone and/or taking objects/parameters.nnHtml, css, JS are an archaic monstrosity that needs to be deleted and rebuilt from the ground up using proper OOP. Its no different than c++.nnIts not even good for mobile development, Pit PhoneGap vs Native code on Android and Native code always demonstrates high performance.nnIts the comcast of the web development world, except its free. Its simply too embedded to get rid of.nMaybe I am spoiled, I grew up on Java and C#…but then again, I rarely see anyone who wants to go back to doing things like managing memory in c++.n

    • Sven Slootweg

      That sounds like a problem with your developers, not with Javascript. Writing tightly coupled code in *any* language is a terrible idea. Except Javascript is one of the few ecosystems (especially since the introduction of Webpack and Browserify) that actually lets you wrote loosely coupled code easily, with near-zero overhead. Far more nicely than in Java or C#, too.

      As for OOP; Javascript has ‘proper OOP’, it’s just prototypical rather than classical. That it doesn’t use the paradigm you’re used to from other languages, doesn’t automatically make it bad. In fact, with no prior knowledge of either OOP paradigm, prototypical inheritance is *considerably* easier to understand and reason about than classical inheritance.

      As for performance; unless you have the hard metrics to prove that it’s a bottleneck, this is a non-argument. *Of course* a JIT-compiled language is going to be slower than a precompiled language, that’s the nature of the beast. But for 99% of real-world applications, this doesn’t matter. Performance is only a concern once you’ve gotten security and code quality/maintainability down.

      The one point I can agree on is that CSS is horrible. Unfortunately that’s not something that’s likely to be resolved any time soon – non-Turing-complete languages are generally *extremely* hard to deprecate, because it’s hard to implement a smooth migration/backwards-compatibility path while still getting rid of the technical cruft.

      • Charles

        “that actually lets you wrote loosely coupled code easily, with near-zero overhead.”

        Except when you need to maintain it…..I am currently working on a project with the FE team using JSS/HTML. It isn’t even out out beta yet and they have had to rewrite 250k lines of code.
        That shouldn’t happen in 2015.

        That “loosely coupled code” you can easily understand creates nothing BUT overhead when attempting to change or maintain things. Loosely coupled isn’t a good thing when its done wrong.

        “As for OOP; Javascript has ‘proper OOP’, it’s just prototypical rather than classical.”

        Riiiight…so “Its like OOP! but its not oop….” How far did you have dig for that one?

        “As for performance; unless you have the hard metrics to prove that it’s a bottleneck, this is a non-argument. ”

        “But for 99% of real-world applications, this doesn’t matter.”

        Demands hard metrics…..then throws that requirement out the window when making own claim…..Nice, I applaud your hypocrisy.

        I don’t think you are an actual developer, I think you are one of those people that decided you wanted to program, picked up JS and started coding away without care about standards, best practices, etc.

        You basically sound like one of the people I have to clean up after.

        Well, thanks for enabling my job with your crap code I suppose.
        Bottom line though, JS is a great language when properly maintained and used…but in reality, that doesn’t happen because its not even type-safe, and has very loose standards.

        Its like C++ for the web.

        • Sven Slootweg

          “Except when you need to maintain it…..I am currently working on a project with the FE team using JSS/HTML. It isn’t even out out beta yet and they have had to rewrite 250k lines of code.”

          That sounds like entirely too many lines of code, and I’d wager that it isn’t modularized correctly. Again, blame the developers, not the language. I’m fairly sure that I could poke a lot of holes in the code quality there in a code review (which, by the way, I do professionally).

          There certainly aren’t any indications that you’re looking at a quality codebase, and I’m unsure why this leads you to believe that the language must be at fault, other than confirmation bias.

          “Riiiight…so “Its like OOP! but its not oop….” How far did you have dig for that one?”

          No, it’s OOP. There is nothing that says ‘real’ OOP must be classically inherited. There are different OOP paradigms, prototypical and classical are two of them. Honestly, your response makes me feel you don’t really understand what OOP means to begin with.

          “Demands hard metrics…..then throws that requirement out the window when making own claim…..Nice, I applaud your hypocrisy.”

          No, I’m not “throwing that requirement out of the window” – I’ve developed and looked at plenty of projects, and their corresponding profiling data – 99% seems about right from that data. This is confirmed by the hard numbers I’ve seen from others, and by a lack of hard numbers showing otherwise.

          But feel free to link me some metrics that show otherwise.

          As for the rest of your rant: maybe you should take a step back, and try to *understand* the language you’re complaining about. Most of your argument seems to be “it’s not like the languages I’m used to”, which really isn’t a good metric for the quality of a language.

          I’ve tried to give you a reasonable response in the hopes that you might learn something from it, but if your only interest lies in throwing shit at others like it’s kindergarten at any cost, then my part of the discussion here is done. I’m not going to waste time on trying to explain things to you if you’re not going to take it seriously anyway.

          I can explain it to you, but I can’t understand it for you.

          • Charles

            Loose languages that don’t actively discourage or allow bad behavior share the blame.

            It’s the reason on Java got rid of goto, it let people create spaghettis code.

            It’s not modularized correctly because you don’t need a basic
            understanding of programming to use jscript. It’s so loose you can get away with tons of nonsense. It enables bad developers to exist.

            Your anecdotal evidence of personal experience is garbage and gives you NO foundation to demand hard numbers while refusing to provide your own. That is the epitome of a double standard.

            I understand the language just fine, I’m just willing to give it honest criticism instead of getting a hard on and fanboying it up with that pathetic excuse of logic you are running on.

            The fact you think I should learn something from your response rather than treating those who disagree with as people with valid opinions further demonstrates the ego you have going on. You haven’t given the idea that you could be wrong a second thought.

            As far as reason goes? Reason died when you setup a double standard of demanding hard numbers and then denying you have to provide your own.

            People like you are the reason mainframe still exists with lunatics praising it.

          • SWR

            Hey Charles, let me know when you got an alternative to Javascript ready for all the browsers to implement.

          • Charles

            Just google “google dart”, link is waiting to be approved by mod.

  • humpity

    It’s not javascript. It’s the way it is used. Like this site, about 50 other references to scripts of other sites is bogging down my cpu. (WSJ is another horrendous site).nn ‘Responsive Design’ is just another excuse and exploit by academics for what is really just common sense.

  • Clinton

    As long as browser makers keep making browsers with Javascript as the only legitimate option for manipulating the DOM, the anal buttery goodness that is Javascript—as hideous and miserable and foul as it is—won’t be able to die.

    In my opinion, Javascript needs to be put out of its misery and suffer a full-stack death.

    • Clint Nash

      “Those who say no – don’t know” – JShaters are wrong and misinformation is rampant.

      • Clinton

        Hello, Clint. I do not mean any offense, especially since programming language preferences are largely subjective. In other words, I am not belittling your point of view. I’m just pointing out a handful of Javascript’s myriad flaws in order to back up my previous point of view.

        With that in mind, I’ve been programming in Javascript, out of necessity, not choice, since the 1990s. Based on my personal experiences, I think it sucks. Why?

        1. Hoisting.
        2. CamelCaseIsHardToRead.
        3. No string interpolation.
        4. Scripts are executed in a single, global namespace that is accessible via the “window” object in browsers.
        5. Because there is no string interpolation, and since ‘+’ is overloaded for both string concatenation and addition, stupid type-based bugs are easy to create in Javascript.
        6. Prototype-based inheritance in current releases of Javascript are retarded in that public methods cannot access private fields. Why convert a function to a method if it doesn’t have access to private fields?
        7. People misuse Javascript objects as hashes because Javascript doesn’t have a real hash or dictionary type.
        8. typeof NaN === “number” equals true.
        9. ‘this’ is ambiguous in Javascript.
        10. Switch fall-through is a poor design choice, just as it was in C.
        11. You cannot inherit from builtin objects.
        12. Prototype syntax is awkward and cumbersome. It feels like an kludgy afterthought rather than a well-designed feature. Indeed, many language features feel that way.
        13. Javascript’s Prototype system is not as flexible as it should be. Things that are easy to model in other languages are difficult and sometimes impossible to model effectively in Javascript.

        I can go on…

        While some issues with Javascript have been fixed in ES6, many have not.

        Out of curiosity, what other languages do you know and use on a daily basis? I wonder if Javascript apologists only know Javascript, so they have no idea how bad the language really is compared to other offerings? There’s nothing wrong with that, if it is indeed true. Just imagine all the surprise and delight they’ll find once they break out of the Javascript bubble.

  • http://www.davidfindlay.com.au David Findlay

    Compared to other languages Javascript is horrifying ugly.

    • http://ExpressiveComputing.com/ Matthew Harris

      Guess it just depends on which languages you compare it to. Compared to ASM, or FORTRAN, or PASCAL. JavaScript isn’t so bad.

  • Antonio Brandao

    Would be great if we could just use AS3 for the web, it was the best ECMA Script out there. Remove JavaScript, hello AS3, goodbye DOM.

  • Clinton

    Yes, as I mentioned, some of the issues have been fixed in ES6. Still, as you pointed out, many issues have not.

    Regarding Javascript’s camel casing, I personally find thisIsAVariableName to be a cluttered mess. this_is_a_variable_name is much, much easier to read.

    Regarding #13, implementing private variables is Javascript is clunky. Unless it has changed recently, you have to kludge the functionality together with closures. Effective multiple inheritance is also an issue, in my opinion. I don’t have time to explain the complicated example I was thinking of when I wrote my previous comment. When I do, I’ll post it somewhere for you and provide a link.

    I agree, Coffeescript fixes some of the dumbness of Javascript.

    I also agree that Javascript is much better today that in was 15 years ago. ES6 makes even more improvements. However, as we’ve both pointed out, Javascript still has a lot of warts that just don’t exist in many other languages. In my opinion, if browser makers fixed the mess that is the DOM and added support for other languages into the browsers, Javascript would quickly lose a lot of developers.

    • Sven Slootweg

      I’m certainly not arguing that Javascript is flawless. I’m simply arguing that it has less cruft/issues than basically any other major language currently in use – from the bad options, it’s the least bad.

      “Private variables” as a technical measure are really not a desirable thing to begin with; you shouldn’t need to forcibly hide a variable. The only way this is useful is as a convention, in which case prefixing with an underscore (as is common in JS), is more than enough.

      There’s not really a problem here – the thing you consider ‘kludgy’ is a thing you shouldn’t be doing and don’t need to begin with.

      I doubt that JS would ‘quickly lose a lot of developers’ if browsers adopted more languages. This was tried with VBScript, and it lost. There are now browser-compatible runtimes for other languages (eg. Python), and these have not caught on either. In the meantime, Node.js usage keeps growing.

      There are many attractive points to modern JS; a very readable, small and flexible language core, memory-safe, a very good package management and module system (no version conflicts, ever!), an extremely rigorously versioned modular ecosystem (using semantic versioning), with an average code quality that is considerably better than in most other languages, and great documentation for almost everything.

      There are currently no other languages or ecosystems that can provide this set of advantages, combined, that I know of.

      • Clinton

        Private variables are indeed necessary to implement certain class structures and also to maintain the integrity of your class in a multi-threaded environment. You don’t want something else in the program to access private variables and methods and change things out from under you. The reason this isn’t as big of an issue in Javascript is that Javascript runs in a single thread (which I also see as problematic, at least on the server side).

        Private variables and methods are also necessary when creating class structures that can accept a wide variety of inputs without resorting to a bunch of type checking, conditionals, and error handling. The result is clean, maintainable, and extremely solid code. Javascript’s prototype system can’t really do that effectively (if at all), so if Javascript is your language of choice, I can understand why you wouldn’t miss it. For me, however, it is an important feature to give up.

        I would hardly call VBScript competition. For one, it wasn’t ubiquitous. For two, it sucked. Coffeescript is a better indicator. A lot of people use Coffeescript instead of Javascript because, lets face it, Javascript is ugly and not very fun to code in. If Coffeescript were supported natively in the browsers, Javascript would lose a lot of marketshare to it. Opal is another popular alternative to writing native Javascript.

        Yes, Javascript has a very small and flexible language core, but it also lacks a lot of features that other programming languages have (like string interpolation). I personally think packaging tools like Pip, Mix, Gem, and Bundler are equivalent to things like NPM. I also like that they don’t pollute your project directory with 3rd-party libraries that can potentially clutter up your repository and deployment. I know you can do npm install -g for everything, but nobody does that. Don’t get me wrong, I think tools like npm, nvm, webpack, grunt, and so on are good tools, but they all have counterparts in other languages that are at least equally good.

        In my experience (C, C++, Smalltalk, C#, Java, Python, Ruby, Lisp, Clojure, Elixir, Javascript, etc.), the Ruby community has been the most helpful and has produced the best community and collection of documentation. Elixir, having taken a page from Ruby, also does quite well. The C# community/documentation was the worst, in my experience. Javascript’s is pretty good, but because it has such a low barrier to entry, there are a lot of cut and paste scripters out there that pollute online forums with trashy code and advise.

        The best codebase I’ve seen is Elixir. It is quite elegant.

        Another problem I have with server-side Javascript is scalability. With languages like Elixir, I can write a server-side app that can not only scale to all the cores on my server, but all the servers in my datacenter, and all the datacenters my company has access too. Elixir’s immutable, functional programming style eliminates most of the issues around multi-threaded programming, and its actor model provides a far more robust, faster, and resilient environment. It’s truly amazing, not to mention fun.

        I know you guys want to convince me that Javascript is the bee’s bonnet, but it just isn’t. There are far more elegant and robust languages out there.

  • Clinton

    Regarding generators, that’s kind of my point, Clint (at least one of them). Generators have been around in other languages for, well, ever. Javascript is playing catch-up to support things that the rest of us have been doing for our entire careers, and while Javascript is implementing generators, the rest of us are jumping into even more interesting things.

    WebAssembly is indeed interesting. It will be fun to see how it plays out.

    I’m not saying Javascript is utter crap. It isn’t. However, it just isn’t on par with many other languages that are popular today. I can’t pretend it is.

    • Clint Nash

      Cool. The reverse is true of lambdas… right?

      We are in an evolving system.

      Nice discussing this with you.

      • Clinton

        Hi Clint,

        No, Python and Ruby, for example, have had lambdas forever.

        Sorry this turned into a “my language is better than yours” discussion. That wasn’t my intent. I actually do like things like Node.js and React, and I do recognize the vast improvements to Javascript over the years. Javascript simply isn’t my favorite language for a variety of reasons (from syntax to missing features, etc.) The great thing about free software though is there are plenty of languages to scratch all kinds of itches. I’m glad you’ve found a language that satisfies yours.