Js Next A Managers Guide
Js Next A Managers Guide
2n
n
Aaron Frost
o
iti
Ed
JS.Next:
A Managers
Guide
Short. Smart.
Seriously useful.
Free ebooks and reports from OReilly
at oreil.ly/webdev
When you strive to comprehend your code, you create better
work and become better at what you do. The code isnt just
your job anymore, its your craft. This is why I love Up & Going.
JENN LUKAS, Frontend consultant
KYLE SIMPSON
UP &
GOING
Upgrading
to PHP 7
Davey Shafik
Static Site
Generators
Modern Tools for
Static Website Development
Brian Rinaldi
2016 OReilly Media, Inc. The OReilly logo is a registered trademark of OReilly Media, Inc. D1814
SECOND EDITION
Aaron Frost
First Edition
Second Edition
First Release
The OReilly logo is a registered trademark of OReilly Media, Inc. JS.Next: A Manag
ers Guide, the cover image, and related trade dress are trademarks of OReilly Media,
Inc.
While the publisher and the author have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the author disclaim all responsibility for errors or omissions, including without limi
tation responsibility for damages resulting from the use of or reliance on this work.
Use of the information and instructions contained in this work is at your own risk. If
any code samples or other technology this work contains or describes is subject to
open source licenses or the intellectual property rights of others, it is your responsi
bility to ensure that your use thereof complies with such licenses and/or rights.
978-1-491-92019-0
[LSI]
Table of Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1. You Cant Afford to Avoid ES6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Innovation Debt
Direction of the Industry
Recruit and Retain Top Talent
Efficiency
The World Is Changing
2
4
7
8
9
2. ES6 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
History in the Making
The Meeting
Harmony
11
12
12
3. Features Explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Arrow Functions
Let, Const, and Block Functions
Destructuring
Default Values
Modules
Classes
Rest Parameters
Spreading
Proper Tail Calls
Sets
Maps
Weak Maps
17
18
18
18
19
19
20
20
21
21
21
22
iii
Generators
Iterators
Direct Proxies (and Supporting Features)
String Literals
Binary Data
API Improvements
Unicode
22
23
23
23
24
24
24
4. Where to Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Incidental Functionality First
Graceful Degradation
Train Your Teams
Using a Transpiler
Microsofts Enterprise Mode
Summary
25
25
27
27
28
29
iv
| Table of Contents
32
32
33
33
Preface
vi
Preface
CHAPTER 1
The remaining sections in this chapter will cover various reasons for
adopting ES6 into your current and future projects. Although not a
complete list of reasons, it should help show that in the long run, it
will cost more to avoid ES6 than to embrace it.
Innovation Debt
When talking about debt in software development, most people will
talk about technical debt. Technical debt reflects the imperfect and
sometimes dangerous state of your code and processes. As deadlines
approach, optional features and maintenance time can get cut from
the schedule. Without enough time to properly maintain code and
processes, you will inevitably have to watch as your technical debt
grows. Increased technical debt is something that all teams, except
perhaps those with infinite resources, face regularly.
There is, however, another type of development debt that is con
stantly accruing: innovation debt. The term comes from Peter Bell,
an amazing author, speaker, and innovator. Peter provides a concise
definition:
Innovation debt is the cost that companies incur when they dont
invest in their developers.
Like technical debt, innovation debt can spiral out of control if left
unchecked, possibly threatening the existence of the company.
If you have time, please visit Peters blog and
read his full explanation of the definition.
Imagine your CEO tells you that she needs a new and modern app
(that your team doesnt know how to build), built with very modern
tools (that your team doesnt know how to use), and deployed using
very modern build tools (that your team doesnt know how to con
figure). What would you say? Given the state of your team, what are
the odds of getting it done right?
Consider your current technology stack, code base, feature set, and
business goals with their new target feature set. Now think of all the
training and practice that your team will need before you can create
those target features. Consider your competitors feature set and
how fast they are gaining on you, or how fast you are falling behind
them.
Innovation debt is the cost you have to ante up before you can begin
innovating again. Many teams keep their innovation debt managea
ble and may be able to train up a few of their current members to
help bring the team back on track. However, some teams have
accrued so much innovation debt that they have to hire new
employees, with a new and different skill set than their current team.
They hope that these new employees can pull everyone else up to
speed. In extreme cases, such teams may even plan for these new
team members to replace their current team. As innovation debt
increases, the ability to avoid extreme decisions decreases.
So how do you pay back innovation debt? Better yet, how can you
prevent innovation debt from increasing on your teams?
The answer is simple: teach your teams what they need to know so
that they can innovate, and then let them practice it in the
workplace.
Make time for your team members to learn and practice these new
skills. Trying to pay off large lumps all at once can be too costly in
the short term. Taking multiple iterations and cycles to train your
teams is difficult to sell to your customers, whereas smaller and
more consistent bites can be much easier to swallow.
While the how to pay back may seem most important, I think that
the when to pay back is even more important. The when is now.
Starting today, pay back small amounts of innovation debt on a reg
ular basis. At least once per quarter we should all be taking strides
toward paying back innovation debt.
Lets bring this back to ES6 now. Dropping ES6 into your current
project can seem like a tough challenge, but it may prove to be your
strongest ally. The ES6 release is not a minor upgrade to the lan
guage. It is a significant upgrade and improvement. And the new
constructs and syntax in ES6 will enable your teams to make more
progress faster than they ever have. Here are some tips on how you
can help your team to catch up on ES6:
They will need time to learn it, even those who are already skilled
JavaScript developers. If you dont dedicate enough time to learning
and training on ES6, your teams will struggle. Create goals around
learning ES5/6 and other modern JS libraries/ frameworks. Projects
Innovation Debt
like Angular, Grunt, and IOjs are a few that I am partial to. An
ambitious few may even jump into server-side JavaScript, such as
IO.js and Nashorn. Make sure your teams have the resources they
need to learn the latest technologies. Then ask them to implement
those technologies to help reduce the technical debt. Lead from in
front instead of from behind. Help lead the way by regularly sched
uling team training. Even if they are simple, informal meetups,
make time for the team to sit down and talk about what the next
steps are.
Do what you can to create a healthy culture on your team, one that
harbors innovation. For example, at a past job, we ordered 100
Angular iron-on badges. We handed those out to engineers who
released an Angular app into production. At our internal monthly
JavaScript meetup, we ceremoniously handed out the Angular
badges to those who released their app since our last meetup. We
were surprised by the results. Many of those badge winners were on
teams that we never expected to adopt such modern and fun frame
works. It was encouraging to see the team members innovate and
learn something new. Nowadays, you can spot these badges all over
the building, each one a reminder of our goal to continually
innovate.
Microsoft
Beginning in August of 2014, Microsoft began implementing pieces
of its strategy to revive its in-house browser, Internet Explorer. The
company appears no longer impartial about how long people use
outdated versions. Not only did it point out that updated browsers
decrease online risks, it also pointed out that stale browsers frag
ment the Web and decrease productivity. Along with these claims,
Microsoft announced that starting on January 12, 2016, it will only
support the most recent version of IE available for your operating
system. This means that a consumer running Windows 7 SP1 will
need to be on IE11 in order to continue receiving security updates.
On January 21, 2015, Microsoft announced that their new operating
system, Windows 10, will be a free upgrade for anyone running
Windows 7 or newer (you need to upgrade within the first year).
Further, all subsequent updates will be free. Further, they announced
that Windows 10 will include a new browser (currently called
Project Spartan) that will be updated independently of the operating
system. In March of 2015, Microsoft announced that IE will no
longer be the default browser on Windows and that Project Spartan
will take over in Windows 10. This means that the Microsoft
browser of the future will be evergreen.
Microsoft is taking some aggressive (and expensive) moves toward
helping users avoid an insecure and outdated Internet experience. If
Microsoft is abandoning support for oldIE, then what business do
we have supporting it?
Google
The king of search, Google, has a similar support strategy. On its
help and support page for sites such as Google Apps, Google spells
Direction of the Industry
out its policy for supported browsers. It supports the current and
previous version of all major browsers. In its documentation, the
company explains its reasoning:
At Google, were committed to developing web applications that go
beyond the limits of traditional software. Our engineering teams
make use of new capabilities available in modern, up-to-date
browsers. Thats why we made the decision last year to support only
modern browsers, which also provide improved security and per
formance.
Rather than spend money to help people limp along in their out-ofdate browser, Google opted to spend money innovating and gaining
a competitive edge by building websites that go beyond the limits
of traditional websites.
Kogan.com
One last example of the direction of the industry demonstrates inyour-face boldness.
An Australian electronics store, Kogan, took a strong stance against
stale browsers. As of June 2012, any shopper checking out in IE7 or
lower will be charged a special IE tax. The IE tax rate is 6.8%, which
is 0.1% for each month since Microsoft released IE7 and the date
Kogan.com rolled out its IE7 tax feature. The following is Kogans
explanation to the user about the IE7 tax:
Conclusion
The industry as a whole is largely on the fence with regard to aban
doning stale browsers. However, two of the biggest movers in the
game (Microsoft and Google) are herding people to modern brows
ers. With that, they are saying: When faced with spending your
money on stagnating to support oldIE or innovating and building
the apps of tomorrow, always bet on tomorrow. It will help you
retain a competitive edge and keep your teams sharp.
Additionally, you should make an informed decision when deciding
to prune support for legacy browsers. If you are setup with a web
analytics platform, look at the data to find out what percentage of
your users are on these old browsers. You may be surprised with
what you find. While management wont easily prune support for an
unknown number of users, you will find that people are much more
willing to move forward with a decision when you provide them
with current and past browser usage statistics for your company.
Once you know the statistics, everyone can make a more informed
decision with regard to moving forward with the Web.
Please check your pulse. If reading this section has raised your heart
rate, no worries. Recommending that you drop support for Internet
Explorer can have that effect. If this is you, go ahead and skip to
Chapter 4 and read Graceful Degradation on page 25 and Using a
Transpiler on page 27. These offer serious solutions that will allow
your team to use ES6 without completely abandoning IE users in the
process.
Efficiency
The term efficient code can have a few different meanings. The
many new features in ES6 can each be categorized as satisfying one
or both of these definitions.
The first is: does it run efficiently? If I write code using the new ES6,
does it run faster than code written in ES5 and earlier? Many of the
8
Moving away from heavy oldIE support may be met with resist
ance. Transitioning your web architecture from server-side templat
ing to a heavy, frontend templated JavaScript solution may also be
met with resistance. You may even be the one resisting. Those who
have seen success in the past tend to think erroneously that their
one road traveled is the only road worth traveling. As Drucker sug
gests, proposing alternatives to tried methods is often rejected as
unsound. Drucker refers to this as a myth of management, a myth
that we can help overcome.
10
CHAPTER 2
ES6 Goals
The Meeting
Opera hosted the TC39s monthly meeting in Oslo, Norways capital.
There were two different camps fighting for control of the next
ECMAScript update. One camp had proposed a smaller update
under the release number ES3.1. The other camp wanted a more
robust release, full of features that hadnt reached a group consensus.
This second, larger release was dubbed ES4. And this had been the
debate for months: whether to choose the smaller ES3.1 release, or
the larger, feature-rich ES4. Unlike the previous meetings, these two
sides would reach a compromise. ES4 would be postponed, and
ES3.1 would become the next release. However, because the group
had torn down their walls and made new alliances, they changed the
release number from ES3.1 to ES5 to account for those milestones.
The final ES5 specification was approved in September of 2009, with
a follow-up release 5.1 landing in June of 2011. This marked a huge
step forward for browser vendors. Progress and standards prevailed,
and JavaScript was again moving forward with new features. This
was all very cool.
Harmony
What about all the ES4 features that no one could agree upon?
Where did they end up?
A super-majority of the ECMAScript proposals fell into this bucket.
In August 2008, Eich addressed the TC39 and let them know that all
remaining features (ES4 and beyond) would be grouped into a col
lection labeled Harmony, a tribute to all the committee members
that harmoneously came together to help move the language for
ward again. In his email, Eich outlined a list of goals for the Har
mony features. A few additional goals have been standardized since
12
then, and they can be found on the ES Harmony wiki. The goals
include:
1. Provide a better language for writing
a. complex applications,
b. libraries,
c. and code generators targeting the new edition.
2. Switch to a testable specification.
3. Improve interoperation, adopting de facto standards where
possible.
4. Keep versioning as simple and linear as possible.
5. Support a statically verifiable, object-capability secure subset.
These goals still guide TC39 today.
Complex Applications
As JavaScript began, the engineers pioneering its adoption had only
a fraction of the ambition that we demand from JavaScript. What
started as a very simple scripting language has grown into the most
used language development language on the planet, appearing in the
browser, on our servers, and event-powering robots. JavaScript
needs features that allow for less coding while producing more
functionality.
Libraries
Any given page on the Internet may have dozens of JavaScript
dependencies. As a JavaScript project becomes larger, the task of
library and dependency management increases in difficulty. Harmony
has a handful of features that will provide a better experience for
library builders and app developers alike.
13
Harmony
15
CHAPTER 3
Features Explained
Arrow Functions
When JavaScript programmers talk about what this means in Java
Script, you may feel like youre watching Whos on First? For those
who are new to JavaScript, understanding what this is can often
prove difficult.
What better way to provide clarity than to add yet another meaning
for this? Arrow functions are a new syntax that allow developers to
manage their scope differently than before, providing yet another
value for this.
While that may sound confusing, arrow functions will help make
JavaScript code more readable. When using arrow functions, your
code reads the same way that it will execute. The same cannot be
said for all usages of this. Such functionality will help make Java
Script code more readable and predictable for developers, which
translates into easier maintainability.
In addition to helping developers understand what this is, arrow
functions have some syntactic sugar that allows you to opt-out of
using the function and return keywords throughout your code.
17
Destructuring
As you pass data around inside your apps, you will invariably need
to pull pieces of the data apart to examine them individually. The
task of pulling data apart is also referred to as destructuring, because
you are taking the datas structure apart. Prior to ES6, programmers
were required to be fairly verbose while destructuring their data.
ES6 destructuring allows you to perform the same task of taking
your data apart with a lot less code.
Default Values
Toward the top of many JavaScript functions there is code that veri
fies that all incoming parameters have a value and are not left unde
fined. Unwanted undefined values can create hard-to-find bugs in
code. ES6 default values allow you to elegantly verify and provide
default values for each of your parameters. It has always been possi
ble to catch these undefined parameters and trap them before they
make a mess; however, the new default values syntax simply makes it
much easier. Many other modern languages have this feature.
18
Modules
Prior to ES6, JavaScript had two main competing module systems:
AMD and CommonJS. Neither is native to the browser: they are
monkey-patched into the browser at runtime. Both of these module
systems have different strengths. When it came time for the TC39 to
decide between the two, the committee decided to come up with yet
another approach for modules. The new approach is elegant and
covers an even wider spread of functionality then either of the
predecessors.
Modules, in general, solve several problems for developers. First,
they allow the developer to separate code into smaller pieces, called
modules. Second, they make it easy for developers to load (inject)
those modules into other sections of code. Having modules injected
like this helps keep project code uncoupled from the module (read:
improved testability). And third, modules can load scripts asynchro
nously. This means that apps can begin loading faster, as they dont
require all scripts to be loaded prior to executing code.
Under the current proposal, modules will provide features from
both AMD and CommonJS. In addition, ES6 modules have addi
tional pieces that dont exist in either of the others.
Classes
One of the easiest ways to reuse code is by allowing one piece of
code to inherit the functionality from another piece. This way, both
pieces of code have the same functionality, but the code only gets
written once. By using an inheritance chain known as prototypes,
JavaScript has always been able to share code this way.
While prototype chaining works, most other object-oriented pro
gramming languages use a variation of class-based inheritance to
share functionality from one piece of code with another. Starting in
ES6, you will be able to define and inherit functionality by using
classes as well as prototypes. The syntax to share code using classes
is much cleaner than its equivalent in prototypical code sharing.
This is a polarizing feature among JavaScript developers. You wont
find many developers who are on the fence with regard to classes in
JavaScript. They will either like it or dislike it.
Modules
19
As I see it, classes have two main advantages. First, classes add some
syntactic sugar to inheritance in JavaScript. This means that inheri
tance in ES6 will be more straightforward, and the code will be eas
ier to follow. Further, languages that compile to JavaScript will be
able to do so more easily and exactly. Second, once classes have
completely replaced traditional prototype-inheritance, regular func
tions will potentially have a smaller footprint in memory.
Rest Parameters
The term rest frequently refers to REST, a common pattern for
writing web services. In the context of the ES6 release, rest has
nothing to do with a web service.
Many other modern languages allow you to make a method that
takes a dynamic number of parameters. Consider a function called
add. It may need to add 2 numbers together; it may need to add 100
numbers together. Suppose that at times you need to add two num
bers together, and at time you need to sum three numbers. You
wouldnt want to write two different add functions to accomplish
this. ES6 rest parameters now give JavaScript the ability to have
functions that accept a dynamic number of parameters.
Previously in JavaScript, if you wanted to pass around a dynamic
amount of numbers, you had to put them inside a container, like an
array. Rest parameters allow you to just pass the numbers, without
jumping through the hoop of manually wrapping them in a
container.
Spreading
Arrays are just linear collections of objects. They could be a collec
tion of numbers, words, or even other arrays, for example. How can
you get things out of the array once they are there? Looking back
ward, you always had to reference each of the items one by one. This
always worked; however, it tends to be a bit verbose, not to mention
that the code can become cryptic. ES6 spreading allows you to easily
spread out the array, without all the mess.
20
Sets
JavaScript has has two very powerful containers: arrays and objects.
Arrays are lightweight containers. You can treat them like a queue or
a list, popping an object off the end, or shifting an object off the
front. However, there were some things that an array couldnt easily
do.
Prior to ES6, if you wanted to have an array without any duplicates,
you had to write your own code to prevent duplicates from being
added to the array. This duplicate-preventing functionality now
comes built in with sets. Sets are very much like arrays in JavaScript.
However, if you try to add the same value twice to a set, the set will
simply ignore the second attempt to add that value. With sets there
is now an easy way to have collections of unique values.
Maps
In other languages, we refer to maps as hashmaps or dictionaries. A
hashmap maps a key with a value. An example would be mapping
the key name with the value Freddie Mercury and the key
band with the value Queen.
JavaScript has had these hashmaps for a long time. In fact, JSON is
an entire data structure based on keys that are mapped to values.
21
Weak Maps
Weak maps are exactly like maps, with a few exceptions. The pri
mary difference is: weak maps can make cleanup easy.
Suppose you have a map and add a key that represents some HTML
element from your page. If that HTML element is ever removed
from your DOM, having a reference to that element in your map
prevent the browser from completely removing the HTML element
from memory. This is known as a memory leak. Because the map
still points to the element, the garbage collector will not remove it
and free up the memory that it was occupying.
Unlike a map, weak maps will let the garbage collector remove the
element from memory. If the only reference to the HTML element is
the key in the weak map, the weak map will release its reference as
well. Once all references have been dropped, you can then say good
bye to the HTML element forever.
Generators
Generators are functions that can be paused. By adding the keyword
yield inside our generator functions, the system will pause the exe
cution of code, return the value to the right of the keyword yield,
and wait until we tell it to continue. (Generators have been in Fire
fox for quite a while now.)
Generators have many practical uses. One would be generating
unique IDs. Each time you need a new ID, you could call genera
tor.next(). The generator would return the next ID and then pause
again. You could write your own for loops with generators, along
with many other features. I predict that generators will help library
and framework authors to produce more efficient code.
22
Iterators
In conjunction with generators, iterators offer enhanced support for
looping. If you have an object that is iterable, you may now use a
new for loop to iterate through that objects properties. The new
forin loops make it easier to go through an objects values. Prior to
iterators, you needed to reference each value by first referencing the
key and then using it to retrieve its values. Forin loops give us
direct access to the objects values.
String Literals
ES6 string literals fill multiple roles. One role is templating; another
is string interpolation. In the browser, JavaScript is often used to
glue together HTML, CSS, JSON, and XML. While there are many
client-side templating libraries out there, they will all enjoy what ES6
quasis have to offer.
String literals (referred to as quasis by some) will perform much
faster than any templating library could ever hope to. Additionally,
Iterators
23
Binary Data
The binary data enhancements in ES6 aim to provide some perfor
mance gains when working with binary data in JavaScript. APIs
such as Canvas or FileReader return binary data. By improving per
formance behind the scenes, these APIs will perform much faster at
runtime than they ever have before.
API Improvements
The Number, Regex, String, and Math global objects each has a
handful of improvements in the newest version of JavaScript. None
of the enhancements are major. Most of the methods that are new
are utility methods that many people have built on their own.
Unicode
Beginning in ES6, JavaScript will begin supporting UTF-16. These
changes will add better support for a wider range of less frequently
encountered characters.
24
CHAPTER 4
Where to Start
Its settled then. You are going to begin integrating ES6 into your
projects. Still, you may have some questions about where to start. Or
maybe you would like some best practices for your organization.
The following suggestions may make this transition easier.
Graceful Degradation
Some browsers have more capabilities than other browsers. Maybe
youve decided that you want to use some functionality that doesnt
exist in all browsers. In other words, your users will have a different
experience on your site, depending on their web browser. When
implementing different features for different browsers, there are two
competing ideologies:
25
Progressive enhancement
Progressive enhancement suggests that you begin by building
your site for the worst-case and most basic scenario. Once that
exists, you add functionality for the more capable browsers.
Graceful degradation
Graceful degradation suggests that you build your app for the
most capable browser. Once that exists, you find alternate func
tionality or turn off the functionality for less-capable browsers.
I recommend that you start out by implementing graceful degrada
tion. Allowing your team to focus on the best possible scenario will
produce the best possible experience for your customers. You may
then combine your best-case scenario using a transpiler (see Using
a Transpiler on page 27), pushing Microsofts Enterprise Mode (see
Microsofts Enterprise Mode on page 28), and/or traditional
monkey-patching. Combining these technologies may even enable
the worst of browsers to run the latest ES6 code.
Monkey-patching is the term used to describe the
act of modifying JavaScripts default behavior.
An example of monkey-patching could be
adding JSON.parse and JSON.stringify func
tionality into IE7. Because IE7 was released
prior to the explosion of JSON, it doesnt have
support for the JSON API. However, a handful
of libraries out there monkey-patch IE7 so that
it has JSON.parse and JSON.stringify function
ality. Monkey-patching is also known as duckpunching and polyfilling.
However, please do not shy away from shutting off different pieces
of your site to users who are on older browsers. As discussed previ
ously, herding your users to an evergreen (auto-updating) browser
will reduce your development and maintenance costs. Further, as a
member of the web community, we all have a duty to protect our
users. While modern browsers are much faster and more capable
than older browsers, that isnt why you should help your users
upgrade to a better browser. You should help them upgrade so that
they can use a browser that has the latest security patches and
updates. You should help them upgrade so that they can be safe.
26
Using a Transpiler
One of the quickest ways to get your team into ES6 is by using a
transpiler. With a transpiler, you write ES6 code, and it is then
turned into something that older browsers can understand. This
means that your teams can start using tomorrows syntax today.
This means that you can have your teams write this:
let add = (x, y) =>
x + y ;
and it will convert that into code that your users browser can
understand:
var add = function(x, y){
return x + y;
};
27
ever, I do feel that we should each let our biases go and accept pro
gress as such. Especially when it helps us move our organizations
forward.
One of the reasons that many corporate environments are stuck
using an old version of IE is because they have a few sites that dont
run well in newer versions of any browser. In almost all cases, these
are sites that they depend on. And rather than rewrite those sites to
work in modern browsers, they are more than happy to force all of
their network users to continue using IE8 or IE9. If this sounds like
your organization, or your customers organizations, KEEP READ
ING! There is hope.
One of Microsofts recent features that I think you should care about
is Enterprise Mode. Enabling Enterprise Mode on a Windows Net
work means that you can set up a list of certain sites that need and
depend on oldIE to function appropriately. Then, any network user
can open Internet Explorer 11 (or whatever the latest version is
when you are reading this) and IE11 will load those sites with an
older version of its JavaScript and HTML/CSS rendering engines. A
version that acts, thinks, and performs like oldIE performs. All other
sites will get to experience the Web through IE11.
Perhaps educating your network folks (or your customers network
folks) about the benefits and ease of use of Enterprise Mode may
afford you the freedom to upgrade your development process to
only include more modern browsers. If are like me, you know the
exact number of users that are still using oldIE. Fingers crossed that
Enterprise Mode, along with Microsofts support changes coming in
January 2016, will help us all move our projects into the future.
Summary
Every organization is different. Each team will need to set its own
pace. With innovation in general, constant progress is key. Aggres
sively seek out new opportunities to help your projects stay on track
with your innovation goals. The total reduction in costs for stand
ardizing on modern technologies will make your efforts worth it.
The age of oldIE isolation has already begun.
Summary
29
CHAPTER 5
As of January 2016, the list of possible features for ES6 has been fro
zen. Only the proposals that are already on the list may be included
in ES6. Any additional proposed features to ECMAScript will have
to wait in hopes of being included in ES7. Potential features for ES7
have already begun to appear.
JS.Next refers to the next version of the JS API.
Currently JS.Next refers to ES6. Once the ES6
release is live, JS.Next will refer to the ES7
release. JS.Next will always refer to the next
update to the language.
31
Object.observe
A popular feature in modern frontend JavaScript frameworks is
two-way databinding. Having two-way databinding makes life easier
on your developers. It allows them to focus on writing new code
rather than worry about keeping all the data in sync.
Object.observe makes two-way databinding easier than ever
before.
On any given JavaScript-assembled web page, the values on the page
represent some JavaScript variable in your code. Keeping those two
values (the page value and your variables value) in sync is impor
tant. Any time your users update the values on the page, your vari
ables are updated as well. Additionally, if you change the value of
your variables, you want the page to be updated with your changes.
That is two-way databinding in a nutshell.
We have already seen a handful of frameworks implement
Multithreading
One of the best things about JavaScript is that it runs in a singlethreaded nature. Because you can write code without worrying
about multiple threads, application development tends to be easier.
While this is a huge plus, it also present limitations. For example, if
any of your JavaScript code runs too long, your entire app will
appear to be frozen. Things like intense graphics can easily bring
your code to a halt. If JavaScript apps had a good option for running
code in parallel, on different threads, it would be a much more pow
erful language.
32
Traits
In many object-oriented languages, your objects share functionality
by inheriting it from parent classes. One of the alternatives to classbased inheritance is traits. By using traits, you define the functional
ity to be shared as a trait and then add the desired traits onto your
object. By adding a trait to your object, your object will absorb the
functionality of your defined trait.
Implementing traits provides another powerful way of sharing func
tionality. It can also reduce the risk of over-architecting traditional
class-based inheritance models.
33
Array comprehensions
Async functions
Typed objects
Invite your teams to keep their ears to the ground, listening for
more cutting-edge features that may appear in JavaScript.
34