Altabel Group's Blog

Posts Tagged ‘NodeJS

Introducing ASP.NET Core:

ASP.NET Core is a new open-source and cross-platform framework for building modern cloud based internet connected applications, such as web apps, IoT apps and mobile backends. ASP.NET Core apps can run on .NET Core or on the full .NET Framework. It was architected to provide an optimized development framework for apps that are deployed to the cloud or run on-premises. It consists of modular components with minimal overhead, so you retain flexibility while constructing your solutions. You can develop and run your ASP.NET Core apps cross-platform on Windows, Mac and Linux. ASP.NET Core is open source at GitHub.

The framework is a complete rewrite that unites the previously separate ASP.NET MVC and Web API into a single programming model.

Despite being a new framework, built on a new web stack, it does have a high degree of concept compatibility with ASP.NET MVC.

ASP.NET Platform exists for more than 15 years. In addition, at the time of System.Web creation it contained a large amount of code to support backward compatibility with classic ASP. During this time, the platform has accumulated a sufficient amount of code that is simply no longer needed and is deprecated. Microsoft faced a difficult choice: to abandon backward compatibility, or to announce a new platform. They chose the second option. At the same time, they would have to abandon the existing runtime. Microsoft has always been a company focused on creation and launch on Windows. ASP.NET was no exception. Now the situation has changed: Azure and Linux occupied an important place in the company’s strategy.

The ASP.NET Core is poised to replace ASP.NET in its current form. So should you switch to ASP.NET Core now?

ASP.NET Core is not just a new version. It is a completely new platform, the change of epochs. Switching to ASP.NET Core can bring many benefits: compact code, better performance and scalability. But what price will be paid in return, how much code will have to be rewritten?

.NET Core contains many components, which we are used to deal with. Forget System.Web, Web Forms, Transaction Scope, WPF, Win Forms. They no longer exist. For simple ASP.NET MVC-applications changes will be minor and the migration will be simple. For more complex applications, which use a great number of .NET Framework classes and ASP.NET pipeline situation is more complicated. Something may work and something may not. Some part of the code will have to be rewritten from scratch. Additional problems may be caused by WebApi, because ASP.NET MVC subsystems and WebAPI are now combined. Many libraries and nuget-packages are not ready yet. So, some applications simply will not have a chance to migrate until new versions of the libraries appear.

I think we are waiting for the situation similar to the transition from Web Forms to ASP.NET MVC. ASP.NET Framework will be supported for a long time. First, only a small amount of applications will be developed on ASP.NET Core. Their number will increase, but sooner or later everyone will want to move to ASP.NET Core. We still have many applications running on the Web Forms. However, no one comes to mind to develop a new application on the Web Forms now, everybody chooses MVC. Soon the same happens to ASP.NET Framework, and ASP.NET Core. ASP.NET Core offers more opportunities to meet modern design standards.

The following characteristics best define .NET Core:

  • Flexible deployment: Can be included in your app or installed side-by-side user- or machine-wide.
  • Cross-platform: Runs on Windows, macOS and Linux; can be ported to other OSes (Operating Systems). The supported OSes, CPUs and application scenarios will grow over time, provided by Microsoft, other companies, and individuals.Command-line tools: All product scenarios can be exercised at the command-line.
  • Compatible: .NET Core is compatible with .NET Framework, Xamarin and Mono, via the .NET Standard Library.
  • Open source: The .NET Core platform is open source, using MIT and Apache 2 licenses. Documentation is licensed under CC-BY. .NET Core is a .NET Foundation project.
  • Supported by Microsoft: .NET Core is supported by Microsoft, per .NET Core Support.

The Bad:

  • As for the “cons” one of the biggest issues are gaps in the documentation. Fortunately most of the things for creating and API are covered, but when you’re building an MVC app, you might have problems.
  • Next problem – changes. Even if you find a solution to your problem, it could have been written for a previous version and might not work in the current one. Thanks to open source nature of it, there is also support available on github. But you get same problems there (apart from searching).
  • Another thing is lack of support in the tooling. You can forget about NCrunch or R# Test Runner. Both companies say they will get to it when it gets more stable.
  • ASP.NET Core is still too raw. Many basic things, such as the Data Access, is not designed for 100%. There is no guarantee that the code you are using now will work in the release version.

The Good:

  • It’s modular. You can add and remove features as you need them by managing NuGet packages.
  • It’s also much easier and straightforward to set up.
  • WebApi is now part of the MVC, so you can have class UserController, which will return a view, but also provide a JSON API.
  • It’s cross-platform.
  • It’s open-source.

ASP.NET Core is the work on the bugs of the classic ASP.NET MVC, the ability to start with a clean slate. In addition, Microsoft also aims to become as popular as Ruby and NodeJS among younger developers.
NodeJS and ASP.NET have always been rivals: both – a platform for backend. But in fact, between them, of course, there was no struggle. The new generation of developers, the so-called hipster developers, prefer Ruby and Node. The adult generation, people from the corporate environment, are on the side of .NET and Java. .NET Core is clearly trying to be more youthful, fashionable and popular. So, in future we can expect the .NET Core and NodeJS to be in opposition.

In its advertising campaign, Microsoft is betting on unusual positions for it: high performance, scalability, cross-platform. Do you think that ASP.NET “crawls” on the territory of NodeJS? Please feel free to share your thoughts with us.

Thank you in advance!



Darya Bertosh

Darya Bertosh

Business Development Manager

Skype: darya.bertosh
LI Profile: Darya Bertosh



Altabel Group

Professional Software Development



Whether you’re building apps for the browser, mobile or desktop, Aurelia can enable you to not only create amazing UI, but do it in a way that is maintainable, testable and extensible.

Retrospective and today

Aurelia is a project of Rob Eisenberg, the author of a very popular MV * – framework for Caliburn.Micro XAML-platforms, Durandal. Understanding all the disadvantages of Durandal, Eisenberg engaged in the development of so-called NextGen framework. In 2014 he began to work in Angular team on the second version of the framework. However, several months later, Rob decided to leave the Angular team since the direction of Angular 2, in his opinion, had changed a lot. He gathered a large team and returned to work on the framework of his dreams. And Aurelia is the result of that work.

JavaScript of tomorrow?

By using modern tooling Aurelia was written from the ground up in ECMAScript 2016. This means you have native modules, classes, decorators and more at disposal.
Aurelia is written in modern and future JavaScript, it takes a nowadays approach to architecture. It’s built as a series of collaborating libraries, which form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia’s libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS.
Aurelia’s code is open sourced under the MIT License, a very permissive license used by many popular web projects today. The starter kits are available under the Creative Commons 0 license. There is also a Contributor for those who wish to join the team in working on Aurelia. Ultimately, this means that you can use Aurelia without fear of legal repercussions and it can be build in the same confidence.

Benefits of Aurelia

Clean and Unobtrusive – Aurelia is the only framework that lets you build components with plain JavaScript. It stays out of your way so your code remains clean and easy to evolve over time.

Convention over Configuration – Simple conventions help developers follow solid patterns and reduce the amount of code they have to write and maintain. It also means less fiddling with framework APIs and more focus on their app.

Simple, But Not Simplistic – Because of the simple design developers are able to learn a very small set of patterns and APIs that unlock limitless possibilities.

Promotes the “-ilities” – Testability, maintainability, extensibility, learnability, etc.- Aurelia’s design helps developers to naturally write code that exhibits these desirable characteristics.

Amazingly Extensible – Aurelia is highly modular and designed to be customized easily, so developers will never hit a roadblock or have to “hack” the framework to succeed.

Web Standards Focused – Focused on next generation JavaScript and Web Components, and avoiding unnecessary abstractions that obscure the underlying web, Aurelia is the cleanest and most standards-compliant framework today.

Integrates Well with Others – Easily integrated with any 3rd party library or framework: for instance, with jQuery, React, Polymer, Bootstrap, MaterializeCSS and much more.

TypeScript Support – Each Aurelia library is released with its own d.ts files. There are also official TypeScript beginner kits and production quality starter kits.

An Official Product with Commercial Support – Being an official product of Durandal Inc., it has commercial and enterprise support available, so you can use Aurelia for building core technology for your business.

Thriving Community and Ecosystem – Having one of the largest developer gitter channels in the JavaScript world, oodles of contributors and a huge core team, Aurelia has been used to build just about every type of application and is used by large, well-known multi-national companies and enterprises.
Aurelia, Angular and React.js – what’s common and what’s different?

Aurelia vs. Angular

Similarities between Aurelia and Angular 2:

  • Aurelia offers ES6-support out of the box and supports all forms of alternative abstraction syntax such as TypeScript and CoffeeScript. Migration documentation about migrating from Angular 1 and 2 have been put on the roadmap.
  • The basis of both Angular 2 and Aurelia application comprise components associated with the corresponding template.
  • Differences in vision details and options range:

  • The syntax is much simpler and more explicit (i.e. self-explanatory) than Angular 2 and looks a lot like standard JS syntax. ES6 and JSPM are used by default and a gulp file with a custom-built system to transpile ES6 to ES5 using the Babel transpiler is included in the standard package.
  • Aurelia also uses conventions instead of its own syntax and boilerplate code. No special characters like the ones in Angular 2 (*, (), [] en #) here.
  • Aurelia is built in a modular way making it very pluggable. You can plug in internationalization, routing, virtualization, animation, … Besides that, third party plugins are available as well such as the aurelia-flux plugin adding the Flux dispatcher to Aurelia.
  • The presence of a root-component is necessary; it represents an application (app). The metadata may / should be attached to components by using decorators. Component initialization is performed by using dependency injection. In addition, each component has a declared lifecycle, which can be built by using the lifecycle hooks. The components may be formulated into a hierarchical structure.
  • Communication between the component and the template is performed by using data binding. The process of template rendering to the final HTML can be integrated by using pipes (Angular) or value converters + binding behaviours (Aurelia).
  • The main advantage of Aurelia in comparison to Angular is an advanced composition mechanism and template parts. Aurelia is designed with an emphasis on unobtrusive, the number of framework structures in the final code is minimal. Aurelia is more compact, while Angular sometimes simply forces to produce copy-paste.
  • Aurelia is new to the market while Angular has a big user base because it’s already been around for 6 years. On the other hand, Aurelia has great documentation available, it’s an official product of Durandal Inc, and the company has a long term vision for the product, something the Angular team doesn’t seem to have and is blamed for a lot.

Aurelia vs. React.js

  • While on the surface it might not seem fair to compare Aurelia to React.js, they’re both being used for the same things. Despite the fact that React.js is a fully-fledged and functionally released product without the early preview alpha tag and Aurelia is not, at current stage they are both pretty at the same level. You can achieve the same tasks within both, just in different ways.
  • As for React components and Aurelia’s ViewModel’s, they are both quite similar in that you’re essentially using a class to define properties and methods bound to a particular view. The primary difference between them is React doesn’t separate the logic from the view, meaning in React the View and ViewModel are both within the same file.
  • However, that’s not to say that Aurelia doesn’t allow you to achieve the same thing by rendering the View from within the ViewModel as well and forgoing a traditional View.
  • The original intent behind React.js was not to be a competitor to the likes of Angular or Aurelia, but rather be the library that everyone uses with their SPA framework like Angular to improve performance.
  • Therefore, this means you can easily use React.js within Aurelia. Aurelia and React.js can be used together and in doing so, it provides you with a level of power other frameworks cannot without subsequent complexity and strict convention like EmberJS.

Aurelia vs. Angular and React

  • Two-way binding is provided out of the box and the framework does so very precisely. By default, 1-way databinding is used except for form controls, a clear plus when compared to React. Do keep in mind that two-way data binding can only be done through explicit syntax, as is the case in Angular 2.
  • The learning curve for Aurelia is comparable to that of Angular 2 and thus a lot steeper than React’s. Luckily, the extensive documentation makes up for that a great deal.
  • Angular 2 and Aurelia Architecture is very similar. Aurelia looks a lot like Angular 2 in the sense that it’s a complete framework that relies on the web standards. It’s as pluggable as React is and as Angular 2 will be.
  • While Angular was created by Google and React by Facebook, they don’t provide commercial or enterprise support, something that Aurelia will do.


It goes without saying why these three frameworks are so popular. They all have a lot of strong advantages. Eventually, I’m favoring Aurelia: there’s solid documentation available and the overall philosophy is the same with Angular 2, but Aurelia is a better choice from the syntax and execution point of view. The architecture and syntax vision of Aurelia team seems to be more clear than the vision of the Angular team. The company and enterprise support of Aurelia is also a big pro.
What is your personal experience with these frameworks? Which one would you choose for your projects and why? What’s your prediction “who” will win the crown in the nearest future? Please feel free to share your thoughts with us.

Thank you in advance!


Darya Bertosh

Darya Bertosh

Business Development Manager

Skype: darya.bertosh
LI Profile: Darya Bertosh



Altabel Group

Professional Software Development


The IT world is constantly forging ahead. There already exist several dozens of programming languages and software technologies. At the same time to choose the right thing for a specific project is not an easy thing to do.

Every technology has its own advantages and disadvantages. Hence, if you want to choose a certain implementation, which will be effective for both-development and its further support, you need to consider following issues: project scalability, its tasks and timeframes.

Large-scale projects (high load systems)

For big and high load systems (more than 3000 queries per sec, beginning from 10000 database tables) it is necessary to choose the technologies very comprehensively, as it will influence the general project productivity and security.

There are 4 suitable languages for the backend: Java, NodeJS, PHP and ASP. Though it’s better to use Java, as it allows achieving effective work speed, and gives the possibility to support hyperthreading and refacoring. Moreover, Java is one of the best fit from the point of view of development speed – there are plenty of handy frameworks.
It is better to remember, that NodeJS is a bit difficult to use when it comes to complicated calculations. Nevertheless, it helps to provide an easy project scalability and processing speed.

For the frontend it is better to use JavaScript and HTML. JavaScript makes any calculations much faster, while Flash copes better only with rendering, and HTML5 is not supported by all tools yet. That is why standard (as it may seem for many developers) suite of HTML and JavaScript is the best option here.

When it comes to high load systems, one should remember about extensibility, because it is one of the problem developers face to most often. Hence, it is necessary to think over the work layout with a database in details. For big projects it is better to put away relational databases, and turn attention to non-relational models, such as MongoDB и Redis. It is possible to use CouchDB as well.

It is relational bases that place a limit on the projects and do not give an opportunity to be extended easily. Non-relational models have a completely different structure: instead of SQL-queries API are used.

Middle-scale projects

While working on middle-scale projects (1000-3000 queries per sec, 2000-10000 database tables), i.e. not too load, but not home pages either, it is possible to use Java and PHP. In this case NodeJS will not give such attractive results as in high load projects.

Besides HTML and JavaScript, for the frontend it is allowed to use HTML5 and Flash as well. Nevertheless, it is necessary to be very careful here. The notion of middle-scale project is quite vague, thus, one should to draw upon the project tasks. If the question is about a small graphic maintaining, then probably it will make sense to replace Flash by the last HTML version (HTML5) together with JavaScript. In case the project needs detailed rasterizing and full script of graphic action, then Flash would be the best solution.

Databases can be both relational and non-relational. Everything depends on the further project development. If it is planned to grow rapidly, it is better to use non-relational models MongoDB or Redis. If a too big scalability is not required, Oracle will perfectly fit. The point is that in spite of being relational, Oracle is used in many projects that have a potential to scalability. At the same time there no extension problem emerge, even if several servers are used.

Small projects

When the question is about small projects (less than 1000 queries per sec, 2000 databases), it is essential to put away all the complicated things, that present in high load systems. Consequently, PHP, Ruby on the Rails (this framework allows fast development), Erlang are best for development here. No doubt Java can fit as well, though it would be much faster and easier to use PHP or Ruby.

For the frontend it’s better to practice Javascript, HTML5, HTML, Flash/Flex. Most often small projects do no presuppose a big growth, that is why MySQL or PostgreSQL are better to be chosen as a database. Oracle may turn to be too bulky and unprofitable for the client, while MongoDB and Redis will not be effective. The thing is that despite growing popularity of non-relational databases, the smallest mistake in their usage can entail serious consequences. In this context relational models are much easier. Hence, while working on small projects it is better not to spend time and practice relational models, such as MySQL and PostgreSQL.

To sum up everything above said, Java, NodeJS, PHP, ASP + JavaScript and HTML + MongoDB or Redis are better to be used while developing high-load projects. For middle-scale projects- Java, PHP + JavaScrit, HTML, HTML5, Flash + Oracle, MongoDB, Redis. For small ones – PHP, Ruby on the Rails, Erlang + JavaScript, HTML, HTML5, Flash + MySQL, Postgre SQL.
Anyway, apart from the project scalability it is essential to consider its potential. The reason is that the problems start after the project growth, when developers face to inability of an adequate project transfer to other servers and workload distribution. Besides, it is important to keep in mind the project tasks. It is highly possible to turn out, that what is popular today will not be effective for a specific project.

You know that my opinion is not the ultimate truth 🙂 I would be glad to read about your experience of using languages, databases while working on different projects!

Kind regards,

Nadya Klim

Business Development Manager



Altabel Group

Professional Software Development


%d bloggers like this: