By Nilson Jacques

Modern JavaScript Development Is Hard

By Nilson Jacques

It’s not uncommon these days to see people complaining about just how complex JavaScript development seems to have become. I can have some sympathy with that view when it’s coming from someone new to the language.

If you’re learning JS, it won’t take long for you to be exposed to the enormity of the ecosystem and the sheer number of moving pieces you need to understand (at least conceptually) to build a modern web application.

Package management, linting, transpilation, module bundling, minification, source maps, frameworks, unit testing, hot reloading… it can’t be denied that this is a lot more complex that just including a couple script tags in your page and FTPing it up to the server.

Some people who have been involved with web development for years are still pining for those ‘good old days’, and it’s this kind of complaining that I have much less sympathy for. One such comment I read this last week claimed that web development had been hijacked by those who enjoy using the command line and writing JSON config files.

For a long time, JavaScript was looked upon by many as a joke; a toy language whose only real use was to add non-essential eye-candy, such as mouseover changes, and was often a source of weird errors and broken pages. The language is still not taken seriously by some today, despite having made much progress since those early days. It’s not hard to have some sympathy with PHP developers.

For better or for worse, JavaScript was (and still is) the only language supported natively by the vast majority of web browsers. The community has worked hard to improve the language itself, and to provide the tooling to help build production-grade apps. I find it ironic that now people attack JavaScript development for being “too complicated”. Unfortunately, you just can’t have it both ways.

JavaScript developers are now some of the most in-demand (and well compensated) in the industry. Is there any reason to think that it should be ‘easy’? Try talking to a Java or a .NET developer; both these technologies have large ecosystems and build tooling setups for developing production-quality apps. And as for config files, many Java tools have XML files coming out of their… ears.

A lot of JavaScript tutorials often include things like module bundling and transpilation, because writing modular code with the latest language features are skills that are in demand in the job market. They are the necessary pieces for building large, complex applications in a team environment. Keep in mind that a lot of these build tools and development techniques are entirely optional. No one is forcing you to use them for your projects. Like all tools, they are a trade-off: they solve specific problems, at the cost of increasing your project’s complexity (in one form or another). Nothing is stopping you writing plain old ES5 JavaScript files and linking them to your HTML with script tags. You can even pull in frameworks like React and Vue from CDNs if you want to.

Are you happy with JavaScript’s evolution, or has modern web development taken all the joy out of coding for you? I’d be very interested to hear your thoughts on this, so please let me know in the comments or on Twitter.

PS. If you are new to JavaScript development or are coming back to the language after an extended break, be sure to check back tomorrow for our guide to the anatomy of a modern JavaScript application!

  • johnbrowe

    Totally agree, users demand good UX which in most cases means complex JS.

  • It’s not the pervasive and widespread adoption of JavaScript as language that’s frustrated me. In my opinion, it’s all of these new libraries that keep coming down claiming to be the best thing since sliced bread. And not in one instance have I observed anyone really say: “If you’re looking to do “A” then go with AngularJS, but if “B” then you should really consider going with server-side “Node.js”. And on and on it goes, ad nauseum. And by the way, I’ve been a programmer for almost 17 years and I don’t recall once complaining about JavaScript being “too hard.”

    I’m a happy (mostly) .NET developer for the past nine or so of my nearly two decades. I’ve also programmed in Java and PHP and Python…. and I’ve dabbled in Ruby. Again, the frustration comes about with what do you learn because what’s hot today doesn’t seem to be hot next year or even next month. Not to mention you have employers these days with completely unrealistic expectations on what you are REQUIRED to know, and if you don’t know it you’re frowned upon as somehow less than a modern professional or even competent programmer. The JS pundits really need to stop the hatin. Not that this is the fault of any of these JavaScript libraries or those who created them. But it does leave me feeling like I’m trying to navigate my way through one after another of “bad startups”. By my count, we aren’t going to get left behind we already have been in a lot of respects.

    Most frustrating is in all of these new 10 billion tomes on JavaScript at an easy 300 pages each (present SitePoint authors excepted), you don’t really see many out there saying: “Oh, you have an existing mammoth .NET or HTML project or otherwise talking with SQL Server (mostly) and maybe some hooks off on a Python/PostgreSQL or MongoDB API? Well here’s how to clearly and concisely integrate AngularJS, Vue, Elm, or any of the others into your project and use it in a REAL way with tangible results. Not every project that could benefit from JavaScript is a new project speaking “Hello, World” to tens of thousands of users.

    While your article is sound about the state of JavaScript today, I have to fundamentally disagree with your premise about we old timers not loving JavaScript. If you’re in any doubt, look at the reception of jQuery. It’s the sheer volume of tools being thrown at us today and being commanded to “learn it all” if you want any respect that makes me grind my teeth and throw up my hands.

    • IMHO, never use Angular… ;-) I prefer React + single-state tree (redux or similar). As to when to use the server, if you can have node on the server, you can get fairly tight coupling and cross-environment support between browser and server cleanly. As to refactoring existing projects, I feel your pain…

      For me, with .Net projects, usually first establish that all devs must have a dev setup of the current version of node installed… then, I’ll add a package.json to every web project that gets published, and an npm install script (that gets run with my project prebuild) and an `npm run build` that gets run as a postbuild script. This way, it just works… Then I’ll go about creating minified versions of existing scripts, or other configuration steps, usually avoiding anything sweeping on a first pass… Then I’ll work towards setting up webpack bundles, and getting the primary scripts lines up out of NPM instead of whatever mishmash of script libraries there are… usually just a base.js that will import/require all the main library modules… then replace all references, this will often clean up 2-3 versions of jquery and the like… I’ll also setup window.* globals as needed by jquery/bootstrap/etc. From there, I’ll start refactoring section/page.js files and try to make them more modern and using modules… this takes a while, but at the end most pages only include 2-3 scripts… there’s 1 for the site with all the common modules… 1 for each layout/masterpage used for sections of the site, and 1 for each page/component that is specifically bound… outward from there, new development can be done with modern syntax and pages can be refactored much more easily… that’s just my take on it, and I’ve done it a few times now.

      • Very much appreciate not only your reply but the excellent, respectful, and helpful intent by which you delivered it. Thank you!

  • Recently, I started a brand new React project, router v4 was near release, and a few other bits that were new (to me), using Webpack 2 for the first time, and a few other bits… to be honest, it was about as frustrating an experience as I’ve had in bootstrapping a new project. Now, it’s not as frustrating, but it’s really the first time I felt *that* frustrated, so I can feel the pain of a lot of others.

    That said, I would never want to go back to the old days of manually bundling, or using script runners for bundle/reduce… Or doing manual namespacing in JS to avoid collisions in a large project. Modern ES6 (or node/cjs) modules are much cleaner, and you can take my Babel before browsers support all the current stage-2+ features I use from my cold dead fingers. It’ll bee 3-4 years before that really happens. And it will be weird the transition from build/deploy bundling to JS modules from the browser, and HTTP2 server-push. I still prefer the way JS is written today vs any time before.

    I use a lot of async functions, and some ES6 classes (sparingly) where needed. There are a lot of great things in writing modern JS. The flip side is evaluating modules in npm, and keeping up with some of the proliferation without falling into the trap before they’re ready, or likely to take established roots.

  • I do not understand how every time they make the code more ugly !!! Really ES6 is ugly(only in some things), we could do the universal code, but not every crazy with its theme, instead of make it more logical, we complicate it more. But come on that is my personal opinion

  • Donnie D’Amato

    I never wanted it “both ways”, the complaining about the language being a joke came from the people who changed it, not from the people who accepted the way it was then.

    We are absolutely being forced to write differently now. Our jobs have code styles and frameworks embedded and it hard to keep up for some of us.

  • Doron

    JavaScript development is indeed very complicated.
    In fact, JS development is even more complicated than most fields in programming, nowadays.

  • Martin1971

    I do not like the word hard. It immediately gives the new student the impression that the subject matter is inherently difficult. I prefer the word complex which suggests that there are many smaller easier to understand parts that you must fully understand first in order to build complex web applications. Once one understands these smaller less daunting parts of the language then integrating other packages become easier. I think there needs to be a javascript Standards committee who will define exactly what constitutes a framework, package or even an api for javascript.

  • Waheed

    I don’t see that jsor any other languages is difficult my personal opinion is if we have command in JavaScript basic and some advance knowledge in it

    It will definitely help in understanding and working on any framework and library

    The sad part of our industry is ppl are looking for only keywords like angularjs, reactjs etc.

  • Tim Furry

    I think it’s funny that there are more and more articles about JavaScript being too hard. :)

    That being said, I’m one of the old-timey guys who wrote raw JS, wrote my own libraries, and wanted to move to jQuery long before my manager would allow it (for reasons too silly to mention here). Been there, done that, liked it…for 20+ years now.

    JavaScript isn’t hard. It’s all the frigging layers of other stuff that get piled on top of it, and their perceived cool factors (as others have mentioned). Our current project is so complex that none of us know how it all works, and the guys working on the infrastructure are always changing things up so that a week after we write code it’s already stale and not using the latest and greatest widget or whatsit or whatever. We’re locked into Angular 1.x because converting would require manpower we don’t have, so we’re really uncool now.

    Personally, I think a lot of the complexity has been brought in by developers and project managers moving to web from other languages. One doesn’t need a build process to create a complex website (no, Virginia, JavaScript is not compiled). One doesn’t need CSS variables either, or unit tests or all the other stuff that has come along. If you’re careful, you can do it without all that…just not fast. The extra gunk makes it faster to do all the stuff you don’t really need in the first place.

    We used to count every byte that got pushed to the client because it mattered. We used to split up images to fit ethernet packets. We used to write separate code paths for different browsers. It was complicated then too, just in different ways.

  • Louis Gac

    problem is that today JS WebApps look like old 90’s PHP code. It’s like if all the mistakes should be done once again. I just hope that soon JS Frameworks will be as good as Ruby or Symfony or Yii, with clear separation between js functions for logic and the HTML itself in different files, with ORMs, code generation, etc. Because calling “a view” a bunch of unreadable JS functions with some HTML in it is just not acceptable.

  • Thomas Smet

    I never understand why people find Javascript so hard. I didn’t start my career with a background in programming but as an interactive designer I used Macromedia Director and eventually Flash. When Flash started becoming unpopular thanks to Apple I switched to Javascript which I found to be an easy transition from Actionscript. I guess because I have always worked with scripting languages I find it stupid simple to use Javascript. I now use plain Javascript to build extremely complex Cordova mobile apps. I hate frameworks and libraries as I find them to be massive performance hogs and way over complicate something that should be so simple and easy to use. It is the serious developers that keep trying to shoehorn Javascript into something that it isn’t that are making it overly complex. It is the libraries like jQuery that have dumbed down Javascript to the point where now many of its users don’t know what the heck is going on. Simplifying repetitive tasks is fine but people need to learn vanilla Javascript first and then adopt libraries and frameworks as they see fit. Learning a framework first is a recipe for disaster. Thats like trying to teach English to a person with emojis and lol and wtf. Their grasp of the English language would be a messed up Swiss cheese understanding. Thats exactly what is going on with Javascript. We keep trying to introduce new users to the language with completely different emojis and odd ways of presenting the language instead of actually teaching them about the language itself. Javascript is Javascript, plain and simple. Screw Angular, jQuery, Maven and all the other stuff that gets in the way. I can write a near native performing mobile app in Cordova with the canvas and plain Javascript in a fraction of the time it takes for somebody to learn a framework and then try to figure out why the frame rate sucks and blame it on Cordvoa vs native.

  • M⃠ ⃠S⃠ ⃠i⃠ ⃠N⃠ ⃠L⃠u⃠n⃠d⃠

    JS is easy.

    Its the assholes who insist on inventing new syntaxes for it, that are the problem.

    You start to see gobbledygook like %&¤?$!#/, or whatever, and you ask “what language is that?

    JavaScript, grandpa!

    Yeah… %&¤?$!#/ indeed.

    Go %&¤?$!#/ a duck, kid!

  • Constantin Chirila

    Wow, after looking in the comments area Ive only seen useless moaning about these damn frameworks. To make an analogy, its like you are moaning about racing where people keep inventing all these damn different cars, and wondering why isn’t everyone driving one car. And I say, why would you care??? Seriously if 2 people find Angular useful hurray for them, why moan? How does that affect you?
    Writte plain javascript if you dont like frameworks, heck write machine code for what i care, just stop moaning about the ecosystem and look it the way it is, an old language that finally discovered it’s teenage years, and tries everything.
    For goodness sake, stop complaining about people having fun with JS and bending it to their needs, cause that exactly the best part of this weird language! Enjoy it the way YOU want and stop caring about how others are…

    • M⃠ ⃠S⃠ ⃠i⃠ ⃠N⃠ ⃠L⃠u⃠n⃠d⃠

      …except, someone has maintain and update all that crap long after the kids who built stuff with it has moved on to the next worlds coolest framework of the week.

      And we all have to use those bloated slow crappy sites.

      There is a special place in hell for people who make it easier for noobs to cram more animations into websites.

      And the guy who invented is waiting there for them.

      • Constantin Chirila

        Slow crappy website were there 10 years ago too… what’s your point?

        If you are talking about legacy stuff, all languages are plagued with it. And that’s why you need a good CTO, and good company leadership to not trust the noob kiddos to dictate the path of a product. And if you work in the web medium, you do know stuff are no longer build to last right? I am not saying all these frameworks are good, im just saying moaning at it is as pointless as my grandpa moaning about all the damn computers and email and crap…

        Just look all around you, fast iterations are everywhere, phones, computers, etc… it’s competitive out there, and some frameworks are shit, other are pretty awesome, and reinvented the web…

        I really don’t know what you guys want… for Javascript to stay at the stage it was in 2000? :))

        Again stop moaning!.. it’s useless and creates bad blood..

        • M⃠ ⃠S⃠ ⃠i⃠ ⃠N⃠ ⃠L⃠u⃠n⃠d⃠

          Yeah, people should be more like you, and not moan…

  • Todd Zmijewski

    I don’t think the industry as a whole has done a very good job in evolving the Internet. All these crazy complicated brittle front-end technologies are no something I’m proud of passing on. I can use them but I’m not very proud of any of them. In many ways I think some of these people should be ashamed. There has to be a simpler way.

Get the latest in JavaScript, once a week, for free.