Microsoft Tech
By Christian Heilmann

The ES6 Conundrum

By Christian Heilmann

This article is part of a web dev series from Microsoft. Thank you for supporting the partners who make SitePoint possible.

ECMAScript6 or ES6 is the evolution of JavaScript and it is the future. It is the technology innovation for the web we’ve all been waiting for. It is full of great functionality we always craved and it finally enables us to build huge applications for the web in a scalable and easy to maintain manner. It empowers thousands of developers coming from Java or C# or other “higher” languages to finally write JavaScript and bring all the goodness of their experience to a market in dire need of organization and direction.

That’s the sales pitch and — to be fair — a lot of it is true. However, it also makes a lot of assumptions as to what needs fixing on the web. And there is a real problem with evolving a language as ubiquitous as JavaScript without having control of the environments it is executed in. The web is a distributed platform. It is much harder to change the wheels on a vehicle that is constantly in motion than on one you can bring back to the shop, lock up, upgrade and drive out again.

JavaScript Doesn’t Seem to Cut It Any Longer

The, shall we say, lenient architecture of JavaScript has always been a source of confusion for programmers coming from other languages. Especially the lack of classes and prototypical inheritance is a no-go for a lot of people. It feels counter-intuitive and it doesn’t represent what is being taught in schools about computing. To make matters worse, we have the beautiful, but confusing construct of closures and a lack of constants and type safety. All that meant that JavaScript got a reputation for being badly architected and not to be trusted with large code bases. Despite all this, it managed to evolve into one of the most used languages in software development now – to a large part thanks to the rise of the web.

ES6 and the following versions of the language are meant to do away with these annoyances and make JavaScript a better, more reliable and more efficient language.

This, to be fair, is nothing new. We had a few languages that built on JavaScript in the past and tried to fix these issues. TypeScript, Dart, CoffeeScript and even Flash’s ActionScript all tried to solve the same issue. The difference was that they all needed some kind of conversion or container to show up in the browser. ES6, now that it is finalized, is intended to be native to the browser and run just like JavaScript using a script element pointing to it. ES6 has a lot of impressive features:

  • Arrow functions as a short-hand version of an anonymous function.
  • Block-level scope using let instead of var makes variables scoped to a block (if, for, while, etc.)
  • Classes to encapsulate and extend code.
  • Constants using the const keyword.
  • Default parameters for functions like foo(bar = 3, baz = 2)
  • Destructuring to assign values from arrays or objects into variables.
  • Generators that create iterators using function* and the yield keyword.
  • Map, a Dictionary type object that can be used to store key/value pairs. and Set as a collection object to store a list of data values.
  • Modules as a way of organizing and loading code.
  • Promises for async operations avoiding callback hell
  • Rest parameters instead of using arguments to access functions arguments.
  • Template Strings to build up string values including multi-line strings.

Considering what we’re doing with JavaScript these days, this seems to be a real need. Gaming, App Development and even server side development all are possible in JavaScript. And with each environment we have developers that are used to different tools and methodologies. The wild west web development of the past seems to be counterproductive to the performance and maintenance needs of today. This reminds me of the time when we moved from DHTML to DOM Scripting. Order, we need order and reliability.

Where this falls apart is that currently ES6 is far from ready to be deployed on the web. That is not the fault of the language, but of the nature of the web. We can’t and shouldn’t dictate what people use to surf the web. But the support for ES6 in different current browsers is not encouraging.

A comprehensive ES6 support grid maintained by Juriy Zaytsev

The bigger problem is that ES6 breaks the device and browser-independent idea of the web for the first time in the history of JavaScript.

Breaking the Web with New Syntax

The problem with ES6 is not what it does to the language – JavaScript has always been extended with new methods and APIs. All we needed to do to use them safely was to test if the current browser or environment knows about this functionality before applying it. This is called progressive enhancement and means that we never deliver broken experiences.

When you test for the existence of a certain method before calling it, you’re safe. Much like checking that a river is deep enough before jumping in is a good idea. The problem with ES6 is that it breaks backwards compatibility as it introduces many syntax changes to JavaScript instead of just new methods and objects.

That shouldn’t be an issue, but unlike all the other languages used to build “things” on the web (consciously skirting the sites vs. apps debate here) JavaScript is not fault tolerant.

The following HTML is not a problem for a browser:


Internally this gets fixed and the browser goes on its merry way to render the rest of the page:

Firefox Developer tools showing how the HTML5 parser fixed the wrongly nested HTML

Firefox Developer tools showing how the HTML5 parser fixed the wrongly nested HTML

This fault tolerance was one of the main ideas of HTML5. The HTML5 parser is extremely forgiving as we knew that developers make errors and our users shouldn’t suffer for them. An XHTML document with a single error would fail to render. This wasn’t good enough – we needed a sturdier web as the end user experience trumps over everything else. This is even defined as a design principle of HTML as the Priority of Constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

CSS parsers have the same attitude towards code. For example the paragraphs in a document with this CSS applied to it will be a light orange.

p {color: microsoftblue;}
p {color: peachpuff;}
p {colour: powderblue;}

“peachpuff” is a valid name for a CSS colour, whereas “microsoftblue” is not. Whilst “powderblue” is also a valid colour, the gramatically properly spelled “colour” needs to be “color” in CSS, which is why it doesn’t get applied. In essence, whatever line of code the CSS parser can’t deal with is skipped.

This fault tolerance doesn’t work in JavaScript, which is why it is the most fragile part of the web stack. Any issue that causes a JavaScript error means that the whole script doesn’t get executed – there is no tolerance in the browser.

When people discuss the need to progressively enhance on the web this often gets forgotten. It is not about end users that have JavaScript disabled – those are a very small minority. It is about all the things that can go wrong before JavaScript is executed and when the browser finally tries to run it. Stuart Langridge maintains an interesting decision tree telling you all the things that can go wrong from requesting your script to its execution.

ES6 introduces a lot of changes to the syntax of JavaScript. Whilst an ES6 compatible browser or preprocessor has no problem with the following code, for a non-ES6 browser this is nothing but a syntax error.

function showperson(ismember = 0, hasphoto = 0, ...moar) {
    /* … */

This presents us with a big problem. Using ES6 is not possible unless we limit ourselves to the few browsers that already support it. Microsoft Edge, Firefox, Chrome and iOS Safari all have a good sub-set of ES6 implemented. However, not all these browsers are what our users have, and we can not assume people upgrade all the time. Sadly enough, there is a lot of hardware out there that comes with a non-upgradeable OS that has an outdated browser hardwired in it.

Feature Detecting Syntax Support?

One very interesting approach to this issue is by Kyle Simpson. It is a very small JavaScript library that allows you to test for ES6 features and thus only load your ES6 scripts when and if the browser supports them. So to say, progressive enhancement on a syntactical level.

Using this library, you can test the browsers you have and see what they support. A quick check on my machine right now shows this:

A table showing how various browsers support ES6 features

I am not trying to compare browsers here – this is a waste of time, seeing how quickly that changes. I want to show is that when it comes to support of ES6 in browsers, there are quite some differences in between them. This makes feature testing awkward as it is only safe when you test all the things you want to use. Assuming support for other features when you test for only one is a slippery slope.

If you go all the way and test for each and every feature you want to use your code will not break. It can, however, easily turn into overkill. The point of ES6 for a lot of developers is not to use the features piecemeal but write the whole app in ES6 from the start.

That’s nothing new. When HTML5 and CSS3 was a whole hype word and we couldn’t wait to use it, we got a lot of “this cool thing only works in Safari” or “you need to use Chrome to see this site” as a lot of the features were still in flux. These products are still on the web, largely unmaintained and browsers need to include a lot of cruft into their codebases to not break the web. We wanted too much, too fast and we didn’t clean up afterwards.

A lot of effort went into allowing developers to feature detect everything automatically using Modernizr. For legacy browser support, this is still a very good idea, but in a more defined environment, developers found it to be an unnecessary overhead. Instead, we started to set a baseline of support and only give scripting functionality and advanced styling to those browsers that make the cut. The developers at the BBC called this ” cutting the mustard” over three years ago and their baseline is these few checks:

if ('querySelector' in document &&
    'localStorage' in window &&
    'addEventListener' in window) {
     // bootstrap the javascript application

Maybe this is something we could think of for our ES6 work, too? Define a few gatekeeper features that get checked and go forward from there?

If you don’t want to be dependent on browser support and all you want is to use ES6 in its entirety, you’ll need to use something that converts your code. This could be an own language like TypeScript or a so called Transpiler (as it translates and compiles ES6 to JavaScript).

Transpiling to the Rescue?

The good thing about JavaScript these days is that it escaped the confines of the browser and is also usable server-side. node.js uses the V8 engine of Chrome as a standalone binary and also can now use Microsoft’s Chakra JS engine. This allows us to use any JavaScript conversion tool to take ES6 code and convert it to good old JavaScript that runs in any browser. If you’re already using task management using Grunt or Gulp, this could be just another task to run before deployment.

There are a few options out there. The most known transpilers are Traceur that originated from Google and Babel, which originally was called 6 to 5, but as ECMAScript evolves even as we try to implement it, there was a need for a more generic name.

Transpiling seems to be the safest way right now to use ES6 in real projects without worrying about support discrepancies across environments. It also ties in nicely to the workflow of developers who are used to stricter and class based languages. But, on closer introspection, there are some weird drawbacks:

  • First of all, transpiling in most cases doesn’t do any feature detection at all – the ES6 code gets fully converted to ES5 (or in some cases even down to ES3, should you want to do that). This means that browsers that natively support ES6 will never get the code. It makes the implementation in the browser a bit redundant, and – even worse – it doesn’t allow for testing the performance and validity of the ES6 implementation in the browser.
  • Traditionally the web was view-source. That’s how a lot of us in the past learned how to code for it. We looked at the source and found out what others used, and our debugging process was doing the same, after seeing in an error console that something broke. Nowadays we have developer tools for that, with much more advanced features. However, if we transpile the code, we never write the code that gets executed. The code we debug in the browser is what the transpiler created, which is optimised for performance, not for readability. In order to debug our code we need to find a way to connect the generated code with the written code. For this, we use source maps. This also applies to CSS that gets generated by Sass or less.
  • Generating code from other code could lead to massive files. That the original code we write is compact, clean and structured is not necessarily the important thing when the end result means the user has to download megabytes of JavaScript for an interface that could be much more lightweight.

What About Performance?

Whenever we introduce new functionality to browsers, there is the question if we make things faster or if we slow things down. We just don’t know until we gathered enough data to find out where to optimize. In the case of ES6, that data gathering can’t really happen if we transpile the code. Right now, the performance of ES6 natively in the browser does not look too encouraging as this speed report by Kevin Decker shows.

A report shows the performance of ES6 features relative to the ES5 baseline operations per second.

This report shows the performance of ES6 features relative to the ES5 baseline operations per second. Everything not dark green is slower than JavaScript. Everything not dark green is either slower or identical to ES5 performance. This means that only the spread operator, Promises, Maps and Sets bring performance benefits.

ES6 Matters and Needs Our Attention

Right now, ES6 is in a weird place when it comes to web development as a whole. It is a standard, it is well supported (more than, for example Web Components) but it also breaks backwards compatibility. Instead of praising all the great things it does and show examples that may or may not work for you, I’d like to invite you to take part in the discussions around ES6. This is why I want to end this here with a few questions for you to ponder and we’d love to hear your opinions in the comments.

If our main purpose is to create web content with our coding efforts, we need to ask ourselves a few questions:

  • Do we let developer convenience trump over end user experience? Is it more important to deliver more, quicker than deliver the best performing solution for a certain environment?
  • Is it OK to build larger apps that expect more of the end user’s environment when it is easier, faster and more maintainable for us?
  • Does being able to change an app easier and extend it in a more defined way make up for locking out users?
  • Is it high time that we draw a line in the sand and make JavaScript safer and easier to extend?
  • Was the concept of ongoing backwards compatibility of the web flawed? Are we holding ourselves back by catering to the lowest common denominator?
  • Are the new features of ES6 really a benefit or do we just try to catch up and repeat what other environments did? Is this really the best we can do seeing that software as a whole might be broken?
  • Are the benefits of these changes worth the effort it needs to use them? Should new developers coming to the web have to use transpilers, preprocessors and task runners to get started?
  • How can we help browsers be better in supporting ES6 when transpilers create ES5?
  • Is using a subset of JavaScript, like TypeScript, the better option?
  • Is it the right direction to abstract the code we write away from the code the browser gets? Has view-source outlived its usefulness?
  • Is ES6 just another way of working on the web – much like converting bytecode to JavaScript using emscripten is or Flash was? A precompile step might seem weird to a web developer, but someone coming from Java is totally OK with it. In other words, is ES6 not for everybody, but we try to make it that?

The next few months will be exciting around ES6, and its very nature means there will be ongoing discussions and talks for quite a while. It appeals very much to those who didn’t like the flexibility and randomness of JavaScript. And it confuses those who are firm in their use of JavaScript and feels like a lot of overhead for not much immediate benefit. Evolution always comes with growing pains. Time to speak up and try out what works for you.

More hands-on with JavaScript

This article is part of the web development series from Microsoft tech evangelists on practical JavaScript learning, open source projects, and interoperability best practices including Microsoft Edge browser and the new EdgeHTML rendering engine.

We encourage you to test across browsers and devices including Microsoft Edge – the default browser for Windows 10 – with free tools on dev.modern.IE:

In-depth tech learning on Microsoft Edge and the Web Platform from our engineers and evangelists:

More free cross-platform tools & resources for the Web Platform:

  • Very insightful and well presented article. Thanks for sharing your thoughts.
    You mentioned TypeScript only among those final questions. I think that may be [one of] the correct course as we navigate these rocky waters.

  • Everywhere in this article that says “backwards compatibility” actually means “forwards compatibility”. There are a handful of tiny “backwards compat” breaking changes in ES6, but they are mostly not related to all the new ES6 syntax being discussed here.

    * “Backwards Compatibility” means: “old code continues to work in newer environments”.
    * “Forwards Compatibility” means: “new code works (even partially) in older environments” — like how new HTML tags don’t break the rendering in older browsers, but just get ignored largely.

    So new ES6 syntax is non-forwards-compatible, but it doesn’t break backwards-compat at all.

    An example of a legitimate break in backwards compat is `let[x] = [2]`. Prior to ES6, this was considered a `[x]` access of an array/object called `let`. As of ES6, it’s considered an array destructuring assignment with the new `let` block scoping.

    • Both ES5 and ES3 also introduced forward-compat breakages (aka, new syntax):
      – `try .. catch` in ES3
      – `get (..)` / `set (..)` in ES5

      Certainly ES6 introduces way more forward-compat breakages than the previous updates, but that’s also because these changes were a long time coming (many of them were attempted in the ES4 timeline and failed) and JS needed quite a face lift.

      Point being, none of this new stuff (in any of the 3) has “broken” the web, as some have become accustomed to suggesting. All the old web continues to work just fine in the newer browsers (and even better, via more performance optimization).

      We didn’t need transpilers back in ES3 and ES5, mostly because the new syntax wasn’t really all that compelling and so the payoff wasn’t very high. But we could have had them back then, just like we do now.

      I for one welcome our new transpiling overlords. The web is not broken by ES6, it just got upgraded.

      • pdimitar

        Spoken like a true JS fan and a nitpicker lover, sir.

        You might have the expertise in JS that many of us don’t have; won’t argue with that. You got the details. What you definitely don’t have — or at least you don’t demonstrate it here — is an outlook to the programming as a bigger area which has other values than JS: values like consistency, predictability, being tidy, has only one way of doing things, has easily pipe-able pieces, has strong or at least duck types, is instrumentable, limits or eliminates side effects… and I probably forget at least two dozen more good practices.

        Looking at those videos in YouTube showing all the mysterious ways a JS comparison can produce WTF results is not even funny anymore. It’s a living testament to the insanity of the JS area and what are people putting up with.

        We don’t need more tools and new “overlords”. Are you really such a fan that you cannot see that when a technology needs dozens of crutches by its community, it’s really time to just let it die with dignity and move on? Can you not?

        As I’ve commented above in my standalone post, it’s the lack of courage and constant dodging of the real problems that produced the current situation. And now we’ll invest even more in the same measures that we already know will inevitably fail no more than a year and a half from now?

        How does that even make any sense?

  • Strength to strength. Thanks Christian.

    Double extra points just for using the word “conundrum” in an article on JavaScript. :)

  • Brent Roose

    “If you go all the way and test for each and every feature you want to use your code will not break.”

    That’s just utter nonsense. If you’re not executing parts of your codebase because that part is not compatible with the client’s system, chances are your application will break.

    The issue you raise is valid though, and not a simple one to solve. I personally prefer a whole other approach: to take these awesome web technologies and use them for desktop application development:

  • Peter Michaux

    This is worth discussion but none of this is new. When try-catch syntax was introduced to JavaScript, using the new syntax broke Web pages. The solution now is the same as the solution was then: Wait 5 years and see if non-supportive browsers have dwindled to insignificant popularity. In the mean time, ES5 is plenty capable even if developers are insatiably trendy.

    The focus on ES6 is, or at least is verging on, distraction from the real problem. It is becoming much more difficult to develop for the browser for many reasons other than JavaScript. In fact, JavaScript is still one of the easiest parts when a developer has taken the time to learn a small handful of concepts (e.g. prototypes and closures.) Large, high-budget development teams like GMail have raised the bar so high for browser-based apps that it is very difficult for small development teams to compete given the still very inconsistent nature of the popular browsers. Also, native mobile apps, when available, are now preferred by people I know as they load faster and download less over the connection each time they are used.

  • “It feels counter-intuitive and it doesn’t represent what is being taught in schools about computing” – should we adapt the tools to what academia is teaching, or should academia adapt to the “real world”? People certainly need to be trained, and the quote reflects some of the disparity in programming education.

  • Owen Densmore

    There is an existence proof that es5 is ‘good enough’: transpilers like babel do it, so by getting hip enough, we can do it all w/o es6 (well, except modules).

    Unfortunately, Web Assembly is going to make JS obsolete. I already have a friend using C++ & emscripten because its guaranteed to work well and better than JS itself, as well as in the compiled form.

    • Tarabass

      Unfortunately? Why?

      I don’t think it will go that way. Al those scriptkiddies using javascript now a days mostly didn’t want to learn a dissent language. ‘With JavaScript they can do it all’. Most devs aren’t even programmers, but can write complete servers now. At least they thing they can. Only older programmers can make the step to c++ (and other languages) easily, but they didn’t make it towards GTW and tools like that..

      Never the less, from my point of view it would be a bless when JavaScript would be obsolete. And I say that as a JavaScript programmer with a broad programming background.

    • steve

      Guaranteed? Nothing is guaranteed.

    • pdimitar

      Programming languages are prone to subjectivism. Some love Ruby, others Python, others are confident Perl 5 is enough until the end of days, and a fourth group says Smalltalk is all they ever needed.

      There can’t be ANY “proof” that ES5 is good enough. It certainly isn’t for me. When you have to pay attention not to step on any of ES5’s corns 80% of the time you are writing your JS code, you should ask yourself WTF is going on. Omit one character accidentally when extending a prototype and you can hunt for bugs for hours. Sure, ES5 is good enough. Or Javascript for that matter. I say let’s go back to Visual Basic, what do you say?

  • vivainio

    Some “well actually’s”:

    – TypeScript is a SUPERset of JS (yeah, I know this is what you meant ;).

    – Pretty much all the languages have closures these days (even Java).

    Transipilation is very well worth the effort. We switched to TypeScript, and it’s way less bug-prone and more enjoyable than ES5 (or ES6).

    It doesn’t matter much what new developers do, but if you spend nonzero amount of hours every day doing frontend development, you should just take the initial hit and go for it. Effort from browser engines to support for ES6 is probably mostly wasted (as nobody can use it for production apps for a long time anyway), but Node devs will certainly benefit from ES6 support in v8.

  • Since patching Javascript with ES6 would result in breaking the web anyway, why didn’t we just work on releasing Javascript 2.0? A refactored, backward incompatible version of JavaScript that has all the ugly parts of JSv1.0 fixed/removed and includes several new features (like the ones in ES6).

    rip the band aid off once and for all

    • ES6 is most definitely not breaking the web… that’s the difference between the FUD that’s being spread and reality. ES6 is breaking forwards-compat but not backwards-compat. Whatever the “JS 2.0” is that you speak of, that really would break the entire web by breaking backwards-compat, which is an entirely more drastic thing than what ES6 (and ES5 and ES3 before it) has done.

    • pdimitar

      History has shown many times, especially in our profession, that after some time and effort poured into bandaids, that it’s indeed a high time to just start over. I agree. It honestly can’t be worse than now.

  • srcspider

    > Especially the lack of classes and prototypical inheritance is a no-go for a lot of people. It feels counter-intuitive and it doesn’t represent what is being taught in schools about computing.

    Not javascript’s problem.

    This is the same as saying “people are though in school java like languages that ignore all hardware so javascript needs to be tuned to be an abysmal language with bad performance.” I’m exacgerating a bit but the sad thing is a lot of that analogy is painfully true. Schools teach based on what’s easier to teach and introduce students to only these “sugar” languages that are designed to cater to the largest common denominator, usually in ways that make them look “superior” (such as presenting only really trivial or dumb problems as student exercises) then everyone bitches once those students go and wrech havoc in the wild on “why is X and Y slow” and “we need A and B to fix so-and-so.”

    There’s no need to cater to dumb schools, adapt or die as an institution! If there wasn’t such a focus on lazy one-size fit-all concepts like “classes” that both spiral into a mess at scale and completely crap on “hardware” we wouldn’t have half the problems we have now. Don’t get me wrong, classes as they were originally envisoned are fine and they’re also fine when they’re used as a “concept” and not as a “magical keyword that solves everything for you if you just spam it”.

    I expect the introduction of classes with ES6 to just lower quality (speed, clarity, flexibility) overall and exponentially increase library sizes as people apply their “smarts” from years school of “throw classes at a problem until the machine dies and you can say its unsolvable, or the problem is replaced by the problem of your unmaintanable monstrosity”.

    • steve

      Well said

    • David Carr

      Good comment.

  • I don’t think there’s a huge problem here, we just need the JS equivalent of PostCSS’s Autoprefixer ( ) mixed in to transpilers so that they generate code based on which browsers do you want to support.

  • Michał Gołębiowski

    TypeScript is not a subset of JavaScript, it’s its superset.

  • wyattb

    Sounds like an attempt to make ES6 like a C# clone with C# hell (or Java clone). Maybe you should backoff and understand why people started using JS in the first place. And why they use Chrome or Firefox. And yes, it is an attempt to show that Edge is “better” (at least on the chart) and hijack nodejs. I will tell you when I will use any MS product. When it runs on all platforms equally. Linux, Mac OS X. Otherwise I don’t want anything to do with it.

  • “This means that browsers that natively support ES6 will never get the code.” — Why not deliver transpiled code to non-supporting browsers and the code as written to supporting browsers? This seems like a non-issue if we resolve the support detection issues… and even less of an issue as more and more browsers begin to support the new standard.

  • Oscar López Concha

    Is a copy of C# and Java. I came with arrow funtions. I am waiting for a Linq version.

  • steve

    This is the message i interpret from all these rave reviews on the latest developments on es6. ‘Ladies and gentleman. Javascript is difficult for computer science trained programmers who have crafted their skills in c, c++, java. Javascript is too complicated with its existing tools, so we have enhanced it with further tools making it even more complicated for everyone. The old javascripters will now have an even more difficult time understanding multiple ways of assigning a variable or reading a variable. We dont care about them because we want to give control now to the better programmers. ‘

    I say fine. Its a complet mess. I dont want to touch es6. Its counter intuitive. String mystring = “some string”; is readable and makes sense. What the f#### is this {foo:baz} = poo. Baz = poo.baz. ive been doing js for 15 years. Ive had a good run. The thing i most enjoy about programming is organising code, naming conventions, file structure to be quick to understand for other developers. This new language defeats that purpose. It is a fusion of many programming languages and is therefore a mess. It isnt java. It isnt c. It isnt javascript. Its a f###### huge mistake by some clever d#### who arent thinking about the developer experience and being able to recruit for, sustain technologists in an already fragile industry.
    Websites cost millions. They are about to blow up further with this added complexity.

    There is one fundmental point missing here. Most programmers dont write for the web. They dont understand html let alone the dom. They think they can style html and depend on librarys like angular and bootstrap to make it look pretty. They dont know how to have absolute control of how to make a web page animate, behave, share information with other modules without spending twice the time as an existing front end javascripter who knows how to craft the language, html, css into half the size to deal with ui latency, not just page load performance. Who knows how to manage the code so other developers can build on top of it and keeping the ui latency lean and code readable, less expensive to develop and keep within the guidelines of w3c accessibility, support multiple devices, can deal with imagery and fonts. Teach that to a java or c++ programmer and i wonder what they will do? Ask as to come back and we will say ‘sorry, i dont understand this language’ and the business will waste double their time and money finding a middle ground which is even more insustainable and cost them even more to recruit and train when their elite change jobs in an ever changing contract market.

    • Marko Vucinic

      beautiful comment sir

  • pdimitar

    You’re right, I forgot to mention Dart. Thank you. :)

    Google and Apple are the only companies on this planet who have courage and are willing to invest in new tech, it seems. But everybody else is stuck in their ways and doesn’t want to try and evolve the branch they’re working in. I’d imagine this is also because of economic reasons: just imagine an angry mob of 18-22 year old “disrupters” who only ever learned JS.

    Guess they don’t like it when they’re getting “disrupted”, hehe. Irony abounds.

    “Moving on” in JS would be stopping the insane amonts of adding of a hell of a lot of “features” to the language, freeze its spec for 2 years and devise a strict mode inside the frozen spec. Something that has only like 30% of the current JS. Let’s get this guy’s own book “Javascript: The good parts” and only implement that in the strict mode.

    There are things that _can_ be done. It’s infuriating that even they aren’t initiated and completed by anybody.

    • Hector409

      Personally I quite like JS as it currently stands (ES6) that is. I’m not a huge fan of class based languages, but classes in JS don’t actually change the way anything works… let at least.

      The one thing that would make my day job much easier is the async/await stuff that should be coming in ES7. At that point I’d be pretty happy if the language didn’t change anymore.

      I use C in my personal projects and I’ve been messing around with making a toy language for a while, just to test out different ideas and features. I think something between C and JS would be really nice. Similar sort of syntax, static typing, pointers, no GC, stronger type system than C, type inference and some sort of immutability with concurrency and parallelism built into the language.

      Oh and maybe classes, but with a different approach to inheritance. Something like the using keyword in Jai or maybe the ability to delegate functions from members.


      class Base
      func do_something()
      print( “I do something” );

      class Other
      // Allows instances of Other to access public members of Base.
      using base: Base;


      class Other
      base: Base;

      // Allows instances of Other to access this method on
      // Base, all other members have to be accessed through
      // other.base.member.
      delegate base.do_something;

      There isn’t anything to show for this yet, just some ideas I’ve had and I have a few implementations of parsers and VMs, that half work haha :)

Get the latest in Front-end, once a week, for free.