Advancements in JavaScript further the frontend craft. Here are some advancements that I believe are important to us today.



## Rapid Spec Improvements

Hasn't it felt like there have been a lot of upgrades to JavaScript itself in recent years?  I feel like the TC39 committee, responsible for evolving the language and sharing a spec that vendors can build to has been very productive.  Browsers and Node.js are all tracking new specs quickly as well.  The [process](https://tc39.github.io/process-document/) seems to be working well.  It feels good to have progress.

The JavaScript language surface area is expanding.  Sometimes I pine for the days when a newb to JavaScript had fewer concepts to grok when first encountering code.  But on the whole, the additions and progress made have seemed worthwhile.

## Transpiling By Default

But not all JavaScript runtimes can keep up with the flood of new language development.  A mainstay in my JavaScript writing experience now seems to be [Babel](https://babeljs.io/).  Babel allows JavaScript transpilation, taking future-state JavaScript and rewriting it as current-day JavaScript that's interpretable by browsers today.  Never before have I or others felt so comfortable using features that are coming but not yet fully cross-browser compatible.

I have mixed feelings about JavaScript transpilation in the long-term.  In some ways, I hope it goes away.  But there are so many features yet to be adopted across major platforms that I see this as a necessity and a strong net-positive at least in the mid term.

## Type Support

As JavaScript projects get bigger and more complex, there seems to be more appetite for a strong type system in JavaScript.  I don't see this coming to the language itself, but who knows. The primo JavaScript flavor for typing is [flowtype](https://flow.org/).

This is welcome and feels like it makes apps better in many situations.  There are still situations, however, where I enjoy the ability to move quickly in JavaScript without first establishing the shapes of all required types.

The tooling here is getting better, but there's still much to be desired.  Typing requirements and error messages can be quite cryptic.

## Compile it All to JS

Is there a language today that doesn't compile to JavaScript?  The fact that is hard to answer with one or many examples is a testament to the fact that writing and deploying JavaScript is a valuable target.

There are many languages around the JS ecosystem that act as feeders for many of the ideas and language advancements that come to JavaScript.  Elm, Purescript, Typescript, Reason, and more. There is a lot of functional philosophy influence here.  They brings ideas for new, expressive syntaxes.

These are few advances that can be felt in the JavaScript language space.  Which developments have you had your eye on and feel are influential?

Advancements in JavaScript further the frontend craft.

Modern Frontend Dev: Language Advances

Modern frontend dev is enabled by growing browser capabilities.  There are many exciting things happening in browserland.  Here are a few that I care about.



## Offline Support

The new approach to handling offline support, embodied in [service workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API), is so much better than what came before.  It's now like you have a little router in the browser that you get to implement. It routes requests to where they should go during on- and off-line moments. It's a giant leap forward, and it's huge for creating web experiences that exist even when you're not connected to the Internet.

## In-browser Databases

We've had most of these storage options for a while now: local storage, session storage, and [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API).  But paired with newly-viable offline support, they are _way_ more compelling.  And improved APIs and capabilities, such as IndexedDB 2.0 are starting to land in browsers.

## WebAssembly

I think [WebAssembly](https://developer.mozilla.org/en-US/docs/WebAssembly) has the potential of changing the face of web development.  New, high-performance apps will be accessible over the Internet through browsers, continuing to evolving past the original document sharing network it all start as.  

WebAssembly also has the ability to change the source languages for the web. This will expand the number and kinds of programmers that are involved in creating the next generation of web applications and the form that these web apps take.

## Speed

Browsers are pretty snappy these days.  Vendors are constantly working to refine, enhance, or wholly recreate the engines that power the running of JavaScript, application of CSS, and the rendering of UIs.  You can require your apps to do a lot more and still be performant.

## Layout

New and interesting layouts are possible using specifications that are much more powerful and flexible than before.  CSS Flexbox is widely supported and we see a growing number of applications that can now respond to the wide-ranging form factors that web users come to the web within.  [CSS Grid](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout) is quickly spreading across all browsers, being adopted faster than about any significant CSS spec in the past.  

## Browser APIs

New and interesting browser capabilities are coming to fruition, some long years after conception.  The [web animation API](https://developer.mozilla.org/en-US/docs/Web/API/Animation) expands upon keyframe animations and transitions from CSS and brings that and more to JavaScript.  Support for the [payments API](https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API) has just started to land, allowing the browser to natively handle user payment information.  Mixed with a resurgence in talk around micropayments, this could change the way and the ease with which money is exchanged on the web.

## Language Support

Browsers are following the language advances in JavaScript itself, supporting more and more natively.  Native promises, es2015+ syntax, and new data types will allow the browser to do more with less.  As polyfills and runtimes diminish, bundle sizes will shrink, and certain API and data structure implementations should become more performant.

## Tooling

To enhance the developer experience, browser vendors are investing much in developer tooling.  Most noticeable is Chrome, which has a widening and deepening array of useful tools.  Debugging is top-notch.  New performance audits via Lighthouse are awesome.  I've also heard raving about the great animations panel in Firefox.  

Browsers are getting better.  They can do more.  Which of these advances or others are most important to you?

Modern frontend dev is enabled by growing browser capabilities.

Modern Frontend Dev: Browser Capabilities

What writing JavaScript looks like for a modern web developer.



I'll assume, for a moment that I'm that modern web developer.  Hopefully my profile is modern and webby enough.  We'll use my own experiences as a hopefully informative prototype of what writing JS in the modern web can look like.

## Bet on JavaScript

I like Eich, and I subscribe to the "always bet on JavaScript" mantra.  JavaScript is being shown to be a solid choice for building rich Internet apps.  The language and browser engines to run it are quite fast these days.  The language is pleasant and productive to write in.

JavaScript is in so many places!  Your skills are widely applicable, and you can build a variety of things if you're good at this language.  

## Using ES Next

I use Babel on almost all my projects, except for some Node projects.  We're in the middle of ES2017 right now.  This and last year's feature adds were a bit lack luster.  ES2015 of yore was an amazing leap.  We have some interesting features yet to come.  

These days I'm recovering stage-0-er.  Now I'm a reformed stage-2-er.

There are so many, but my favorite feature to come out of ES2015 is the module system.  It's a basic feature.  In most programming languages, modules are just assumed to be a thing.  With modules now in JavaScript, we can create better code abstractions and trace explicit dependencies.  Tooling gets better too.  I love that modules for JavaScript are coming to more places, including the browser.

A feature yet to come, object spread, is hopefully one you've been using for a while via Babel.  It's currently a stage-3 feature.  In the data manipulation that our code is largely about, it is very useful!  Its effects are possible via `Object.assign` today in all browsers but IE 11 and Konqueror. But the spread operator is more expressive and lends my mind to better solutions.

## Harnessing Npm

A package manager is a program that allows you to easily and consistently share and access 3rd party code. The Web's original "package manager" was code addressable by a URL that was loaded into a script tag and had code attached to the global object.

Today, to accommodate an increased number of app dependencies and code bundling, local package managers are common.  I use Npm for essentially all Web and Node projects.  I have avoided the Yarn train and have only sometimes wished for the feature set there.

## Preferring a Library

Today there are so many good library and framework options for organizing your frontend apps and gaining efficiencies there.  On the whole, they're all viable, so we're really down to developer preference when it comes to choosing one.

I reach for React.  It has a great mental model which has [changed the way I code UIs](/post/repainting-my-mind-with-react/).  It has great abstractions that support many use cases, and I feel productive in it.

## Trying Tools

Because I'm writing code in ES Next, I need some compilation tools.  I use Babel.  When bundling, I use Webpack, but I'm trying to avoid it when I can.  There's a lot of power there, but it can be over- and mis-used.

I'm not an avid linter.  Some rules are sometimes helpful.  But I don't miss them a lot when they're gone.

I'm a huge fan of using [Prettier to format your code](/post/format-javascript-with-prettier/).  It helps you keep your mind on the task at hand an not have to take "breaks" to think about formatting.

I'm using flowtype on a few projects, mostly where the domain model is complex or will expand.  It helps make me more sure about refactors.

## Just a Snapshot

Of course, what is here today can be gone tomorrow in a JavaScript frontend world.  So here are some observations about my current JavaScript writing mode.  Tomorrow I may write another article.  

What is your JavaScript writing experience currently as a modern, possibly-mustached frontend dev?

What writing JavaScript looks like for a modern web developer.

Modern Frontend Dev: Writing JavaScript

Increased user expectations are driving what modern frontend dev entails.



Here are a few things that the modern frontend web developer must concern himself with in order to make the applications that his users desire.

## Animations

Animations are now common place.  Animations help provide polish for your page, showing real care.  They help provide additional feedback that can help communicate intent about what's happening on your page.  They can dazzle and delight.  

Animations can also be overused.  Adept developers need to be judicious in their use and tasteful in the application of animations.  Smooth, no-jank animations is a standard expectation.

## Transitions

Transitions describe going from one state to another.  This might be from page to page, route to route, or it might be from one on-page state to another.  These transitions and states are growing increasingly complex.  

Users want feedback about where they are in transitions.  Placeholder content is often displayed before real data or layout is completed.  

Users want to avoid full page repaints.  Browser loading indicators and blinks of white remind the user of the request/response cycle of the web, and it's not in vogue.  Where possible, partial repaints and dynamic, even preloaded, content changes are preferrable.

## Speed

Users are more impatient than ever.  They are willing to wait for less time, and they have more things to do.  People have a lot of choice and alternative information sources and services are easily found.  Without quick, easy access to your application, users will choose something else. 

If your time to first paint runs long, you risk losing users before the page has even loaded.  Efforts to to decrease even the _perceived_ load time are worthwhile.

## Responsive design

Today's device form factors are almost unknowable.  There are many devices on the market and more coming all the time.  In today's market, you pretty much know that there will be a rectangular screen of pixels, and that's about it.

But when a user comes to your app, they'll just expect it to fit and to work.  Effort to make your app flexible and usable across a variety of viewports is expected.

## Unpixelated

Many of today's devices ship with high-density displays, where more pixels are being packed into the space previously used for one.  This leads to sharper text and imagery.  Now users expect it.

High quality typography is expected.  Images tailored to pixel density are common.  SVG, scalable vector graphics, are increasingly used to provide always-crisp visuals.

## Accessibility

More people than ever need to use the Internet.  It's expected that they'll all be enabled to use your applications.  More and more critical services and experiences have moved to the web.  

It's good to consider others' needs in the design and implementation of your applicatons.  Today, more and more companies and developers are showing their willing to pay that cost.

These are a few things that a user on the web today cares about.  What other expectations are there that drive modern frontend dev today?

Increased user expectations are driving what modern frontend dev entails.