Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

The Rise of JavaScript Frameworks – Part 2: Tomorrow

On this page:


frameworkIn Part 1 of this series I talked about the current state of JavaScript frameworks and how in many ways JavaScript frameworks have become the new baseline for developing client centric Web applications or Single Page Applications. Due to the complexities involved in building complex client side applications using JavaScript and HTML, frameworks have just about become a necessity to effectively building any non-trivial application. Frameworks are a huge help with organizing code, providing easy ways to bind data from models rather than binding data to the DOM manually with imperative code, providing tons of helper functionality for operations most applications need like view and nested view routing, form validation, http request management and tons of other features that every application needs but isn’t immediately obvious as a bullet point feature.

Version 1 of the major frameworks came about later than I would have expected them to, as there was a lot of pent up need to address the missing pieces. When these frameworks finally did arrive on the scene and got to a reasonably stable point, public interest took off like wild fire and adoption rates have gone through the roof since then. It’s not surprising – for me personally using both Angular and React I’ve seen myself being able to build complex front ends in a fraction of the time that it took previously.

Trouble in V1 Paradise

As much as the first round of frameworks have improved life for JavaScript developers everywhere, there are lots of warts in the V1 frameworks. Most of these frameworks started out as very experimental projects that  morphed into frameworks only after public interest inspired exploration of more general purpose functionality. Angular in particular evolved from a template HTML generator, into a what is now a full featured Angular 1 framework. Angular  had its start in 2009 which seems like a lifetime ago now in terms of new Web capabilities and developer practices. With the exception of some of the newer frameworks like React, the story is similar with other frameworks that had an early start.

The result is that a number of frameworks have quite a bit of old code that wasn’t designed for the purposes we use them for today. Even beyond that when these frameworks were originally built, the complexity of applications we are actually building today wasn’t imagined in those early days. The end result is that frameworks have been refactored from the outside in, resulting in a number of inconsistencies, overly complex APIs and sometimes funky behavior that requires detailed inside knowledge of how the framework works to work around issues.

Since those early days, framework developers have done an admirable job of patching up the existing frameworks, keep them relatively easy to use as well as providing the features that we as developers need to get our job done. As I mentioned in Part 1, it’s amazing what these frameworks have provided us in terms of a leap over your typical jQuery based application we built before it, both in terms of functionality as well as productivity. For me personally the productivity gains in building front end applications has skyrocketed after starting to use a framework (Angular in particular) because it freed me from having to build my own system level components and try to figure out project structure. It's been a huge win for me.

But… looking over how frameworks are working there are many things that are suboptimal. Again speaking from my Angular particular view there are tons of rough edges. In Angular the built-in routing system is terrible even though UI-Router provides some relief for that it's still a very messy way to handle routing. Directives have to be near the top of the list for awkward APIs with its multi-overloaded structure and naming standards (if you can call it that).  There are lots of quirks where binding can go terribly wrong if you bind circular references or when you need to do manual binding at the wrong time in the Digest cycle and you end up in an endless digest loop that eventually pops the execution stack. While these are all known and relatively minor issues that have workarounds, it shows the architectural choices from a bygone time catching up with frameworks that are trying to do so much more than they were originally designed for.

Starting Over with V2 Frameworks

The inclination to reimagine is very high in software development, and in the JavaScript world where major version cycles are measured in weeks instead of years this is especially true. But in the case of the existing JavaScript frameworks and their explosive growth and rate of change, it’s actually become quite clear that starting over and building for the current use cases that we’ve discovered and mostly standardized on for JavaScript framework based development is a good idea. Clear the slate so to say, and start over with focus on the performance and features that we are tasking those frameworks with today.

Not only are we dealing with new framework re-designs, at the same time we're also dealing with a bunch of new-ish technologies that are disrupting the way things have been done in the past. Among them are:

  • Components not Applications
  • JavaScript Changes
  • Platform Changes
  • Mobile Optimizations

I've been watching and playing around with Angular 2, Aurelia and Ember 2 for version 2 frameworks. Out of these three only Ember is shipping a production V2 version today while the others are still in alpha and beta state respectively and not looking like they are going to release anytime soon. This post mostly relates to these three frameworks since that's what I've looked at, but much of the content can be applied more broadly to other frameworks as well.

Components over Applications

One theme that all the frameworks are starting to embrace is that applications should be built out of smaller and simpler building blocks. So rather than building large modules or pages/controllers,  the idea is to create self-contained smaller components that can be patched together like legos into a larger document. Components have their root in the fledging Web Components standard that seems to have stalled out due too many problems and inconsistencies, but the overall concept of self contained components is still something that each of these frameworks is paying lip service to.  All the framework vendors claim some Web Components functionality but in reality it looks like the concept more than the actual implementation is what counts.

In Angular 2 for example, rather than having controllers and directives there will only be components. A component can take over the functionality of what directives and controllers used to do under a single component type. At a high level both do many of the same things - they both have models  and binding code to deal with.  Likewise services and factories are simply classes in Angular 2. The goal of much of the new functionality is to simplify and strip functionality down to its most essential features to limit the API surface of frameworks which results in simplification on many levels. Certainly angular 1 had a lot of duplicated concepts and in Angular 2 the object model will be much smaller and more concise which makes it easier to work with.

Besides the object model simplification, a component approach can have a profound impact on how you build applications. Rather than building large and complex controllers, you can break out pages into their individual components where sections of a form, or say a list live in their own components. By isolating each of these components and assigning their own logic and data to them they become easier to develop (less dependencies and smaller code base) as well as more easily testable. Angular, Aurelia and Ember all embrace this component style with nested customer HTML tags that describe the individual components in a page.

But having played with components over controller approach I have to admit I have to really force myself to think this way - it's hard to draw the line and not over fragment applications into a million little shards. There's a fine line between not enough and too much componentization. But the beauty of the model is that it's your choice. You can make your components as atomic or as monolithic as you choose.

Improved Databinding Syntax for Angular and Aurelia

Angular 2.0 is making a big break from Angular 1 with drastic changes to its markup syntax for data binding. In Angular you can bind any attribute, event or property through the markup interface using a funky CSS inspired syntax (# for objects/properties, [] for attributes and () for events) for example. While the syntax definitely is 'different', it does provide for a well thought out approach for data and event binding that is much more flexible than the old model. This model reduces the need for custom directives just to handle special bindings for each type of control or control attribute. This feature alone should cut down drastically the amount of directives needed in Angular.

Aurelia also has a beautiful, explicit data binding syntax model that uses descriptive prefixes like bind. or delegate. to actively describe the operations to perform for binding. It's very clear and descriptive although a little verbose. Like Angular Aurelia can bind to anything on an element which makes for more flexibility than V1 frameworks had. I'm a big fan of Aurelias binding and validation model. It's very clean and easy to work with in code.

The changes in these frameworks are very welcome as they provide much more flexibility than what was available in V1 frameworks. It also looks like performance of data binding will be much improved as a result of these changes.

JavaScript: On the Cusp of Big Change

The other major change that's happening in the V2 frameworks is that they are all focused on EcmaScript 6  (ES 2015) and beyond.  With that change comes a whole slew of other technologies that are required in order to make it all work because even modern browsers cannot run ES6 natively today.

This means new technologies you have to learn and work with:

  • EcmaScript 6 (ES 2015)
  • Transpilers
  • ES6 Module System and Loaders
  • Build system technologies

ES6/ES 2015

Some of the highlight features of ES6 are:

The built-in module system is probably the most notable feature as it greatly simplifies the alphabet soup of module systems that are in use today. Having a standard module system defined at the language level should - in the future - provide for a more consistent experience across libraries instead of the messy multi-module support most libraries have to support today. ES6's module system doesn't support all the use cases of other module systems (there's no dynamic module loading support for example), so we may still need a supporting module system for that, but at least at the application level the interface will be more consistent.

Classes are the other big feature for ES6 although not everybody is a fan of classes in JavaScript, as it sidesteps some of the traditional functional nature that many love in JavaScript. Realistically classes just add to existing features so the purists can go on using their prototypes and functional classes, but I think classes add a necessary construct that is needed in a general purpose language like JavaScript. Dissenting purist voices aside, classes will end up being the most popular choice for creating a data structure  and looking at how the V2 frameworks handle operations that's certainly validating this point. Function() based classes and Maps likely will be relegated to special use cases once ES6 takes hold broadly.

I might be biased coming from Object Oriented environments but to me classes make a lot more sense than the haphazard choices we've had in JavaScript thus far with their individually different behaviors. As a bonus classes finally maintain the scope of the .this pointer in method code, which is one of the most vexing problems that new JavaScript developers coming from OO often run into.

Another great feature are template strings which can be used to merge string and data content inline. This is great for code based output generation, but also useful for things like components which often need to be fully self contained and not ship with external HTML content. In this new word of components inline HTML may not be uncommon and template strings greatly facilitate embedding data into string content for rendering.

Promises are now included in ES6 as part of the base language which again provides a consistent baseline on which libraries can build. The built-in implementation doesn't support all the features a library like Q provides, but it provides the core implementation. Libraries can build ontop and provide the additional functionality. It's been frustrating to see different promise implementation that handle callbacks and error handling using differing syntax and by having a standard in the language at least we're bound to see standardization of the core syntax. All the new major frameworks are using the base ES6 promises and building extensions on top of it.

Arrow functions are like C# lambdas and make for less verbose function syntax.  Not exactly a big feature but I have noticed that it does make for more readable code as it cuts down on verbosity for anonymous functions. Unlike standard anonymous functions, arrow functions also guarantee that the parent scope's .this pointer is captured, rather than the active context's which is important when executing inside of the context of a class.

Finally there are a bunch of new language features in ES6 - the let keyword allows truly local scope variables in addition to the sometimes tricky block scoping. There are tons of new features via method extensions on the base JavaScript objects. Arrays in particular gain a ton of new functionality. There's also support of yield syntax using Generators so you can build IEnumerable style functions, and an implementation of iterators using the new .keys() and .values() and .next() functions that allow iterating over the internal members and values of an array. .find() and .findIndex() make it easier to find elements.  Many of these features have been available as part of third party libraries like underscore or lodash, but it's nice to have these common features available natively without a lib. It's a good idea to poke around in the list of new features in ES6 to see what other things you can use and might allow you to ditch an external library for. ES7 promises even more common language enhancements like async and await, object.observe() and more array and object extension functions which are useful for everyday scenarios.

None of the features are necessarily new - most you've been able to accomplish with third party libraries or other code workarounds. But having this stuff as part of the native JavaScript platform can reduce the amount of external libraries required and generally make functionality more consistent.

ES6 and (no) Browser Support

We can all agree that ES6 is nice and has many, many worthwhile enhancements. But the reality is that ES6 is not natively supported by any browser shipping today. Some browsers support some of the features, but no browser supports ES6 fully today.  if you take a look at this chart, you'll see a lot of red and the highest feature coverage of any browser is FireFox with 71%. It's actually quite surprising that full support isn't here yet especially given that most browsers (with the exception of Internet Explorer) are now evergreen browsers that are automatically updated with new features and standards and the ES6 standard has been more or less finished for nearly a year (although fully ratified only a few months ago). Yet full native support for ES6 looks like it will be off by quite some time yet. My guess is we won't see a full native implementation until early next year and probably a few more months before even all evergreen browsers will be there.

But even when evergreen browsers become capable to run native ES6, there's still the issue of older browsers that won't go away. Internet Explorer versions before 11 and Edge will never get upgraded, and there are literally  a billion old smartphones that have old browsers that also won't upgrade. The shift to ES6 with native browser support will take a long time before you can ensure that native ES code runs the way we expect ES5 code to run today.

ES6 requires Transplilation

Because this is all so much fun we had to invent a new word for running ES6 on browsers today: Transpilation. Transpilation is the process of converting JavaScript from one version to another - specifically from ES6/7 to ES5. For now, if you want to use ES6 the unfortunate truth is that you have to a transform ES6 code into ES5 somehow so that it can run on just about any browser. Transpilers take ES6 (and ES7) code and convert the code to ES5 code that can run in any browser.  Tools like Babel and Traceur come both in build time and runtime libraries that convert ES6 code into ES5.  The most common use case is to use a transpiler as part of the build process and statically 'compile' ES6 code into ES5 code, which is then loaded in the browser using a command line build tool or build tool like Gulp or Grunt.

There are a number of transpilers available today:

  • Traceur
  • Babel
  • Typescript (still requires traceur or shim transpiler at the moment)

Traceur by  Google is optimized for machine read code which essentially means it creates very terse and unreadable code. Babel is probably the most popular of the transpilers at the moment and creates reasonably readable ES5 code from ES6 or 7. The advantage of Babel is that it provides good debugging functionality and source mapping as well as smart exception handling that actually provides usable errors. Typescript is Microsoft's JavaScript enhancement language that provides new language features ontop of JavaScript and a type system for JavaScript. Typescript's features are mostly compatible with ES6 and ES7 syntax and provides additional features like variable and member typing, interfaces etc. Typescript comes natively with a compiler to turn typescript into JavaScript and there are options on the compiler to create either ES5 or ES6 code. Typescript is a super set of JavaScript, so plain JavaScript just works in Typescript. TypeScripts is shooting for full ES6 support, but it's not quite there yet. While Typescript can compile down to ES5 making it a transpiler of sorts, it still requires some additional module loader code to handle ES6 module loading completely.

Say Goodbye to Simplicity

Say what you will about the complexity of the V1 set of frameworks, one thing that is nice about them is you don't need much to get started. You can simply add a script reference to a page and you're off and running. The V2 frameworks are not going to be so easy to get started with.

With the ES6 recommendation of these new frameworks (Angular 2, Aurelia, Ember 2) that simplicity is gone as you *have to*  use a build process in order to transpile your code before you can execute it. Theorhetically you don't have to use ES6 as the frameworks pay lip service to supporting ES5, but it's clear that this is not the optimal use case. The new frameworks are designed for ES6 and when you look at the examples you are also not likely to want to use ES5 as it's much more verbose to write code with the same functionality.

But the complexity goes beyond just the transpilation. To get the transpilers set up you need a bunch of additional tooling. Aurelia requires jspm which is quite nice and meshes really well ES6's module system by using the same naming convention as modules. Angular uses Typescripts pacakage manager and Ember uses its CLI based loader. Everywhere you look tooling is required to get things loaded compiled modified and rearranged. Welcome to the simple JavaScript lifestyle.

Going to the home page and reading the getting started guide for any of the frameworks reads like a tutorial for a whole product of earlier libraries with discussion of installing package managers, transpilers, and running build agents that compile your code as soon as it's changed. There are usually a page or two of command line tools you get to run before you ever get to write a single line of JavaScript or HTML code. The move to ES6 might provide cleaner code, but the downside is that there is a lot more complexity involved in actually starting and building an application.

To be fair once you understand the basic steps involved this process of setting up a simple build environment won't take very long, but if you are a new developer starting from scratch and staring at the first time tutorials I'm not sure that I would stick with it. My first impression would likely be: "Are you fucking serious? You call this easier?"

I think in the big picture it will be easier to use these new tools and as much as it seems painful at first, a build process for JavaScript is becoming a necessity even if you are using an older framework. The main thing is that the getting started for a complete newbie learning curve has gotten significantly more complex. And that is not a good thing.

Even for seasoned developers comfortable with V1 frameworks there will be a learning curve, at the very least picking up ES6 and new module loading syntax and the new fraemwork syntax, but also to work with a whole new set of tools to build your application.

Dedicated CLIs

To help alleviate some of this setup, build and configuration pain the new frameworks come with dedicated CLIs that help manage project creation, build process and running watchers. These tools are geared towards easing the repetitive and tedious tasks that you have to go through especially at project creation. This goes a long way to making the process appear simpler as long as it all works.

But when it doesn't, things can get ugly because at this point you have hundreds of files and packaged dependencies created and very little in the way of hints where things went wrong. I ran into this with both Aurelia and Ember starter projects and in both cases the problem ended up being out of date package references which took a bit of time and searching to correct.

Regardless, tooling is going to be a vital part of this lifestyle if there is any hope of getting the unwashed masses to use this stuff or even try it out for that matter. I think it's going to be an uphill battle to get people weaned off the simplicity of the V1 frameworks and get over the AYFS moment. :-)

There's lots of room to improve here. The V2 frameworks are either in Alpha, Beta or just Released so they'll improve and get more reliable with time. Let's also hope that the build tooling and dependency trees can be whittled down over time to reduce the complexity of what is required just to get an application off the ground.

Mobile Development

Another important aspect of V2 frameworks is additional focus on mobile development. This comes mostly in the form of optimizations to make sure that frameworks are optimized for mobile devices to use less power and perform adequately. Existing V1 frameworks are notoriously CPU hungry and a lot of focus is going into V2 versions to optimize performance.

All of the new frameworks are using new approaches to deal with view rendering and data binding performance by overhauling their view and binding engines. The React framework seems to have had a massive effect on other frameworks in spurring better performance for rendering large amounts of data, so much so that some frameworks like Ember are emulating some of the React engines features for their own rendering. React's main selling point is that its blistering fast in rendering data, so much so that it doesn't use traditional bindings but rather just redraws the UI as needed from memory rendered buffers.  React's approach is more traditional in that it works like a view engine rather than a data binder with the view engine simply re-rendering the entire view rather than trying to update the DOM's existing state.

Angular and Aurelia on the other use data binding to update existing DOM nodes when data changes. In V2 new approaches are used to detect changes. MutationObservers and support for Object.observe() make it easier to detect changes on DOM elements and classes in a highly performant way and this translates into better overall data binding performance.

Additional mobile development features are geared to the animation features built into the frameworks, that are optimized for mobile deveices as much as possible. I haven't really checked this out, but there's quite a bit of hoopla around this aspect.

There are also efforts in making various frameworks to support multiple view engines that can be swapped out and actually render native controls in native applications. Again React started this with React Native which maps their JSX language markup to native controls. Telerik is also heavily pushing their NativeScript framework which is a more traditional component library approach to building applications, but using JavaScript.

Native development is definitely an important aspect. For me personally, the last 4 applications I've built have had major mobile components to them and while I prefer building Web based applications that work well on the Web, 2 of those apps needed to be wrapped up in Cordova to provide the functionality we needed. Native frameworks address this need. To me though it's not so much the development of the applications that is at issue though - it's the infrastructure and deployment/testing process that's the big issue. Building applications that can go easily between a Cordova solution and a native Web application require a bit of tweaking, and the entire process of rigging up and testing Cordova applications still feels very cumbersome. Again I think tooling in this space is going to potentially make this better and as far as it goes Telerik seems to have the right idea with their integrated Web and Visual Studio environments.

Mobile is definitely an interesting space - so much is changing and no matter what you use it seems by the time you get rolling with it something new and better shows up…

Two Steps forward One Step Back

twoforwardonebackIt's easy to get wrapped up in the hype around the V2 frameworks as they are clearly bringing many improvements and cleaner object models to framework Web development. But we're getting hit with a large amount of change, not just from the frameworks themselves but also the underlying JavaScript and build system changes that are essentially forcing a complete reoboot on how you build front end applications with these new frameworks. We're gaining easier to use code and new framework features at the cost of additional infrastructure overhead.

It's ironic to see JavaScript move in this direction because simplicity was always one of the biggest selling points of JavaScript. In the past it's been "Just add a script tag to an HTML page and you're in business" - well that's no longer the case if you want to take advantage of all of these new features. And just as ironic is that JavaScript now needs what essentially amounts to a compilation system that can compile a bunch of modules into a concatenated and compacted executable file. This is starting to look a lot like a .NET or Java project - without all the nice IDE build tool features that don't exist for JavaScript today.

Regardless, it'll be interesting to see where JavaScript frameworks will end up once they are actually releasing. Currently the biggest pain is that it's hard to see when some of these frameworks will actually ship. I've been really enjoying playing around with Aurelia and some parts of it feel really solid while others are clearly still under construction and wobbly. Neither Aurelia nor Angular are ready for any sort production work yet, so it's hurry up and wait. I'm not about to jump in for real before the frameworks are ready for anything but just playing and getting familiar with some of the new concepts. Make no mistake there's a lot to learn and it will take time, so getting a headstart on ES6 especially is probably a good idea.

I'm taking my two steps forward cautiously. For production use I'm continuing on with Angular 1.x for the time being - after all the V1 frameworks work today. I'm checking out the new frameworks and building a few simple sample apps with them but that's as far as I'm willing to commit for right now. I get questions from customers regularly asking whether they should wait for V2 of this framework or that, and my advice always is - go with what is available today. Don't wait for the new and shiny. Even if it shipped tomorrow you'd need some time for learning, and it's probably a good idea to wait for the first few point releases and see what issues crop up.

The future starts tomorrow. In the meantime get stuff done today…

Posted in Opinion  JavaScript  Angular  

The Voices of Reason


Stephen Cleary
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

Thought you may be interested in this...

One of the big takeaways I had from ThatConference is that JavaScript is making a huge push into native mobile. React Native (by the React team) and NativeScript (by Telerik) are both vying to be the future cross-platform mobile solution. I thought the approach with React Native was particularly interesting: they're using jsx just with native components instead of DOM components.

Cory House
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

Great writeup Rick. You've summarized the current state well.

However, I'd argue version 2.0 doesn't necessarily mean it's a significant shift. For example, Ember's initial 2.0 release simply removed already deprecated functionality. So release numbers don't necessarily mean much. And that's important because I'd argue React's .13 combined with the Flux library of your choice is already a generation ahead of the current crop of "Version 2" libraries you're discussing. Why? I believe the fundamental mistake other frameworks are making is continuing to be HTML-centric instead of JS-centric. I explore this issue more here: https://medium.com/@housecor/react-s-jsx-the-other-side-of-the-coin-2ace7ab62b98

Angular, Ember and Knockout put “JS” in your HTML. React puts “HTML” in your JS. That's a powerful paradigm shift. And one I'd argue the "next-gen" frameworks shouldn't ignore.

Rick Strahl
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Corey - thanks for the feedback. Yeah I think Ember managed the transition to 2.0 a lot better than the other frameworks. But if you want to use all the greatest stuff you still will have to deal with the ES66 builds steps. Ember's CLI generator creates a massive amount of stuff that as a newbie is totally overwhelming even if you are already using other frameworks.

As to React and Flux: I think React and Flux are an aquired taste, to me personally I'm not happy mixing HTML markup and code in the same place (too much of a throwback to ASP Classic :-). React also isn't really a framework per se - more of a view engine and it excels at that part of it. Other things have to be explicitly built on top of it and there aren't a lot of standard implementations it seems. For example form no standard form validation.

But to be fair I totally get the attraction and the key is to build everything as small components so that the HTML/JS intermixing is minimal and doesn't turn into a mess. It might take me a few more attempts and some more in depth research to support functionality to dig a bit deeper. Hey your Pluralsight course is on my list :-)

Mike Gale
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

If WebAssembly ever comes to pass that will take the "JS only" out of this debate. No doubt make it more complex. Presumably that's years away, even if it does happen.

Cory House
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

Rick watching one of my courses? Achievement unlocked! :)

You've hit on the biggest downside to choosing React: The paradox of choice. There's multiple routers, many Flux implementations, many ways to handle data calls, validation, etc. You're right - Comparing React to Ember and Angular is apples and oranges. React is just a component library. But if you're someone who likes picking best of breed technologies, React with React Router and some flavor of Flux is a compelling option. It's the polar opposite of Ember, which of course has its plusses and minuses. But it does make it extremely versatile - you can sprinkle React like salt on existing projects. And if you find it's tasty, you can make a full meal of it.

Torgeir Helgevold
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

In my opinion Angular 2 doesn't really introduce a new concept by releasing "components". Angular 2 components are very similar to Angular 1.x directives if you stick to directives supported by external "controllerAs" controllers. The old .controller will be retired, but the new Angular 2.0 component class is really just the same concept all over again :-)

The component vs directive similarity will help a future migration since the concepts are so similar. I have done a comparison here in case you are interested: http://www.syntaxsuccess.com/viewarticle/migrating-from-angular-1.x-to-angular-2.0

Rick Strahl
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Torgeir - Similar is a relative term. Directives in Angular 1.x are a terrible API construct in terms of implementation. Angular 2's implementation of a component is much cleaner and because of it components can serve multiple purposes as components and controllers. My point in the post is that Angular is consolidating things into simpler constructs and less API surface which makes things easier to work with.

As to new concepts - there are plenty in Angular 2. Today few people really build modular applications with Angular. Most people build essentially complex controllers with directives as needed to handle reusable features or for interfacing with the DOM directly to abstract low level logic. In Angular 1 you'd be crazy to build a modular application out of directives only.

Backwards compatibility and the ability to migrate is overrated. If you have a running application there's no great need to migrate it. I would not recommend going down that road unless you're planning to do a major rewrite/refactor anyway. 'Migration' rarely makes sense IMHO it's just running in a hamster wheel and not making any progress while wasting development resources.

If you really want to take advantage of Angular 2 (or any of the other frameworks) you'll want to go full bore and do ES6 modules, and classes etc. Porting an app from ES5 to that will not be a weekend job...

Rick Strahl
August 26, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Corey -

> Rick watching one of my courses? Achievement unlocked! :)

LOL. I struggle as much as everybody else trying to keep up with all this change and Pluralsight has been a good resource for high level exploration... finding time for watching a multi-hour course even at x2 speed is the biggest problem :-)

Torgeir Helgevold
August 27, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Rick:It's a fair point that similarity is relative, but I don't think components offer better modularity than Angular 1.x. Granted, it's true that the api surface of Angular is too complex, but if you model your directives with all your logic in directive controllers, there is not much of a difference between Angular 1.x "components" and Angular 2.0 components - at least on the surface. I also attribute some of the "cleanliness" of Angular 2.0 to the new direction of using TypeScript. In fact if people started using TypeScript with Angular 1.x I bet people would praise Angular 1.x code as well :-)

There are however other benefits to Angular components under the hood. They have promised to decouple the components from the runtime environment, which means we get some of the same benefits as React offers.

As far as migration goes... I disagree with you that it's unwise to migrate a project to the next version of the framework. Picture a multi year project. Going forward with yesterdays's technology is undesirable for a few reasons. 1) Hard to attract talent 2) You end up losing out on the new cool features of the next version.
That said. In light of the recent news that Angular 1.x and Angular 2.0 will be able to coexist in the same project, we pretty much get the migration for free.

Doug Dodge
August 29, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Rick - Great article as always; thanks. Also, a big shout out to Pluralsight. Before their recent move their old office was about 3/4 of a mile from where I live. Great folks and product(s). So, having no time whatsoever :) to take advantage of my Pluralsight membership nor to keep up with the recent changes like React & Flux the article summed up for me nicely what I do think, if I am reading this all correctly, the larger directional move of our industry. I appreciate you doing all the heavy lifting (again *s*).

In the abstract sense all of the changes in these new products seem to me to be moving in the direction of the Functional programming model. I heard small objects, each with a discreet task, with predictable results for predictable input. Maybe I'm misunderstanding but it sure seems that way.


Rick Strahl
August 29, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Doug - yes I think that where we're heading. Small, single responsibility UI components that can be plugged together to create a whole. Reusability by design and testibility by simplicity. As I mentioned in the post this sounds great, but it really takes some mental adjustment to work this way effectively - it does scatter things about quite a bit and it takes a dedicated workflow to be able to keep things organized.

Doug Dodge
August 29, 2015

# re: The Rise of JavaScript Frameworks – Part 2: Tomorrow

@Rick, The article that lit me up was <a href="http://www.defmacro.org/ramblings/fp.html/">Functional Programming For The Rest of Us</href> written in June 2006 by Slava Akhmechet.

Recommended if you haven't read it yet

Doug Dodge
August 29, 2015

# re: The Rise of JavaScript Frameworks &ndash; Part 2: Tomorrow

@Rick - Can't resist.. Off topic so apologies.

I noted in your two articles the words "Today" and "Tomorrow"

Reminded me of a joke; The Past, the Present and the future all got together in the same room.

It was tense. *g*

Jason Webster
September 23, 2015

# re: The Rise of JavaScript Frameworks &ndash; Part 2: Tomorrow

Thanks for great articles on the JavaScript Frameworks! I agree with your overall assessment. I recently added babel to my gulp preprocessor and I'm writing my current javascript in ES6 to take advantage of the new features get myself ready.

January 18, 2016

# re: The Rise of JavaScript Frameworks &ndash; Part 2: Tomorrow

Rick, it's great to stumble upon your blog again. I remember following it 5 years ago or so, when you wrote about VFP and .Net interoperability. Which makes me wonder, coming from that background did you ever consider using Servoy? It's been heavily targeted at VFP programmers and the platform brought a different for building rich web applications. I've used it to develop enterprise web applications with over 300 users and productivity, development experience, and final user experience is fantastic. Now, I'm about to embark on a new project and trying to decide what to use. I've been reading up on all the new Javascript frameworks and libraries that are coming out and, in many ways, they all seem to do what Servoy has been doing all along (which means a mature, robust environment) with the downsides that Servoy is not as quick to adopt all of the innovations coming out in the Javascript world and that in some ways you get locked into them. I'm also apprehensive of going down this framework path when it's clearly going to keep evolving and it might take a team of developers down a rabbit hole...

Thanks for taking the time to write these articles and it really is great to find your blog again.


January 19, 2016

# re: The Rise of JavaScript Frameworks &ndash; Part 2: Tomorrow

It's nice to read why frameworks are desired/needed. I've been thinking how I would write an app with vanilla JavaScript as a learning experience. I've played with it a little. It's really difficult to think of good ways to write a simple app that is flexible/scalable. It makes me appreciate the frameworks out there more.

I wrote my first app with mithril.js. It's similar to react.js but smaller and feature "complete." AKA, an actual framework. I like it because it is well thought out and really easy to get up and going with it. Like you said, even novices can get going quickly with frameworks. I wrote my second app with react. That was a bear trying to figure out how to do it and what the best practices are (since there isn't any real guidance). And then trying to find a decent libraries to integrate with it. I needed it to work on the server and client side. So, I tried using React Router but ended up having to break the good practices to get it to work properly.

I saw the library intercooler.js and thought it would be nice for small apps, and it would work on the server/client side. But then thought. Why not bind to the events directly in element, it seems like a pretty elegant solution, but it appears that is an anti-pattern also, since, apparently, it isn't as flexible and you can only bind a single event to the element that way.

I haven't really looked at angular, et. al. I shied away from it since I heard it was complex/difficult to learn. I like abstractions that make it easier for me to write code, not more difficult. I think mithril.js is an excellent fit for that. intercooler.js looks like it would be really good for small apps (granted it would be nice if it didn't have the jQuery dependency). I'm sure there are a ton of different libraries/frameworks out there that are really good for simple apps. I get annoyed when everyone goes to the over engineered solutions first. They make sense for complex apps, which they are built for. But for the simple ones, it doesn't seem to make much sense, it seems to make more sense to pick something with a tiny API and foot print. Heck, even just a Razor app it better than doing a SPA when it makes sense.

Rick Strahl
January 20, 2016

# re: The Rise of JavaScript Frameworks &ndash; Part 2: Tomorrow

@Jon - yes writing an big JavaScript app from scratch without a framework is tough. There are those that advocate 'vanilla' JavaScript but what they usually fail to mention is that they are leveraging their own frameworks they've groomed from years of hard earned experience. Even if you have that it's still a big job to build something that is comprehensive.

I've been a big fan of Angular. Personally I didn't think there's a big learning curve - I was up and running with the basics within a few minutes. For the main things you need to do - databinding, module setup, form validation etc. - there's really very little to learn IMHO. This is true of most of the top frameworks. It's when you need to dig into the lower level stuff where things get complicated. Frankly a lot of the times when it gets to that it's often much easier to revert to using jQuery or other plain vanilla tools than trying to bend the frameworks into submission.

As to the 'too heavy' comment, I don't really get that frankly. Minified and compressed Angular 1 is around 40k bytes. You need to add additional modules if you use them but for a typical app that will land at about 60k, which for what it gives you is pretty light IMHO. Especially since no framework you build yourself will have a 0 byte footprint either. It's that same silly approach were people decry jQuery from being too heavy for its 28k footprint which is nothing if you use even a handful of features in terms of value.

Size matters, but when it comes to relatively small footprints for libs that are providing so much functionality it seems silly to reinvent the wheel for the sake of saving the equivalent of a medium sized image. I would much rather forego other small helper libraries, than the big deal libraries that are providing general purpose functionality that you are bound to need throughout larger applications. 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024