JavaScript for Line of Business Applications

Hybrid development, or the approach of building native apps using Web technologies, has gone through its fair share of highs and lows. But, despite high-profile abandonments from the likes of Facebook and LinkedIn, hybrid development continues to be used by a substantial number of developers.

 Is hybrid as a platform growing or shrinking? Is performance still a limiting factor for hybrid apps? In this article we’ll attempt to answer those questions. We’ll look at where the hybrid ecosystem is today, and where it’s heading.

Here at OK GROW! we love tools that help us ship faster without ever sacrificing on quality. We think that Meteor could be that tool and are always excited to share our experiences and resources with anyone interested. 

If you are looking to get started with Meteor here's a short list of the things we've found helpful.

* Learning

* Resources

* Community

* Other

A journey with ws, Socket.IO, Engine.IO, and Primus

For a current project at WhoScored, I needed to learn JavaScript, Node.JS and WebSocket channel, after seven years of writing web applications with Java and Spring framework. We wanted an application that can send data to thousands of concurrent users, and Node.JS appeared to be the right way of doing it with its event-driven, non-blocking I/O model that can scale up easily.

Compared Frameworks

* einaros / ws
* Socket.IO
* Engine.IO
* Primus

Performance limits
* Changing the flow based on limitations
* Test 1: The impact of data size
* Test 2: The impact of concurrent connection size
* Test 3: The impact of data broadcasting frequency

With AngularJS and ASP.NET MVC, we now have an MVC pattern and architecture for both on the client and server. What do we do and/or how do we approach this? Well one can argue we don’t use any of the MVC architecture on the server and build out a full-fledged AngularJS front-end application and only use make async calls to Web API for all things that absolutely need to be on the server e.g. CRUD, workflows, business logic, etc.

Now, there’s absolutely nothing wrong with this approach, and for the most part a lot of heavy front end SPA’s are built this way in ASP.NET MVC. However, with all the .NET, ASP.NET and AngularJS goodness, why not leverage the best of both worlds? Again, there’s absolutely nothing wrong with building a pure AngularJS application and only using Web API, but for this blog post we’ll go over patterns of using the best of both worlds along with integrating AngularJS with Kendo UI.

Mithril is a client-side Javascript MVC framework, i.e. it's a tool to make application code divided into a data layer (called "Model"), a UI layer (called View), and a glue layer (called Controller)

Mithril is around 3kb gzipped thanks to its small, focused, API. It provides a templating engine with a virtual DOM diff implementation for performant rendering, utilities for high-level modelling via functional composition, as well as support for routing and componentization.

The goal of the framework is to make application code discoverable, readable and maintainable, and hopefully help you become an even better developer.

Unlike some frameworks, Mithril tries very hard to avoid locking you into a web of dependencies: you can use aslittle of the framework as you need.

However, using its entire toolset idiomatically can bring lots of benefits: learning to use functional programming in real world scenarios and solidifying good coding practices for OOP and MVC are just some of them.

Not too long ago, FTBpro.com moved its website from classic web architecture (CWA) to a single-page application (SPA). For those who are less familiar with SPA, the major differences between the two are as follows...

To put it in simpler words – while in CWA the client gets a full HTML page on each request, in SPA the client gets all needed to be able to render the HTML by itself on the first page load so that subsequent requests might be carried in a very fluent and rich manner. It makes your website more of an application and less of a si

The one framework I always see compared to Derby.js is called Meteor. Similar to Derby, it handles things such as updating views live across multiple clients, though Meteor does it somewhat differently. While Derby is designed to be easier to use with different types of database systems, Meteor works closely with MongoDB. In fact, the client API for accessing the database is almost exactly like what you’d expect on the server-side with something likeMongoose.

While there are some drawbacks and controversies surrounding the framework (see Fibers vs Callbacks), Meteor looks like a pretty interesting option when creating an app that requires realtime feedback. Personally, I’m more attracted to the traditional callback style of programming of Derby, but the lack of robust documentation and a large developer community behind it is a huge blow to Derby’s usefulness. This will change over time, but at a much slower rate than Meteor, which recently received $11M+ in funding. This financial backing ensures that Meteor will remain around and supported, and for developers who need a financially and developmentally stable framework, the funding will only make Meteor more appealing.

Today, I want to go over how to create a really simple Meteor app. Essentially, this is a writeup for Tom’s Vimeo screencast. One major difference between my writeup and Tom’s video tutorial is the way we handle events in Meteor. Rather than copying and pasting code from one of Meteor’s examples, I take you step by step through a custom implementation of handling the enter key press to submit a message. Let’s begin!

This would definitely be the most common question that I see asked or people are wondering how to achieve a link between client and server using the Meteor.call() function.

The solution that I have found involves setting up a Future inside the server call and returning the pointer to that future to the client and then when the function call has completed, send the results to the client via the call-back from the Meteor.call() function.

Say you wanted to make a call to a server-side function and then have the result of that stored in a session variable or even used inside a template. If you tried to call Meteor.call('some_function', function(err, ret) { // use the ret variable here }); you would probably be tearing your hair out wondering why it hasn't returned the value you returned in side the call definition on the server...

The trick is using a Future on the server and then you are able to pass back the result of the call via the future making it available in the call-back method. Example is below and you can download the project via the GIST:

I decided to spend the last couple of weeks introducing myself to some of the big MVC Javascript Frameworks that have gotten so much traction over the last couple of years. I sadly, have found the field littered with frameworks that happily violate the principle of Unobtrusive Javascript and am wondering — is there any solid MVC Javascript Framework that is clean and unobtrusive, will I need to keep rolling my own, or am I just a Luddite?