Couple of interesting things we can learn from JavaScript


In the same logic that started with
Couple of interesting things we can learn from Ruby
and followed by
Couple of interesting things we can learn from .NET

Let’s tackle JavaScript, even if nothing major been posted recently.

First Disclaimer:
Here by “JavaScript” I include the whole ecosystem to build applications
that means it also include HTML5, CSS and stuff like asm.js Web Assembly


Second Disclaimer:
If you think I’m just an “ActionScrip 3 lover” or “Flash fanboy” and what I’m doing
here is just trashing JS out of resentment or other delusion, think again.
As a developer, I was writing JS app in DHTML even before Flash was born,
I worked with things like Classic ASP JScript, Windows Script Host,
HTML Application (HTA), JSDB, poored my nose in source code of Rhino, SpiderMonkey engine, V8 engine, etc.
and even today I keep up to date on what’s going on in the JS world, and yeah
guilty as charged I did not try every goddam JS framework, but I do know them.

All that said, let’s begin.

It really started in a stupid way as I was listing numerous “UI kit” framework and comparing their lightness and other features to select a few for a personal project.

Here a non-exhaustive list

At that point I was thinking

oh boy it’s not only the JS framework that popup every day, it is also the UI kit

My focus was on Material Design Lite, because I want to build an app that look like Material Design but without using Angular.

Again my goal is to build the app from the server-side with Redtamarin, and at best if I need a bit of interactivity on the front-end use jQuery or Fetch combined with a UI Kit.

Simply because I don’t build a huge JS app, simply because I don’t like Single Page Application (SPA) and well why load a gazillion JS file if I only need a very basic AJAX request ? also the whole logic and work is done server-side so really there is not need to use something like React or Angular or whatever.

But … what if I wanted to make a SPA, which one of those JS framework would I chose ?

I thought the answer was obvious: write the code in TypeScript and use AngularJS 2
as I recently watched this video TypeScript and Angular 2 and all the dev are kind of my heroes (if you never read the blog of Miško Hevery it is a goldmine of article about singleton, dependency-injection, testing, etc.).

Well… not so fast.

Angular is made by Google, and there have been already a lot of angry JS dev complaining about the move from Angular 1 to Angular 2, while at the same time there is also something on the rise since 2013 which are the Web Components.

Me, naively, I thought that those web components would simply “plugin” into Angular, you know, as components of something bigger.

So here a little introduction: A Guide to Web Components

Recently I was working with a client to train their internal teams on how to build web applications. During this process it occurred to me that the way we presently architect the front-end is very strange and even a bit broken. In many instances you’re either copying huge chunks of HTML out of some doc and then pasting that into your app (Bootstrap, Foundation, etc.), or you’re sprinkling the page with jQuery plugins that have to be configured using JavaScript . It puts us in the rather unfortunate position of having to choose between bloated HTML or mysterious HTML, and often we choose both.

In an ideal scenario, the HTML language would be expressive enough to create complex UI widgets and also extensible so that we, the developers, could fill in any gaps with our own tags. Today, this is finally possible through a new set of standards called Web Components.

Yeah that’s true, if your “little” app that use jQuery, Backbone, knockout etc. grow a little bit bigger you find yourself with a lot of bloat, and that’s why since then those JS framework evolved and now we have Angular and React.

But it’s not exactly like that.

If you go there Google Developers Web Tools

you can find first the Web Starter Kit

What is Web Starter Kit?

Web Starter Kit is an easy way to start a new project. It comes with all the files you could need to start a new web project including a build process, boilerplate HTML and styles.

A responsive layout is included with the kit that adapts to fit the device your user is viewing it on. This helps you hit the ground running with an experience that looks good everywhere. Try a sample layout.

Web Starter Kit strives to give you a high performance starting point out of the box and we actively work on delivering the best PageSpeed Insights score and frame-rate possible.

We hope that you tailor Web Starter Kit by deleting anything that you don’t want or need. It’s a starting point - nothing more.

To me, this is pre “Material Design” UI kit (eg. without a JS framework attached), oh good that’s what I want right ?

Just underneath you can also see Polymer Starter Kit

Set up for success using Polymer in production.

Start your project with the Polymer Starter Kit to get the most out of the library, elements built with Polymer, and Polymer-related tools.

Components for nearly any app, out of the box

Get started quickly with the complete set of the same paper and iron elements used by Google products.

Complete build chain

Build your app using a suite of gulp tasks that leverage the full range of Polymer-related tools, such as vulcanize, crisper, and more.

Testing made easy

Test your app and all of its components using the built-in and pre-configured Web Component Tester.

Flexible app theming

Easily theme your entire application, including the built-in elements, using app-level Custom CSS Properties.

Framework-free, or framework-compatible

Build your app out of elements, or wire in an external framework to handle business logic. It’s up to you!

Responsive app layout boilerplate

Start off mobile-friendly with the included layout boilerplate.

Live Browser Reloading

Reload the browser in real-time anytime an edit is made, without the need for an extension.

Material design ready

Use the built-in paper elements to create a full material design-style app.

Holly shit batman, that’s a lot of features.

But wait, it’s not a JS framework ?

No, those are Web Components, 3 years have passed and now the thing seems to be ready for everywhere.

Polymer Project

and toward the end of the page

Oh yeah this thing definitively seems ready and Google is even pushing for it.

And then you discover their Github and their Catalog, and you think that those Web Components are a pretty good deal.

But wait … wait… wait… what does he leave us with Angular and React ?

first you really want to know what is the difference between Polymer and Angular
Here’s the difference between Polymer and Angular

So you investigate a little more and find this blog post (yeah it took a long time to arrive there)

Why Angular 2 Is DOA
(eg. DOA = Dead On Arrival)

and now all the quote will be from JS dev, and well … you can see that no everyone agree

I have seen and heard some ambitious things being said about Angular 2. It appears as though everyone is making the assumption that because the Angular brand is so well known and people are falsely under the impression it is a first-class Google project (even though Google offers no support).

Same here, everything I heard show Angular 2 as the next big thing by Google (had no idea it was not supported which is already a big hint).

Just because Google provide some resources for the Angular project, they have another conflicting library called Polymer which they seem to be pushing for quite hard, even more-so than Angular 2. I am not saying that Google is snobbing Angular because apparently a few applications internally already are using it, but publicly Google’s stance seems to be very much pro-Polymer.

wait a minute… conflicting ? are not the two supposed to work with each other ?

I think once upon a time the words, “Google quality” carried some weight, but historically Google have shown they have no qualms chopping something (like the beloved Google Reader) if it does not align with their agenda or business.

I use Google products a lot, gmail first and many many more, but that’s true
when Google decide to kill a product they don’t really hesitate.

Some products I could not give a shit like Google Wave, but many others that I miss dearly like Google Reader, Google Code, etc.

When you see that Angular is under the same fate … honestly you can seriously and legitimately worry.

But there is one problem that Angular 2 did not address. The one pain-point of the original framework, which while did not hinder its success, was definitely a point everyone mentioned in most articles written about it: learning curve.

that’s not the only one, sure you go on the learn Angular 2 in 5mn tutorila and spend a couple of hours instead, not because you’re stupid, not because you’re new at JS, but because of all the tooling, the setup, the specific way to do things etc…

I can easily argue that if you’re writing Angular 2, you’re not writing JS.

moving on

Even though Angular 2 treats TypeScript as a first-class citizen and like other frameworks, utilises features and API’s in ECMAScript 2015, it still suffers from a bad case of over-engineering.

And sorry JS guys, but when you see the massive adoption of TypeScript
and how close the syntax is to ActionScript 3, which by the way is ECMAScript 4,
you are really wondering about why many years ago the TC39 committee decided
to kill ES4 in favour of ESNext … it is obvious that JS dev want types.

The complexity of the templating language is enough to make me quiver. There is nothing intuitive about Angular 2’s templating syntax and after all of the complaints people had with the confusing terminology and abstraction in the original version, you would think that the Angular 2 team would have wanted to take a more intuitive approach to its design.

The truth of the matter is, there was a massive discussion on Github about this. You can see Rob Eisenberg (who was on the core team for a few months) now working on his own framework Aurelia, proposing a very reasonable templating syntax that closely follows Javascript. Unfortunately a confusing and VERY ugly looking syntax using a weird combination of rounded () and square [] brackets was used, as well as asterisks.

Honestly, I want to use Angular 2, but reading this make me want to not to even try.

Let be clear, I did try stuff like Knockout/Backbone/etc. and their downfall was the complexity of the templating which turned in a lot of bloat …

Why on earth would I trade bloated JS framework for another ?

side note: I’m still wondering why all the browsers did not implement E4X,
I mean XML -> SGML -> HTML, who would not want something like E4X ?

see “massive discussion on Github”: Angular 2 DOA

with this interesting little nugget

This has been clarified several times on several channels already. The way A1 was build doesn’t allow to get the benefits, features and performance A2 needs to bring to the table.

so A1 was not performant ? well… at least not enough.

You think I’m unfair towards Angular ?
let’s be clear we’re not talking about a small JS framework build by a motivated guy in his basement (and there is nothing wrong with that)…

we’re talking about a JS framework with the full strength of Google Engineering behind it, if you watched the video “TypeScript and Angular 2”, those guys not only build their own compiler (remember closure compiler) but they can also talk directly to the engineers at Microsoft who work on the TypeScript compiler and ask features …

anyway let’s continue

Compare the getting started setup for Angular 2 to Angular 1 and a library like React. Considerable tooling is required to work with Angular 2 which to be honest is nothing new for a modern front-end web application.

no kidding … not even mentioning the irony of people choosing JS because it is the only language available in the browser … but now everyone use a transpiler

It definitely takes more than 5 minutes to get everything setup once you factor in things like NPM 3 is slow as fuck and slower network connections mean dependencies take longer to download, even Aurelia can fall into this trap. This is where React has the advantage over most modern frameworks in that it requires no tooling and has the fastest setup time of anything else out there currently.

I realise React is being thrown around a lot here and I am well aware that React is first and foremost a library, it is not a framework. However, React is being used for the same purposes as frameworks like Angular are and therefore, it is a framework by association (in my opinion).

At that moment, I was like “oh if Angular 2 is not the solution, that’s OK I will just use React”, I’m sooooooooo naive …

so after long paragraph about who was there first (which imho does not matter at all)

the author end with

So while some have high hopes of Angular 2 becoming just as popular as Angular 1 did, I doubt it will happen. The simplicity of React for me personally is more appealing, I never have to look at any kind of documentation when I use it, but if I do, the documentation is great. And as many of you know, I have been working with Aurelia for nearly a year now and love it (I even use it with React).

I don’t wish harm on Angular 2, but I think some serious poor decisions and the fact it took so long to just release a beta, the odds are not in their favour. Everyone who isn’t still using Angular 1 or waiting for version 2 has since moved on to use React or other libraries/frameworks that have released and matured in the time.

At that point, I was more or less in the situation, my high hopes for Angular 2 were gone, and I was about to look into “React vs Polymer” see which one has more chance to not be killed in the next couple of years.

And then I read the comments LOL

here we go

The biggest mistake in Angular 2 project was they’ve dropped Eisneberg and his brilliant ideas. Now things are complicated so much that spaghetti is a boilerplate, syntax is just stupid, and it creates a lot more problems rather then solving while developing large SPA. Aurelia is emerging and making Angular 2 look really poor.


The fact that google made or use something really means squat huh?
I mean they still use Dart, GO and a few other things internally but externally no one seems to care.
But really, you wonder if they care about anything past 6 months….sorry you had 6 months, didnt become the next sliced bread, so lets try something else.


Brian B
Any thoughts on using React/Flux for a full SPA? I was thinking that React is really targeted to individual components that need to be very performant, but it seems like React is looking to be a standalone framework now. Is this trying to fit a square peg in a round hole, or would this be a viable option for an enterprise SPA?


Brian if it’s a long term project i won’t put any money on React they are still on early pre-alpha 0.14.5 and changing stuff every day and only fb internals knows what is going on there. When it will be stable 1.0-RELEASE then it will be a real game changer.

oh React is not v1.0 stable ?

I think your article is not valuable. I tried React and now I’m trying Angular 2.0 – I don’t agree with you. React is already more than year and it’s NOT stable. Also I agree with “papasound” thoughts about React: “When it will be stable 1.0-RELEASE then it will be a real game changer”. But it will be too late because Angular 2 is already in beta.

oh Angular 2 seems more close to v1.0 stable than React
but wait … Polymer is the one who have less chance to be killed by Google


Thanks for the comment Aro. It sounds like your experience might differ from others and you are entitled to disagree. I am not actually sure if you have used React, it is quite stable. I’ve built 3 applications with it and they are production applications. The release tag is irrelevant to the state of React in my opinion. It is more of a confidence and feature set thing than stability.

All software can be improved, not even Angular 2 in its beta state is any more or less stable. Your comment really makes no sense because you say it is too late because Angular 2 is already in beta, like the beta tag means it is stable. I think tags are irrelevant. Google’s Gmail was famously in beta for like 5 years and nobody ever had an issue with it.

As of React 0.14, Facebook consider it to be production stable as per this post. They say the following in the opening paragraph:

As with all of our releases, we consider this version to be stable enough to use in production and recommend that you upgrade in order to take advantage of our latest improvements.

No offence to the Angular 2 team, but it took them almost two years to release a beta. They rewrote it so many times, kept changing direction and scope as well. Although React is smaller, it is by no means any less complex in terms of code complexity. The team working on React over at Facebook are incredibly talented and Facebook use this themselves further bolstering confidence in it being production stable.

So React is more stable than Angular 2 ?


React requires “no tooling”?

With Babel 5 maybe. But Babel 6 has dropped its browser.js inline transpiling tool. So it looks like React does require tooling now.


React has the most broken ecosystem in the world, there are like more than a dozen implementations of Flux and you say the stack is stable?

At least one of the guys that started React has left and has created yet another micro framework to handle the shitty React syntax. You have giant switch statements, that look like old Pascal code, etc…

React is far, very far from being perfect as is Angular or any other framework.

Be objective bro! Compare code, measure shit, benchmark it, state your case. Your article is clearly Troll fodder… and they are coming the Troll Wars are coming, hundreds, maybe thousands of Angular 2 vs React…

So sick of this shit, there is no perfect solution use what you think is best without needlessly bashing other shit.

well bro, I really try hard to be objective but so far it look like a huge mess


I disagree. I prefer Angular 2.

thanks that help a lot (completely ironic)


I have tried angular 2 for a few hours and I could not get started with a single small example. It’s seems very difficult to me. And the fact that I can not migrate my old Angular 1 apps to Angular 2 has made me change to React.

ah! exactly what we learned from Ruby
if you want to change some part of your app and the part is a little too big
then you may as well change the whole framework


you may also join the discussion here

which lead to

OMG did that just happen ?

it’s like the vicious circle of the ultimate death, you follow an article, follow the comments, to end up where you started: no fucking solutions.

So, what conclusion ?

I already wrote about it before The current state of JavaScript language

it just does not seem fucking ready…

So far, the only thing that seems not being a complete nightmare is to go with Polymer and progressive enhancement, but if you do that you don’t really write a JS app, you write HTML with some bit of JS this and there, like you were doing many many years ago with good old HTML and jQuery.

And do that I will personally use ActionScript 3 server side to render Web Components client side, not because I absolutely want to use AS3 (well… little :wink:) but because it seems the most sane thing to do.

I have no time to cargo-cult following this or that framework build by this or that big player, give me a couple of choices that make sense and I will go with that and build apps, don;t give freaking 1000s of choices that get killed the next month and replaced by another 1000s choices, it’s been 5+ years going, WTF JavaScript ???

Chrome dev summit 2017 keynote

In short,

they dropped E4X, and then people invented a E4X like syntax.

they dropped classes, and then people got classes.

they never mentioned Flex, but Custom Elements is on the way.

they never mentioned SWF, but WebAssembly is being incubated.


that’s another way to put it but yeah

the thing is even with “all that” there is still not a clear path to follow


a little followup as something interesting recently happen

Jeremy Keith posted on his blog about
Regressive Web Apps

Not only he is pointing out (rightly so) the security nightmare waiting to happen
with the Android Instant Apps

Peter has looked a bit closer at Android Instant Apps and I think he’s as puzzled as I am. Either they are sandboxed to have similar permission models to the web (in which case, why not just use the web?) or they allow more access to native APIs in which case they’re a security nightmare waiting to happen. I’m guessing it’s probably the former.

Where we can see that at Google there is a duality between “App” and “Web”
and so he explains this “new shiny thing” PWA (Progressive Web App)

Meanwhile, a different part of Google is fighting the web’s corner. The buzzword du jour is Progressive Web Apps, originally defined by Alex as:

  • Responsive
  • Connectivity independent
  • App-like-interactions
  • Fresh
  • Safe
  • Discoverable
  • Re-engageable
  • Installable
  • Linkable

A lot of those points are shared by good native apps, but the first and last points in that list are key features of the web: being responsive and linkable.

plenty of interesting things mentioned and later in the post he talks about Polymer

Alex pointed to as an example of a Progressive Web App that is responsive as well as being performant and resilient to network failures. It also requires JavaScript (specifically the Polymer polyfill for web components) to render some text and images in a browser. If you’re using the “wrong” browser—like, say, Opera Mini—you get nothing. That’s not progressive. That’s the opposite of progressive. The end result may feel very “app-like” if you’re using an approved browser, but throwing the users of other web browsers under the bus is the very antithesis of what makes the web great. What does it profit a website to gain app-like features if it loses its soul?

previously you could see I was going to focus on Polymer instead of AngularJS, but even if I still “play with it” I’m less and less convinced that this is the future.

First, as a developer, it is quite stupid to focus only on Polymer and not also study Angular, simply because all the dev job offer out there are either for Angular or React, but I don’t see much for Polymer.

Second, the example above illustrate that Polymer use the same logic as SPA (Single Page Application), even if you could put it into the PWA (Progressive Web Application) category.

I do believe that progressive web app are better, but if the end-result is a “blank page” because the browser is not supported or the JS polyfill is not supported …well you bet it is not progressive at all.

So let me just make this little correction: study all the 3 things Polymer / Angular / React because it is what is “a la mode” but really I do expect those 3 things will change again within the next 2 years, so yeah I study/learn them but I don’t invest that much time in them as I’m pretty sure they gonna be replaced one way or another.

Anyway let’s continue with the blog post …

Here’s another example of the cargo-cult imitation of native. In your manifest JSON file, you can declare a display property. You can set it to browser, standalone, or fullscreen. If you set it to standalone or fullscreen then, when the site is launched from the home screen, it won’t display the address bar. If you set the display property to browser, the address bar will be visible on launch. Now, personally I like to expose those kind of seams:

The idea of “seamlessness” as a desirable trait in what we design is one that bothers me. Technology has seams. By hiding those seams, we may think we are helping the end user, but we are also making a conscience choice to deceive them (or at least restrict what they can do).

Other people disagree. They think it makes more sense to hide the URL. They have a genuine concern that users will be confused by launching a website from the home screen in a browser (presumably because the user’s particular form of amnesia caused them to forget how that icon ended up on their home screen in the first place).

Remember when you were producing some SWF applications and “HTML people” were busting your balls for things like “it does not respect the back button”, “the navigation does not reflect in the URL”, etc.

Well… look what we have here, on one side a bunch of “HTML people” who want to display the URL as they consider themselves in the “Web” group, and on the other side another bunch of “HTML people” who want to hide the URL as they want to be part of the “App” group.

Oh… and did I mention that every single thing that have been criticized about “Flash app” have ended up in the Single Page App ?

When ppl dev a SPA, sure the tech is HTML5/JS but the app does not respect the URL, they use the “route” behind the hash tag (exactly like many Flash/Flex apps were doing)
and many other things in common like not being able to use the back button.

Anyway, it sure does feel strange to know that there is a group of HTML5/JS dev who do not want to show the URL and want their HTML app to behave like a native app, and in fact it goes pretty far.

Fair enough. We’ll agree to differ. They can set their display property how they want, and I can set my display property how I want. It’s a big web after all. There’s no one right or wrong way to do this. That’s why there are multiple options for the values.

Or, at least, that was the situation until recently…

Remember when I wrote about how Chrome on Android will show an “add to home screen” prompt if your Progressive Web App fulfils a few criteria?

  • It is served over HTTPS,
  • it has a manifest JSON file,
  • it has a Service Worker, and
  • the user visits it a few times.

Well, those goalposts have moved. There is now a new criterion:

  • Your manifest file must not contain a display value of browser.

Chrome developers have decided that displaying URLs is not “best practice”. It was filed as a bug.

A bug.

Displaying URLs.

A bug.

That’s quite hilarious when you think about it :smile:

And then the blog continue with even more interesting things.

But off course, this blog got some answer and in particular this one

by Alex Russell,
(a developer working on Chrome, Blink, and the Web Platform at Google)
Not The Post I Wanted To Be Writing…

That last point is the high-order bit for me. Like Jeremy, I’m agitated over the lack of access to URLs for PWAs launched in a more immersive mode. That seems to be the thing to be frustrated about if you care about URLs and sharing and it’s what I’ve personally been concerned about.

In fact, I’ve been so concerned that our team prioritized it this quarter. New UI and gestures are hard to get right which is why I’m excited that Owen and Rebecca have been looking into how to make URLs accessible to PWA users no matter what display mode they’re in. We’ll have more to show on this front soon.

This matters because URL sharing is the proto-social behavior. It’s what enabled the web to spread and prosper, and it’s something we take for granted. In fact, if you look at any of my talks, you’ll see that I call it out as the web’s superpower.

Yeah URL does matter a lot and I’m happy to see that some people at Google do not want to “kill the URL”.

But all this raise this very very interesting problem:

what if we could have something to make apps that work inside the HTML
but can not be confused with the semantic of the HTML itself,
a kind of “box” that would wrap your app …

Oh wait, I think I just defined “again” the Flash Player plugin.

I don’t have the perfect solution or answer to that, but I think the main struggling point of all those HTML5/JS frameworks that try to act as native app inside a Web world is that there is no way to separate the web document from the web application.

They may realise after few years that having a plugin like Flash was maybe not so bad an idea.

Remember how the Flash components evolved over the years ?
I can see a lot of the same with the “web components”,
they try something, it does not work, they change the way to do it, etc.
and every year you have a new way to build components …

anyway … food for thought :slight_smile: