Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

The Rise of JavaScript Frameworks – Part 2: Tomorrow


 

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.

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.

Thoughts?

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 – 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 – 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.

JD
January 18, 2016

# re: The Rise of JavaScript Frameworks – 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.

Regards,

jon
January 19, 2016

# re: The Rise of JavaScript Frameworks – 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 – 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 - 2017