The current state of JavaScript language


#1

…vs the ActionScript 3.0 language

Back in 2012 or so, we could see a lot of AS3 dev moving away from the Flash Platform to the HTML5/JS platform with such articles as

TypeScript for ActionScript Developers
From AS3 to TypeScript
etc.

Now we are in 2016, it should be even better right?

well… according to this other article
State of the Art JavaScript in 2016

here the view on TypeScript or types in general

Language: ES6 with Babel. No types (yet)

Avoid CoffeeScript. Most of its better features are now in ES6, a standard. Tooling (such as CoffeeLint) is very weak. Its community is also rapidly declining.

ES6 is a standard. Most of it is supported in the latest version of major browsers. Babel is an amazing “pluggable” ES6 compiler. Configure it with the right presets for your target browsers and you’re good to go.

What about types? TypeScript and Flow both offer ways to add static typing to JavaScript, enhancing tooling and catching bugs without needing tests. With that said, I suggest a wait and see approach for now.

TypeScript tries too hard to make JavaScript like C# or Java, lacking on modern type system features such as algebraic data types (and you really want those if you’re going to do static types!). It also doesn’t handle nulls as well as Flow.

EDIT: It was brought up that TypeScript does have things like union types which cover a lot of use cases. I only meant that I think when it comes to type system in UX-land, you go all the way or not at all.

Flow can be much more powerful, catching a wider variety of bugs, but it can be hard to setup. It’s also behind Babel in terms of language features and has poor Windows support.

I’ll say something controversial: Types are not nearly as critical to front end development as some will have you believe (the whole argument will have to be in a future blog post). Wait until the type systems are more robust and stick to Babel for now, keeping an eye on Flow as it matures.

So, according to what is written above

ES6 is a standard. Most of it is supported

true, now ES6 or ES2015 is a standard
but considering the support part, well … let’s see, let’s follow the link

ES6

and while we’re at it let’s also look into ES next (ES2016, ES2017, etc.)

ESnext

so from ES6, let’s take something simple as the super() function that you use when you inherit from a class to call its parent constructor
see the ES6 highlight here

let’s also use
Desktop Browser Market Share

and
Desktop Browser Version Market Share

For Microsoft IE/Edge: 3%
total share: 44,79%

  • IE 11.0 or less: not supported
    at least 23,16% of browsers market
  • Edge 12: not supported
    0,91% of browsers market
  • Edge 13: fully supported
    3,02% of browsers market
  • Edge 14: fully supported
    unkown % of browsers market

For Mozilla Firefox: 0,4%
total share: 11,68%

  • Firefox 38 ESR (Extended Support Release): not supported
    at least 0,40% of browsers market
  • Firefox 45: fully supported
    0,38% of browsers market
  • Firefox 46: fully supported
    unknown % of browsers market
  • Firefox 47: fully supported
    unknown % of browsers market
  • Firefox 48: fully supported
    unknown % of browsers market

For Google Chrome: 0,35%
total share: 36,56%

  • Chrome 49: fully supported
    0,17% of browsers market
  • Chrome 50: fully supported
    0,18% of browsers market
  • Chrome 51: fully supported
    unknown % of browsers market

For Apple Safari: 3,50%
total share: 4,88%

  • Safari 6.1/7: not supported
    unknown % of browsers market
  • Safari 7.1/8: not supported
    at least 0,44% of browsers market
  • Safari 9: partially supported
    3,50% of browsers market

Let’s add everything up
so how many browsers can currently use the super() function ?

total: 7,15%
that’s JavaScript for you

ES6 is a standard. Most of it is supported

Now, let’s compare to AS3

oh sure the Flash Player is not standard, but still it is installed on 90% (and more) of desktop browsers out there, and we also have this super() function, and we can basically use it since 2006


Couple of interesting things we can learn from JavaScript
Chrome dev summit 2017 keynote
The State of JavaScript 2017
#2

The thing is, it doesn’t matter that ES6 features are mostly limited to the latest versions of major browsers. Babel and TypeScript support these features today, and that matters more. Since they compile down to ES5 (or even ES3), which is widely supported, developers don’t need to wait for people to upgrade their browsers.


#3

Yep no problem with that ES6 indeed does not matter but is much hyped
because you could use anything else that transpile to ES3/ES5

why not use GWT (Java to JS) ?, or Transcript (Python 3.5 to JS) ?, etc…
or anything listed in List of languages that compile to JS

btw someone should add FlexJS to the list above.

My point in all that was more to show that we have a standard with AS3 since 2006 and compared to the ES6 standard of today (10 years later) and the percentage of browsers supporting it, using AS3 is not necessarily a bad choice.

Most of people will advise to use JS to build an app for the browser, I’m just sayin’ “wait… look around”


#4

Fair enough! :slight_smile:

Indeed, Apache FlexJS and ActionScript should be on that page. I’ll try to get it added.


#5

“If you don’t need it, don’t use it”
that’s true


#6

Yep. AS3/ES4 should have been the language for the web a long time ago, thanks a lot to the awful process that standards are. It’s agonizing to watch the web community struggle over things that were solved by AS3 and Flash in general literally 10 years ago. It’s so slow, my life isn’t that long! Haha.

Personally I’m using TypeScript for everything outside of Flash these days. TypeScript is a lot like AS3, surprise, surprise. There’s no runtime type system so it’s more like AS2, actually. It’s very robust and accommodates the limits of JavaScript more than pretending to be a new language.

In general I just think it’s ridiculous that there are so many constraints around the languages we use for the web. How is it 2016 and the only way standards have to publish an app to the web is to send plain text source code to the clients browser? That’s crazy! I’m hoping WASM will free us from the shackles of ECMAScript.


#7

I don’t understand this World, the people are crazy, specially Adobe.

Why if we had a robust platform (AS3) right now to develop complete rich and fast app for the web and beyond, the community are looking go back (7 years ago and start again all)… Is like if we have flying car and the companies says, burn all the flying car, go back to the past and start to inventing the flying car again.

I work in many languages but with JS I feel like working with a prehistoric language. Some people are happy with JS and say it’s amazing, is the future…. I only have an answer for them, you never meet AS3 and don’t know the possibilities that it offer.


#8

I don’t think the problem is the language itself. Because JS has some good parts, and you can also use ES6 right now.

The big problem is that any browser does not really support all the features or doing the same way of implementation. If you had been struggling with DOM and CSS, not only JS, you might have known the pain:

Write Once, Debug Everywhere.


#9

It’s all of the above IMO. JS, DOM, CSS, SVG… all ancient technologies evolved by committee and competing interest groups (browser vendors) over eons of internet time. :slight_smile:


#10

ES5+ is a desperado. However, any browser that supports HTML5 supports the basic root.TypedArray and rarely root.DataView (standardized on ES6).

TypedArray allows reading and writting to an allocated memory, e.g., Uint8Array, an array of bytes.

(Particularly I’d avoid dictionary-like instances/namespaces on JS code, since hardly any engine optimizes their accesses. I’d prefer contiguous arrays and local variables instead, which are guaranteed to be faster. Well, gotta like compile time…)

Lots of browsers support typed arrays, not only the modern ones, so it’s possible to fit the entire ActionScript 3 efficiently, actually.

Even without typed arrays it’s possible to do it efficiently, excluding the lovely flash::utils::ByteArray. But a non-sense code that messes the global object with dynamic properties may be slow since we’d need to track the AS3 types that are beyond JS, on run time. Obviously a warning of dynamic accesses solves it all.

I’m not really satisfied with FlexJS output. It could be times 100x better.

If I bornt much more before I’d certainly have had half of my AS3 compiler done. I could only know Flash Professional on 2014 and I still were a 13 kid. And for me ES4 and E4X will always be mutants. ES4 is a cousin.


#11

It’s just one part of the problem, sure typedArray are nice and in fact necessary to implement some stuff but look at the Browser compatibility here, it’s far from being supported everywhere, so you will have to polyfill a lot of stuff or use the smallest common denominator.

Even 1 year later I still find ES6 is a huge disappointment, oh yeah you got class but no private/protected/public methods … almost like they really want you to keep using lambda functions to fake something private :scream:

then contribute to the project and improve the output


#12

Thanks for the idea! I could, but I’m not really interested since I’m building my own compiler. I also might want to add simple extensions like type parameters and blah.


#13

many developers think that every technology adoption is purely linked to technical performance.
it’s not, at a major scale it’s political and strategical.
You wonder why They are changing technology every 10 years?
well, first to control the standards, second to restart a (fake) economy boost and third to kill the competition,


#14

There’s more to adoption than performance but I think are more variables than commercial too. Many times the directions go down to what fulfills the participants goals. Many languages and platforms come and go and some are motivated by commercial and others are not.

For example, Apple was proprietary with the iPhone apps initially and then with some persuading they opened up the app store to external developers.

At first they used Objective C but in time Swift emerged. I don’t think Apple was attempting to end the life of Objective C but had a desire to make an easier to use language.

Macromedia, Adobe, Allaire and others had different clients and users using their web software as the web was growing.

The needs from the web developers and their clients formed the Flash and AIR runtimes, languages, development tools and the whole platform. As we know later some decisions were then made based on obstacles (Flash not allowed to run on Apple devices, slander from competition and so on).

Software development is still relatively new field. I agree some changes were commercially motivated but some were evolution or improvements on languages to deal with different paradigms. For example, small device UI, web development, client server work, app, low bandwidth constraints. Those new languages were created out of those needs.