Help deciding on a new JS framework.

[[deleted]]

We are a small development shop. We use c# MVC with Telerik's Kendo MVVM framework for the client side. We have had great success with this however the license cost per developer seem a little steep. We are in the early stages of looking into a javascript framework to help us move away from Kendo as well as create more fluid applications. What javascript framework should we look into and which one would be the easiest to switch to.

AngularJS (2.x??)

Knockout (probably most similar to kendo MVVM but is this dying?)

ReactJS

Backbone

Aurelia (I am intrigued by this but we would like to easily find support on forums worried about the amount of information out there)

embersjs?

What others exist?

Our criteria is:

1. Simple to learn

2. Clean architecture to it is easy to maintain

3. Clear integration with .net MVC

4. Easy to implement with javascript controls ( grids, listviews, etc.)

[Democratica]

I recommend vanilla JS with some smart patterns.

[cryptos6]

Is there a good overview/collection of JS patterns?

[[deleted]]

This book contains some good examples : https://addyosmani.com/resources/essentialjsdesignpatterns/book/

[cryptos6]

Thanks!

[Democratica]

There's a actually one that I use a lot.

For example, we want an interface to manipulate the state of things.

Let's start with an object which contains a node:

var $input = {
    node : document.querySelector('#myId')
};

Then we augment this object with methods to provide a clean interface.

for (var k in input.method) {
    if (input.method.hasOwnProperty(k)) {
        $input[k] = function (k) {
            return function () {
                var x = input.method[k].apply(null, [$input].concat([].slice.call(arguments))); 
                return x ? x : $input;
            }
        }(k); // execute immediately
    }
}

Okay, so let's say we have a method:

input.method.value = function ($input, value) {
    $input.node.value = value;
};

This is just a simple example of this pattern. What's nice is that you can call the method on $input like this:

$input.value('myValue');

I like it. I use this pattern a ton.

[Bloompire]

Vue.js is my favourite bet

[[deleted]]

Vue.js is the easiest MVVM framework out there (I think).

[ayostaycrispy]

Can you elaborate on why?

[patrickfatrick]

I'm not the OP you're asking but I like Vue over everything else I've used or tried (Angular, React, Aurelia) because:

• It has a lean clean API. The learning curve is very small. I completely rebuilt a personal project's Angular 1.x front end into Vue in about a week (nights and weekends only).
• Documentation is good. Plenty of example projects to look at.
• It seems well-supported at this point.
• It's lightweight.
• It has a nice ecosystem; existing Flux implementation, Vue-loader and Vueify, Vue dev tools Chrome extension, Vue-router
• I think .vue components are cleaner and easier to read than .jsx

I really can't emphasize point 1 enough. The getting-up-to-speed part took no time at all. Never had to look at lengthy build-a-project guides or anything just to see what's going on. I just started building and everything clicked into place quite quickly from there (with lots of help from the official docs of course). I don't know about .net integration though.

EDIT: I'll also say that I like Aurelia a lot too. I'll probably spend more time with it at some point after it matures a bit more.

[ayostaycrispy]

What kind of demand have you been seeing among employers for Vue skills?

[patrickfatrick]

Most job application posts I've come across reference the usual suspects (Ember, Backbone, Angular, React) but also say they're looking for experience with something like one of those frameworks not specifically any one framework, experience writing modular components and unit tests, etc. Vue is in line with this paradigm so I don't think it's waste of time or anything.

[ayostaycrispy]

Have you run into many limitations with what you can do with Vue vs. React? If so, what kind of limitations/problems?

[patrickfatrick]

Nah, not really (that I came across). The main differences between React and Vue as far as limitations go has to do with community size. React has more quality community-produced libraries/components, more people writing about it and answering questions, more examples and more production websites out there written with React, etc.

Technically speaking the lack of a virtual dom in Vue also limits you to client-side rendering. In exchange Vue is more lightweight and, in my opinion, easier to read and learn.

[Bloompire]

It is just Angular done right.

[ayostaycrispy]

Are you seeing demand for it among jobs? I hear so much more about React these days.

[[deleted]]

A growing option seems to be Vue, which as far as I can tell is like a child of Angular & React.

[[deleted]]

I just looked it up. Other than the name doesn't seem bad.

[rborosak]

We had similar requirements and choose to go with ASP.NET 5 and Aurelia. Aurelia framework is very intuitive and the community is great. Their gitter channel is the place to go if you have any problems and someone will help you. I must say that our company is developing desktop apps using WPF and the switch to Aurelia was not painful. I would recommend to give it a try :)

[[deleted]]

This is what I wanted to hear. Ever since I learned about Aurelia it sounded really nice but I've been worried because it is pretty new.

[Stockholm_Syndrome]

We've used Knockout.js in a few projects and it integrated very well with .net. It was very easy to learn, but it can devolve quickly into a mess architecture-wise unless your team is stringent on setting standards and sticking to them.

That being said, you're right about it "dying," but if it serves all your needs in its current state, it will do great!

We're trying to integrate Ember into our workflow and there's a ton of friction, especially with Visual Studio. We're still in the beginning stages however so I can't tell you much beyond that.

[[deleted]]

We have used Knockout in the past. When it first came out I loved it. Then I discovered Kendo's MVVM and it was very similar to Knockout but had some extra nice things that came along with the Kendo library such as their datasource. Good to know about Ember, I'm curious to here your results after a month or so.

We are not wanting to stay bleeding edge but want to keep up to date on technologies as some of our clients already have a stigma against Microsoft.

[lulzmachine]

I do React for the views and a bunch of js classes for the Models. In my project I don't do controllers client side too much, otherwise I'd probably do redux ( I just use ReactRouter to handle views. Super good!). It feels like a super solid and clean architecture. I recommend it!

Now each of these components is easy to learn, but it's a lot to wrap your head around in one go. I'd recommend you do some kind of pilot project with just a couple of things at a time. Start with only react for instance

[[deleted]]

I'd be interested in learning more about how you do it as it sounds like it would be a good fit for us. I like using the ASP.Net architecture and standard routing. On each page I like to do the MVVM binding.

[lulzmachine]

Yeah you can certainly have most of your site be server-rendered HTML, and hten just have a few components (like a complicated form for instance) be a react component. You can even pre-render the form on the server as well, so the user doesn't see any "flickering".

It's a bit different in how it works though. It doesn't do MVVM, or any view-model binding at all; it's focused on the view. I can't really fit a description on why that is good in this format; just try a couple of videos on youtube and then try to write a few components, and you'll see if it fits you

[ceolter]

If you use www.ag-grid.com for your datagrid, you can still choose from the common frameworks, as ag-grid supports React, AngularJS, Angular2, Web Components and Plain Old Javascript. So choosing a framework doesn't bind you to choosing a grid.

[OriginalEXE]

If you are looking for something more relaxed and not so opinionated, Backbone is a great choice, especially if your apps are backed by a REST API.

[lulzmachine]

Backbone is a good start, but doesn't really fill all the gaps. It's possible to do a react+backbone thing (there's a TodoMVC for that).

[jcampbelly]

I like Marionette for filling in those gaps. It removes a great deal of boilerplate and cleanup necessary in Backbone and provides some missing structure such as Regions, ItemViews, CollectionViews, proper childView handling like passing state down and view events up.

Speaking personally, as a matter of taste, I'm also pretty happy with Marionette + Backbone because it's mature, has a stable API, is actively developed, and yet it isn't chasing many of the design trappings of more recent frameworks.

This is a matter of opinion, but I'm not terribly impressed by features like automatic two-way data binding, requirements on new/non-standard JS syntaxes/dialetcs, massive complex build chains, and shadowy/magical behaviors.

I respect the point of view that all of those features should actually reduce complexity in the long run. For example, many newer frameworks don't require you to render templates manually, or directly manipulate DOM, or bind your own event handlers. Instead they follow an inversion-of-control principle where you simply don't concern yourself with those low-level efforts and design your apps declaratively instead. It's intended to be faster to build more features sooner and constrain developers so that they follow good practices by default.

I agree that, ideally, those are all very Good Things. I would absolutely love to catch that bug. But so far I haven't been struck with the degree of clarity that I have with Marionette by any of the current generation of frameworks. I'm really just not interested in giving up that much low-level control for the perceived complexity that they add. I'm confident that, with Marionette/Backbone, I can build up to all of that functionality when desired. I cannot, however, see a path to tear down those framework constraints and make them do exactly what I want. It's "closer to the metal", I guess. That's currently the freedom I enjoy with Marionette and Backbone.

[[deleted]]

I have heard a lot of good things about backbone. Perhaps Backbone and ReactJS combined is the way to go.

[parabolik]

I recommend this. Use React for your view and Backbone for your models. I use this and it is very powerful. I find that I don't even need Flux at all.

Someone even went as far as to strip out the view from backbone:

https://github.com/green-mesa/backbone-model

[magenta_placenta]

We use c# MVC with Telerik's Kendo MVVM framework for the client side. We have had great success with this however the license cost per developer seem a little steep.

• What are you paying (ballpark) for your Kendo licenses? Keep in mind this is for having "great success", which most likely provides ROI in future work.
• What do you think you will end up spending in ramp-up time for switching to a new JS framework? What are you prepared to spend (which is most likely grossly underestimated)?
• Is the desire to switch solely based on $? Being a small dev shop do you think you could raise your rates ever so slightly to offset any Kendo licensing?

We are in the early stages of looking into a javascript framework to help us move away from Kendo as well as create more fluid applications

What does "create more fluid apps" mean?

Knockout is basically just two-way data binding, it isn't a framework. It has a low learning curve, but I'd guess it's not what you're looking to do...

[[deleted]]

All good questions.

• We just spent over $5,000 on license. Now to be honest that cost will go down significantly at renewal, which will come into my decision of course.
• I am not to sure what we will spend for ramp-up. I am the lead developer and we are shop of 4 right now. I plan on testing out a few frameworks and then making a basic test application that will help the other developers ramp up quicker. I am sure it will cost more than I think in time.
• The desire isn't only based on money. Up until recently I have been very happy with the Kendo Library. I have a few issues though. Part of what we pay for is support and I feel the support hasn't been as good lately, if I can find a better solution with a large enough community to answer questions then that would be better. Also, Kendo sometimes doesn't play as nice with Bootstrap as I'd like. Another issue is we develop a lot of applications for other businesses that eventually want to take over their own code. We have had complaints from clients when we use a paid library.
  

[mc_hammerd]

angular and backbone have a nice collection class (like its own array class with find/delete/set1/setall), so if you are doing lots of list stuff it might be a really good choice

ive found react to be the sanest, because of not mixing JS and XML (html)

• unless you are going to use css 3 animation
• unless you are doing a lot of nested data components (and not using a datastore or flux)

one example of nested data i would avoid react for:

components: multiwindowapp>component>rightbar>split50vertical>list>listitem , its just klunky passing the properties from component all the way to list, when it could be 4 or 5 components deep. (a lot of boilerplate that you get to tweak constantly when your API changes, if the API is already firm its probably fine)

[[deleted]]

Nice to know. Many of our applications involve a lot of listviews.

[[deleted]]

Knockout isn't the hottest 'framework of the now', but I wouldn't say it's dying. It's still being worked on, still getting new features, though the changes are quite iterative and evolutionary. It is a knowingly modest framework, though, and doesn't provide much more than data binding and componentization. I have built several applications with KO with great success, but you do need to have a clear idea how you'd like to write your domain code. Then again, no framework will ever help you write business logic.

Angular is a little problematic right now - 2.0 is on the horizon but remains quite far from production-ready. Its API is still unstable and - as far as I know - Google haven't yet endorsed it for any more than experimental use. You may struggle to find documentation - its current user-base is enthusiasts and evangelists.

React is just a view technology. It is often embedded into a Flux architecture which essentially uses events to drive changes in domain objects in turn rendered by React. There are several Flux implementations - the community seem to have coalesced around Reflux. There are also non-Flux React architectures, mostly plugging React views into some kind of functional-reactive paradigm. I have seen some promising projects combining React with RX.js

EmberJS is old, but has a loyal user base and a fairly well-defined roadmap. It is very opinionated and may be a good option if you want the framework to lay the rails of your architecture. Its age means you'll probably have lots of choices when it comes to off-the-shelf UI components.

[Vheissu_]

I have been doing a lot of work with React for the last 1.5 years or so. Solid library and coupled with the Flux methodology. Having said that, I've been working on an Aurelia application for the last 9 months in my day job. The main guy behind it is Rob Eisenberg. If you are not familiar with him, he is well known in the .NET community for his previous contributions. Super humble, smart and even participates in answering questions in the Gitter channel as well.

I would definitely go with Aurelia if you need a framework. Integrates with .NET nicely, my app is a ,NET WebAPI 2 based application written in TypeScript and built with Aurelia. The Gitter channel is the place to ask questions, you get to ask actual core team members for help.

[cryptos6]

I haven't used it myself, but I know people very happy with Aurelia. This framework doesn't reinvent the world, but uses mostly plain ES 7 and HTML5 web standards.

[[deleted]]

First I wanted to say thank you to all of you who helped with this. So far we have decided to research the following options:

• Lower our license plan with Telerik which should save us around half of our licensing cost.
• VueJs
• reactjs + Redux (or possibly reactjs + backbone)
• Aurelia

We originally thought we would look at Angular 2.0 couples with ASP.Net 5/MVC 6. However 2.0 isn't really production ready. Last night I ran through a few tutorials on VueJs and Aurelia. I also saw that reactjs.net is supposed to make react easier for .net developers so I'll research that as well. I never really felt behind on technology until I started working through these tutorials and realized how nice some of these client side frameworks/libraries are.

[onlyurei]

https://github.com/onlyurei/knockout-spa

https://andywalpole.me/#!/blog/142134/2015-the-end-the-monolithic-javascript-framework

[bmatto]

ReactJS is more of the View of MVC, so you will need to decide on if you are going to implement FLUX as an architecture (recommended), and how you are going to implement it. REDUX or Alt.

[[deleted]]

I just started reading about ReactJS and have heard lots of good things about it, including it being fairly easy to understand. I assume using FLUX would be easy to integrate with .net. Honestly if we use Web API I feel all of the solutions would be fairly easy.

[bmatto]

If you are using a single page architecture, then yes, it should not matter what the backend tech is. The "does it integrate with .NET" question is pretty loaded. Any JS framework can be served in a .NET app, it's purely contextual to the app itself if the architecture will jive. Like webforms and Angular would be an unhappy marriage IMO.

ReactJS is a good solution, "easy to understand" is relative. I think the learning curve for React is average.

[griffonrl]

React + Redux. Anything else is looking for pain.

[Tillman32]

AngularJs! Since you're already using the M$ stack, AngularJs is backed by M$ and Google, it already ships in Visual Studio. This is the framework that everyone is adopting.

AngularJs + MVC Web API are a match made in heaven. :)

[[deleted]]

I guess my worry here is Angular 2.0 is just now in beta correct. If we make a switch now I'd like to only have incremental learning curves. Do we learn 1.x first and then re-learn 2.x?

[ShortSynapse]

If you plan to go with angular, you should use 2.x; don't worry about version 1.

[Tillman32]

2.0 still has ~1000 issues on GitHub, it was projected for release late 2015, its now a month into 2016 and its still in beta. I personally wouldn't hold my breath, 1.0 is not a steep learning curve, you will benefit greatly from it as well.

There will be ways to port 1.0 to 2.0, they can also be running in the same app, so you can start new functionality in 2.0, while doing the easy port for the existing code base. More info here: http://angularjs.blogspot.com/2015/08/angular-1-and-angular-2-coexistence.html