TC39 proposals which make me excited about JavaScript

As someone who geeks out about new features in HTML and CSS I have to say that there are interesting things coming our way in JavaScript, plain old Vanilla JavaScript.

Pattern matching

This Stage 1 proposal is authored by Kat Marchán from npm. My reason to be excited about this proposal the most are my previous experiences with Scala where pattern matching is implemented and is the one feature I think every language should have.

Pattern matching for illustration will make everyone’s life easier when one needs to parse a response from the back-end. So instead of series of  if s:

One has to use only one switch1:

Private fields, private methods and decorators

This group of proposals is scattered at at least four separate proposals:

Private designation

At first I must admit that I was against using private variables and private methods inside objects because it didn’t feel JavaScript-y. (Un)fortunately there are other developers who come to JavaScript world from languages which use private, public and sometimes protected designations, ehm, Java. Since they are used to working with a bit different object model and how somethings affect others, they’ve introduced an ad-hoc version of private and public methods which works only among those who follow the rules.

With private designation this practice will become standard and hopefully I’ll stop seeing functions and variables that start with _ . Hating on underscore character is my current petty pet peeve.

The way how it’s supposed to work in order not to introduce too many new things and thus breaking old code is by prefixing variable’s name instead of using a keyword:

For non-JavaScript developers it may be confusing to not use a keyword but one has to remember there are tons of JavaScript code. People writing the proposals are aware that some developers may have used a variable or method called “private” and “public” in their code and that code may still be running2.

Private methods work similarly to private variables:

Decorators

Decorators are a thing which I strongly dislike in Java because they aren’t part of the language itself but part of third party libraries such as Lombok. To me decorators are/should be a core feature of a language, so I am much more comfortable with the way JavaScript plans on handling them.3

At the moment there are three defined decorators, all of the are used around custom elements.

My favorite is  @defineElement which makes creating a new custom element a bit shorter and it’ll make code more readable because at the moment we have to define a custom element at one place and active it at another:

Instead with decorator

My second favorite decorator is  @observed which does basically the same thing as AngularJS’  $scope.$watch('variableName', function() {}). For those unfamiliar with AngularJS, it means that within the scope there’s a variable called variableName and when that variable changes, something happens.

The difference is that  @observed watches a variable that’s defined after the decorator, @observed myVar = 1, and when that variable is changed a render function is called on that component.

The third decorator, @bound , is supposed to replace using bind() function. Unfortunately at this point in time I am a bit skeptical about and would need to see it used somewhere for it to make more sense to me.

Pipeline operator

Pipeline operator is something which JavaScript needs and needed since chaining functions in jQuery. In it’s basic function helps readability of the code. From this:

We get this:

It may not look like a lot in this simple example but when one has to chain a few functions together it helps.

Currently there are two competing proposal for pipeline operator. One is takes inspiration from F#, OCaml, Elm, Julia and other languages and UNIX pipes and the other take a new look at how pipelines could work. My personal preference is to use the former because that’s something I am already familiar with but I’ll watch the space in case some interesting use can take better advantage of the latter.

  1. My preferred version but in the proposal is at the moment case…when
  2. At the moment I work on one project with JavaScript code from early 2000s
  3. This is also a reason for my preference of Vue over Angular.