Analysis / Technology / Top Stories /

JavaScript 2018: Things You Need To Know, and a Few You Can Skip

3 Jan 2018 3:00am, by

JavaScript has grown up — we are not just making tiny little interactive elements in web pages anymore, we are building entire giant applications in JavaScript. So, of course, it’s more complicated than ever before, with so many more moving pieces that it becomes difficult to grasp the size and scope of the current JavaScript ecosystem.

As both a working software engineer and an author of two JavaScript books for O’Reilly Media, Ethan Brown has spent a lot of time parsing the  JavaScript landscape, trying to make sense of what’s out there and how a modern JavaScript developer might start to fit all those pieces together.

Here are Brown’s prognostications for aspects of the JavaScript Ecosystem that are the most up-and-coming, or at least the most useful, for smart devs to familiarize themselves with in 2018. With two caveats: First, he is pointing to good things to be aware of among all the changes in the JavaScript space, even if some of the items on this list are not your focus. Having that general awareness when you encounter problems that are at the intersection of different areas will help you make connections, know who to talk to and what technologies to look for.

He also stresses that these choices are his own opinion, based on his own experience in the ecosystem, and of course yours may be entirely different. “This is just my opinion, we can all draw our own maps, and I know I’ve left some stuff out,” said Brown.

Still, we’ve got to start somewhere.

WebAssembly: WebAssembly is a subset of JavaScript that provides a compiler target for other languages. So if you want your C++ compiled to JavaScript, WebAssembly is where you would look — it allows just about any language to target the browser or target Node.js, and has some very interesting applications. “I have a feeling this is going to be big, it’s going to be really relevant,” said Brown. “I’m definitely keeping my ears open and spending some time in 2018 learning this better.”

Functional Programming: “Not a new idea, and it’s already been embraced by a significant portion of the  JavaScript community, but I feel like 2018 is going to be the year functional programming really achieves critical mass and scale,” said Brown.  The usual criticism is that it’s harder to learn, harder to understand, he continued, but that this is really a matter of perspective: Had we all started with functional programming, the confusion and side effects and chaos of imperative programming would be what seems weird and difficult to us.

Brown’s recommendation: “If you want to experiment with really constrained functional programming you can look at Elm or ClojureScript, but you can do it in JavaScript today simply by saying, ‘Alright, everything is in my code is going to be pure function.’”

Immutability: Goes hand in hand with functional programming. “Though a lot of people, when they first come to immutability, think ‘Wow, this is really inefficient, you’re creating a copy of everything, all that memory seems very unnecessary’,” said Brown. But keep in mind, he added, you’re only copying the things that change — the other structures stay the same. And also, this is really JavaScript’s thing — identity comparison is fast and it’s cheap in JavaScript, and so when most people switch to an immutability architecture they find it increases performance.

Even better, immutability provides a natural safety net for experimentation — if you know you can’t actually change anything that exists, you can only create a new copy that is modified, this encourages experimentation you might not otherwise feel comfortable with. Which makes it great for beginner programmers as well.

One-Way Data Binding: “This is for the front end folks, an idea brought to the table by Elm, and picked up by Facebook with Flux, and then there was Redux, and now it’s in Angular and in Vue,” said Brown. Increasingly everyone’s realizing this is a great idea, and 2018 is a good time to get acquainted.

One-way data binding does make your application state easier to manage. When you first come to it you think, gosh, this is so much more work, so much more I have to write, it seems like overkill. And it may be overkill for small apps, but once your application reaches a certain size it really does help constrain your thinking to your entire app and not only the part you’re working on. Because when you’re using one-way data binding, you have to think about the state of each piece of your application and where it fits into the application hierarchy.

Computed Property Names/Property Shorthand: “This is the sleeper hit of ECMAScript 6 (ES6). I don’t see people using this very often yet, and I think it could be used so much more. It’s a fantastic little bit of syntactical sugar that allows you to dynamically construct property names and object initializers or object literals,” Brown said. “I feel like every week I find a new cool way to use this. This also works really great with functional programming, so if you haven’t seen this before definitely look it up — I’d definitely like to see more use of it in the community.”

 

Things Not to Worry About:

There are also, according to Brown, some areas of knowledge we can skip. At least for now.

Object-Oriented Programming: “I’m not a huge fan of classical object-oriented programming in JavaScript. I think there are better paradigms, better ways to accomplish things in JavaScript, to accomplish code reuse. So I wouldn’t fret about learning everything there is to know about OOP if you are in  JavaScript land,” he recommended.

Generators: “This is a cool feature of JavaScript, definitely some use cases for it out there, but I think the primary one was obviated by async/await. So for a while, we were really excited to use Koa.js and generators so we could have that nice synchronous semantics with asynchronous programming, but now we have async and await and it’s even better. So unless you’re in one of those weird use cases where generators make sense I wouldn’t worry too much about it,” he said.

Symbol: “Another one that’s a great idea, a fantastic addition to the language, but (A) I don’t see people using it and (B) every time I’ve tried to use symbols I run into nothing but problems with frameworks and serialization,” Brown said. In short, he just doesn’t think the JavaScript ecosystem is really for symbols, and it may even be just not the right language feature fit for the things we are doing with JavaScript. His recommendation: At this point, wait and see on symbols.


A digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.