1. 29

  2. 10

    Or you might just use for example a ClojureScript wrapper for React, which simplifies usage quite a bit (taking advantage of the immutable persistent data structures for automatic and efficient diffing), enjoy all the benefits of Google Closure, have a single build tool (for back & frontend if you use Clojure on the server side), and be done.

    Honestly though, I’m not sure if it’s a great idea to advocate for vanilla JS. Sure, if all you want to do is register some click handler to send an XHR or make the background change color based on the time of day – basically the little bits of interactivity JS was initially designed for – then go ahead and use the bare minimum of what’s necessary. But if you’re planning to do a slightly more complicated “web app” I’d say there’s a reason why all those technologies exist and more often than not you add a feature here, expand something there, and find that your application has grown beyond its initial scope (OK, the proper thing to do would probably be to do a complete rewrite using what you’ve learned thus far, but that’s seldom what gets actually done).

    1. 6

      This is exactly what we’re doing, and my experience is that the apparent complexity as a dev working in cljs/om is far less than using ad-hoc jquery on top of some arbitrary templating language like erb or haml. We have a full fledged, well-designed application for our frontend, and the only language I write is clojure(script).

    2. 11

      JavaScript development today: abstraction abstraction abstraction, devops, component-based development

      1. 5

        Another post about the complexity of the JavaScript ecosystem. How worthwhile is this now, since it’s been said so vocally so many times before? The reality is that yes, the JavaScript ecosystem has a lot going on. And the article makes a solid point that many projects are front-loading complexity in a way that’s unlikely to be worthwhile. In general, a think a rule of doing one or two new things (new language, new framework or major library) in a given project is a good way to go. Not because what’s new is bad, but because there’s an inherent complexity to picking up new things. In the JavaScript world, you don’t have to go whole hog and pick up a bunch of new hot libraries at the same time in one project. Start by doing it how you’ve done it before, and then try out the new stuff as needed.

        In essence, don’t go crazy. The rules for writing good, stable, quality projects are the same as ever. Don’t go chasing shiny things just because they’re there, and don’t feel like you have to be on the latest and greatest. You’ll get there eventually, and with a lot more of your sanity intact, if you take it slow.

        1. 32

          Boiling water is also easy to get into if you take it slow. I personally value these articles, delight in them, treasure each one, and lovingly caress them on my screen when I see them. Why? Two reasons.

          First, in the hope that maybe this one, THIS article is the one that makes the language go away.

          Second, every time someone realizes that JavaScript is the programmatic equivalent of Guy Fieri with a cold, drunk on moscato in an Olive Garden, and that the current state of front end development has fascinatingly arrived at a global minima, I get a delightful little frisson of both schadenfreude and that feeling when you finally see the dog catch the frisbee.

          1. 12

            Chides the author for beating the dead horse, then joins the author.

            1. 3

              Yup. Guess I did. Sorry about that!

          2. 3

            I don’t think it’s that bad, really, but maybe that’s because I am in JS dev every day. A lot of stuff comes out that is new and hot, like react (and angular, jquery, prototype, etc) and it takes a bit to determine if it’s worthwhile investing in it or not. You can’t possibly learn every new lib or framework that comes out, but it’s pretty easy to give them a once-over and see if it sounds useful or not.

            Right now I’m using mithril for the SPA aspects of it and plain express for the backend. A couple grunt tasks for using require on the front end (which is not necessary, but I think it’s cleaner to write/use) and compiling/minifying, and it’s all good. Mithril doesn’t have a huge ecosystem to learn, though. I chose it for that reason. Anyone who has coding experience can look at the mithril API and code and figure it all out within a few hours.

            There is a ton of web stuff (not just JS) out there and it’s all kind of daunting if you’re not in the thick of it.

            1. 2

              I know I’m not saying anything new here, but: I’m in the thick of it (and writing JS every day), and gosh, do I find it daunting.

              1. 1

                To be honest, I just ignore most of the new stuff as it comes out and wait until I hear about things for more than, say, 6 months, before I start to take it seriously. That might hurt someone straight out of college (“you’re out of the loop!”), but realistically, most places uses some either angular, backbone, or react for their js stuff.

                As far as build tools, they’re really optional. I see a ton of articles saying this is the way to do things! But I don’t believe in that stuff. Different people, different teams, different companies have different needs. If you can figure out how to use something like grunt/gulp and just add in plugins slowly, you’ll be fine. There are tons of plugins available, but it doesn’t mean you have to use them (or even know of them until you search for something you need).

                I think there’s a culture within the coding community that expects one person to know everything and if they don’t, they’re automatically an idiot/inferior/not worth working with. That’s not reality, though.