What to expect from ECMAScript in 2019

Reading Time: 5 minutes

JavaScript as a language has been maturing at a steady pace in the past decade with the evolution of ECMAScript. The current version was released in June 2018, ES2018 and the upcoming version brings several new additions to the language which we’ll cover in this post.

Before that, it can be useful to know how new features are being added to the language through the additions to the ECMAScript standard.

ECMAScript proposals

The Technical Committee 39, TC39, is responsible for reviewing and adopting changes to the existing version of the ECMAScript standard. The process takes the form of 5 stages of maturity after which a new feature is included in the standard.

  • Stage 0: Strawman
  • Stage 1: Proposal
  • Stage 2: Draft
  • Stage 3: Candidate
  • Stage 4: Finished

There is no guarantee that a feature in Stage 3 will be included in the standard, but generally, JavaScript engine implementations like V8 (Chrome, Node.js, Opera), SpiderMonkey (Firefox) and Chakra (Microsoft Edge) tend to add some features with experimental support so that developers can test and provide feedback.

ES2019 finished features

At the time of writing this post, there have been several finished features, you can check the full list in the TC39 proposal repository.

  • Array.prototype.{flat, flatMap}
  • Object.fromEntries()
  • String.prototype.{trimStart, trimEnd}
  • Symbol.prototype.description
  • Subsume JSON
  • Optional catch binding
  • Well-formed JSON.stringify()
  • Function.prototype.toString()

Array.prototype.{flat, flatMap}

The new array instance method, flat(), flattens an array up to a given value, it takes an optional depth argument which can be set to Infinity to run recursively until the array is single dimensional.

const nestedArray = ["a", ["b", "c"], ["d", ["e", ["f"]]]];

// using flat() on a multidimensional array
["a", "b", "c", "d", ["e", ["f"]]]

// using flat() with an argument
["a", "b", "c", "d", "e", ["f"]]

// using flat() with Infinity as argument
["a", "b", "c", "d", "e", "f"]

flatMap() is similar to the existing map() method, but the callback can return an array and the end result will be a single dimensional array instead of nesting arrays.

const scatteredArray = ["a b c", "d", "e f", "g"];

// map() results in nested arrays
scatteredArray.map( chunk => chunk.split(" "));
[["a", "b", "c" ], [ "d" ], [ "e", "f" ], [ "g" ]]

// flatMap() concatenates the returned arrays together
scatteredArray.flatMap( chunk => chunk.split(" "));
["a", "b", "c", "d", "e", "f", "g"]


Objects have an entries() method since ES2017, it returns an array key-value pairs of the object’s properties. The fromEntries() method does the reverse and returns an object from an array of properties.

If we use both methods on an object the cloned object will be copied by reference.

const person = { name: "John", age: 30, country: "UK" }

// using Object.entries and assigning it to a new object
const entries = Object.entries(person)
[["name", "John" ], [ "age", 30 ], [ "country, "UK" ]]

// using the new Object.fromEntries
const newPerson = Object.fromEntries(entries)
{ name: "John", age: 30, country: "UK" }

// the new object is a shallow copy
person !== newPerson

String.prototype.{trimStart, trimEnd}

trimStart() returns a string with removed whitespaces from the start of the original string, while trimEnd() removes whitespaces from the end.

const str = "   blank spaces   ";

// trimStart() usage
"blank spaces   "

// trimEnd() usage
"   blank spaces"


When creating a symbol, you can now retrieve its description property instead of using toString() on the object.

const symbol = Symbol("This is the symbol description")

// retrieving the description property
"This is the symbol description"

Subsume JSON

This proposal solves an issue of inconsistency between a JSON and an ECMAScript JSON, which by specification should be a superset of a JSON.

JSON strings currently accept unescaped U+2028 and U+2029 characters, while ECMAScript strings don’t. With this extension of the ECMAScript JSON, this gap will be patched.

Optional catch binding

In previous versions of ECMAScript, we had to implement a catch binding even if we never had to use it.

try {
  // ...
} catch (error) {
  // handle error

With this addition, we can now simply omit it.

try {
  // ...
} catch {
  // handle error

Well-formed JSON.stringify()

This fixes the JSON.stringify() output when it processes surrogate UTF-8 code points (U+D800 to U+DFFF). Before this change calling JSON.stringify() would return a malformed Unicode character (a “�”).

Now those surrogate code points can be safely represented as strings using JSON.stringify() and transformed back into their original representation using JSON.parse().


ES2019 introduces a change to the toString instance method of functions. Now the returned value will be exactly as defined, without stripping whitespaces and comments.

function /* this is foo */ foo () {}

// previous behavior of toString()
"function foo () {}"

// proposal behavior
"function /* this is foo */ foo () {}"

Upcoming candidate features

The following list contains all current candidate features which have reached Stage 3 and will most likely be included in the specification in the future.

FrontCon 2019 in Riga, Latvia

Reading Time: 3 minutes

Only a few weeks left until I go to my first tech conference this year. Travelling means for me learning something new. And I like learning. Especially the immersion in a foreign culture and the contact to people of other countries makes me happy.

It’s always time to grow beyond yourself. 🤓

BUT why visit Riga just for a conference? Riga is a beautiful city on the Baltic Sea and the capital of Latvia. Latvia is a small country with the neighbours: Russia, Lithuania, Estonia and the sea. AND it’s a childhood dream of me to get to know this city. 😍

The dream was created by an old computer game named “The Patrician”. It’s a historical trading simulation computer game and my brothers and I loved it. We lost a lot of hours to play it instead of finding a way to hack it. 😅
For this dream, I will take some extra private days to visit Riga and the Country as well. 😇


The most important preparation such as flight, hotel, workshop and conference are completed.

Furthermore, I also plan to visit some of the famous Latvian palaces and the Medieval Castle of Riga. I also need some tips for the evenings: restaurants and sightseeings from you. Feel free to share them in the comments. 😊

Some facts about the conference

There are four workshops available on the first day:

  • Serverless apps development for frontend developers
  • Vue state management with vuex
  • From Zero to App: A React Workshop
  • Advanced React Workshop

I chose the workshop with VueJS of course 😏 and I’m really happy to see that I can visit most of the talks in the following days. There are some interesting speeches like “Building resilient frontend architecture”, “AAA 3D graphics” and secure talks and server-less frontend development. Click here for the full list of tracks.

My expectations

Above all, I’m open to events to learn new things. Therefore, I have no great expectations in advance. So I’m looking forward to the

  • VueJS & Reacts parts
  • Visit the speakers from Wix, N26 and SumUp

I’m particularly curious about the open spaces between the speeches. I will be glad to have some great talks with the guys. 🤩

For my private trips:

That’s all for now

to be continued…

Webpack: The Good, The Bad and The Ugly

Reading Time: 5 minutes


Webpack, a static module bundler, a complex yet simple tool, that allows you to spend between 10 minutes and 10 hours to make a simple web application bundlable.

The Good

As a static module bundler, Webpack delivers a bundle of code that’s easily parseable for your browser or node environment. It allows users to use the UMD/AMD system of bundling code and applies it on images, HTML, CSS and much much more. This allows the developer to create a module or more modules with a segment or multiple segments of a web app, and serve it all, or serve parts.
One of the major sell points of Webpack is the ability to modify it to your choosing. It’s a rich ecosystem of plugins that exist to enhance the already plentiful options of the bundler itself. This allows for Front-end libraries and frameworks to use it to bundle their code using custom solutions and plugins, the likes of Angular, ReactJS and VueJS.

This is made easy by the years of development through which we have reached Webpack 4, that allows for multiple configuration files for development and production environments.

The example in the image is a view into the differences that allow for good development overview and testing, yet at the same time make it possible to use a single script to build a production-ready build. All of this together makes Webpack a viable bundler for most JS projects, especially when it’s the base of ecosystems like in Angular or React.

The Bad

Whilst Webpack is a good bundler of JS, it’s not the only one available. Issues in Webpack come from the fact that most of the libraries that you use need to have been worked on and developed with Webpack bundling in mind. Its native module support is limited, requiring you to specify those resources and what way you do want them to be represented in the final build. And most of the time, a random version update of a model can break the entire project, even on tertiary modules.

The learning curve of Webpack is getting higher and higher, it all depends on how complex a project you are working on, and whether you are working with a preconfigured project or building a configuration on your own.

Just for this article I have gone over not only the Webpack docs, but around 20 articles, a ton of github issues. And around a year and a half of my personal setup experience bundling project with Webpack using Three.js, A-Frame, React, Angular, and a myriad of other niche applications. And in the end it still feel like i’ve barely scratched the surface.

The entire debugging process is ugly, it depends upon source-maps which vary from library to library. You can use the in-built Webpack option or use a plugin for your specific tech, it will never be fun. Loading up a 160k code bundle and blocking your pc, even with source-maps.

The Ugly

All in all, when you give Webpack a chance, your encounter will rarely be a pleasant one. There shall never be a valid standardized version for using and implementing the core. And the plugins don’t help. Each time you find something that works, something new will magically brake. It’s like trying to fix a sinking ship.

This image represents my average day using Webpack, if my project was the dog and Webpack the firestarter. Currently using it in combination with VueJS. It’s the same story, either use the vuecli and a preloaded config. Or regret not doing that later when you need to optimize your specific code integration that needs to run as a bundled part of a larger application.

The worst part of all of this probably is the widespread usage of black-box software like Webpack, which in theory is open source but is a bundle of libraries and custom code that takes as much time as a doctors thesis to study properly. And for all of this, it still is one of the better options out there.


Webpack as a bundler is excellent for use in a multitude of applications. Especially if someone else handles the config for you (Angular, React, Vue clis). It will hopefully become better, but like anything else in JS its roots and backwards compatibility will always bring it down. Be ready for a high learning curve and a lot of frustration. If you like to explore new things, or reimplement existing solutions, or optimize workflow, give it a try.