Flexible Data Model Design
How to grow your project without failing at architecture, scalability and system integration
Fast creation of performance tests based on SoapUI project
How to Improve Performance of AWS Java Cloud App? Try ElastiCache
How You Can Use Cassandra in the Big Data World
Harnessing the chaos in software project management
Working in a Virtual Team
Database: How To Make a Bad Thing Work Well
Smart Version Control for Project Managers and Decision Makers
Unlocking the Power of Industrial Automation Through Java

ISS Art technology stack in 2015

New technologies appear every day, and we try to stay in step with this tendency. But we don’t jump blindly to every new fashion, because this way we can spend a lot of effort for nothing. For commercial development, it is always better to wait a little bit and make sure that the transition to a new technology will really pay off.

The table below shows our main technology stack in 2013 and 2014 years and our plans about what to try in 2015.

2013 2014 2015
PHP framework Zend 1 Zend 1 + Doctrine Symfony + Doctrine 2
Java framework Restlet Restlet Spring
Client language JavaScript JavaScript TypeScript
Client framework jWidget jWidget, AngularJS jWidget + ReactJS
Stylesheets CSS CSS, Stylus LESS, Stylus
Client package manager Bower

Why Symfony?

Zend 1 doesn’t meet modern standards anymore, so we have to make a choice from Zend 2, Symfony and a bunch of other PHP frameworks. Symfony seems the most solid and well-thought one for us. In particular, it has a built-in ORM Doctrine 2, a good view system, code generators and dependency injection. And we haven’t forgotten about Zend 2 either.

Why Spring?

Spring framework provides perfect implementation of IoC container implementing dependency injection principle which is crucial in backend application development. Dependency injection simplifies interaction between objects, makes mock object creation easier for unit testing. Also, Spring framework introduces MVC pattern implementation and a lot of other bonuses useful in Web development. And thanks to splitting Spring by projects it is very lightweight.

Why TypeScript?

For such object-oriented programming zealots as we are, it is inconvenient to develop the dynamically typed code in JavaScript. We prefer to know what fields each class has and it would be really great if IDE helped us to develop code. So, it would be really great to select some kind of a replacement for JavaScript. There are 3 well known replacements: CoffeeScript, Dart and TypeScript.

CoffeeScript is way too crazy for us and it doesn’t give us what we actually want.

Dart has a huge advantage compared to other replacements – a Virtual Machine which is much faster than JavaScript. But the VM is supported by Google Chrome only now and other browsers don’t have any plans to add Dart VM support in the nearest future. But the crucial part is that Dart is very much tied to Google now – it has an IDE from Google, a package manager from Google and package repository from Google and there’s nothing you can do in Dart without communicating to Google servers. Even if you develop your own library, you must publish it in Google repository. The language doesn’t have a big library base, and it is quite difficult to communicate between Dart and JavaScript code. So, at this point, it is way too early for us to give it a shot. Maybe in future.

TypeScript doesn’t have the majority of Dart advantages, but it is very safe for us to transition to it now. TypeScript is not as ambitious of a technology – it is just a superset of JavaScript syntax which gives us whatever we need: static types, interfaces, classes, generics etc. It is completely compatible to all existing JavaScript libraries and frameworks, so why not to try it?

Why not AngularJS?

Thanks to an aggressive advertisement campaign from Google, AngularJS has become a very fashionable technology in 2014. So we’ve given it a shot at one of our projects. The outcome wasn’t as good as Google promised us for it to be. We’ve spent twice as much time as we expected the project to take, and the code wasn’t as clear as it would be if selected Backbone or jWidget. Several great articles explain the major AngularJS pitfalls, and I see all the pitfalls that we faced in our AngularJS development in them too.

Why ReactJS?

ReactJS is a great replacement for AngularJS and for UI part of jWidget framework. It is fast, simple and clear. There are two problems with it, but they are not crucial:

  • Inability to communicate directly to DOM elements rendered with ReactJS. So, for example, it is quite difficult to use jQuery UI components inside ReactJS code. But it is possible, so we don’t care.
  • Lack of model. Usually ReactJS developers take Backbone model and inject it into ReactJS components. We are going to try a jWidget model with ReactJS, because jWidget model is essentially a powerful extension of Backbone model.

Why Stylus and LESS?

Stylus is a cute replacement for plain CSS. It has a lot of features and makes stylesheets clear, simple and easy to maintain. LESS is a bit bulky, but it has a better IDE support compared to Stylus. So, we’ll use LESS until a bunch of IDEs will provide support for Stylus. There’s one more well known CSS preprocessor – Sass, – but it has a major pitfall. The next selector doesn’t work in Sass: &-suffix, and it is crucial for us.


With Bower, it is unneccessary to commit the third-party libraries to repository anymore. This is not crucial, but still awesome.

This was the list of technologies we are going to use in 2015. The list is not limited to the above mentioned technologies however.

What will you try in 2015?

About the author

Egor Nepomnyaschih

Egor is an experienced software developer working with JavaScript, PHP, Java, Unity technilogies. He is happy to share his expertise with all the industry peers.

  • andrwek

    Do you use any task runner?

    • enepomnyaschih

      At the server side, simple Bash scripts combined with Maven project manager (http://maven.apache.org/) and Liquibase DB version control (http://www.liquibase.org/) are usually enough for Java projects.

      At the client side, we use jWidget SDK (https://github.com/enepomnyaschih/jwsdk/wiki/en) to build and optimize our JavaScript. We are struggling about transitioning to a fully capable task runner like GruntJS (http://gruntjs.com/). We couldn’t find a stack of plugins which covers jWidget SDK
      features and keeps up in performance regard. The build process is very
      slow because none of GruntJS plugins provides intermediate information
      which the other plugins can reuse. I’ve posted a separate article about that in my personal blog (http://enepomnyaschih.livejournal.com/17611.html). May be I’m wrong though. If we’ll be
      able to deal with GruntJS performance, probably we’ll transition to it.

      At PHP projects, we also use Assetic (https://github.com/kriswallsmith/assetic) as an alternative to jWidget SDK and Doctrine (http://www.doctrine-project.org/) as an alternative to Liquibase.

      • andrwek

        did you change these tools in last 2 years? if yes, I think it will be better add such information to your post.

        btw: what do you think about gulp vs grunt?

        • enepomnyaschih

          Yes, we’ve introduced a bunch of new features in jWidget and jWidget SDK in last 2 years, but since these tools are not quite popular, I don’t think that anyone cares about their history. If you mean, did we use anything else intensively before 2013 – the answer is jQuery and Flash. Also we use ExtJS in special cases.

          Never heard about gulp. I’ll take a look, thank you for the reference.

  • Looks like a thorough choice, especially for JS!