Didoo

Modern™ Javascript

In the last months it happened to me, more and more frequently, to hear someone to use the word “Modern” in front of “Javascript”. That’s ok, I don’t have a problem with that (despite the fact that looks like a buzzword in embryo).

My itch with it, hence this blog post, is that every time it happened, the person using it was trying to justify his – debatable – technical choices, with a veil of alleged superiority that assumed those were automatically and indisputably good choices, because… hey, this is the future!

So, dear Modern™ Javascript developer, I get your excitement for all the new specifications and syntax changes.

You prefer the arrow functions to the classic declarations? Great. You prefer to use const and let instead of var because, hey is way cooler? Good. You want to use template literals (“quasis”) despite the fact that so the code becomes more obscure? Fine.

not-impressed2

But to really impress me you have to show me how you organise your code, what naming strategy you are adopting, how you make you codebase more maintainable, how your bundled Javascript file is faster to download and then boostrap, how performant is the processing and rendering inside the browser, how your code supports the progressive enhancement of the pages.

In an “hello world” project – the one you are showing me – things are clean and easy. But I know for sure that things get hard and harder when it comes to “real-world” projects.

Everything in your Modern™ Javascript world is perfect, I get it, but you are building something from scratch, it’s a greenfield project, and so you are just adding feature after feature, file after file, line of code after line of code. You haven’t yet got to the point where you have to maintain a large codebase, refactor/patch/hack it to adapt and bend it to the request of changes and the evolution of the “business needs”.

development3

Where you have tens of different developers working on it, hundred of product “features” implemented, thousands of lines of code. Where you have to make – almost daily – tradeoffs between consistency, technical debt, refactoring, deadlines, delivery. Where the overall complexity of your project is pretty high (beyond the “hello world” phase), as well the risk of chaos and “messiness”.

I’m eager to see what will happen to your Modern™ Javascript in 14 months from now, let’s see if all is still perfectly shining-brand-new, or you will need to throw everything away and start (again) from scratch, this time with a Modern™ 2.0 Javascript.

Because if it’s a matter of throwaway, then it’s easy: everyone can do it, you’re not that special. And it’s not even fair to compare – as you are subtly and implicitly doing – your 2 months old Modern™ Javascript with other Old-school Javascript frameworks, libraries and methodologies, which however have overcome the passing of time.

overcomplicated

I want to see your Modern™ Javascript in ten years on Wayback Machine, and I want to see it in the same way I see the pages of Yahoo.com or Wikipedia.org of ten years ago. Because the one you are showing me is (supposedly) a web page, not a web app.

It’s not a fair comparison, right? Those pages are built with HTML and a sprinkle of CSS, yours are entirely client-side rendered in Modern™ Javascript, and who knows in the future what will happen to the browsers. Well, maybe this means that yours is a.. how to call it… maybe Transient Javascript :)

If you think that your Javascript code is so special that needs a qualification like “modern”, then maybe you are missing a particular trait of the Web: it’s an ecosystem in slow but constant evolution. It’s a continuum, a steady flow towards the future, without sudden breaks or abrupt jumps.

Tell me the year in which we dropped the support to IE6, or we stopped to use tables for layouts, or moved away from iframes in favour of AJAX, or we adopted a mobile-first approach, or we started to use Sass or Grunt, or we introduced the Speed Index as a metric. You can’t right? Nor do I.

So, do not get too excited, there will always be someone more modern than you and me. On the other hand, someone is already bragging around about ES7, right?

 

Update #1: if you can read between the lines of what I wrote above, you will see that this relates a lot with that:

 

Update #2: “That’s the meaning I take from working on the web, as ephemeral as this medium might seem sometimes. When we work harder, we get better at doing things the right way. When we get better at doing things the right way, we build something more important than a website; something that will outlast any of us here.” – Smaller, Faster Websites

Update #3: “ES6 is making JavaScript more complicated to appeal to people who program in more complicated languages and I think this is a terrible decision.” – JavaScript ES6 is Doing Too Much

Go to blog index