Web technologies study: Our software frameworks preferences

Rafał Szczech
13 December 2018
5 min read

Our work is about getting things done in an efficient way. We have been through many projects now, which means we have applied many technologies too. So, after our fair experience working in the tech world, we can present our thoughts on the current situation in the web technologies market and why we use what we use.

The big battle among software frameworks:

Starting with a clean unbiased view, let’s take a look at which software frameworks people actually use nowadays. According to different sources (i.a. Octoverse from Github, JAXenter survey, Medium bloggers) the unquestionable king of the Internet is JavaScript with its all-star frameworks including React, Angular and Vue.js on the front end, and Node.js with Express/Nest.js on the back. It is usually followed by Java, PHP, and Python. And, last but not least, we have Ruby (usually paired with Rails) as one of the main back-end solutions.

The huge popularity of JavaScript is not an accident nor a surprise. The libraries available are usually fast, scalable, and flexible. It’s easy to code using all those modern frameworks, it’s efficient. Thanks to the massive recognition (and the backing of companies like Google and Facebook) the community is growing at a fast pace. It’s supportive, and it all helps the frameworks develop. The fact that the biggest of the current Internet built their apps using JS does nothing but help here. A few examples are Facebook, YouTubeTV, Instagram, Netflix, PayPal, WhatsApp, Dropbox, and the list actually goes on.

Our decision: efficiency as the final goal

So, we’re on board. We’re here for those sleek frameworks helping us build fast, engaging, bulletproof web apps. On a daily basis we use React and Angular (newest versions) as our main technologies on the front end. We support them with other languages and frameworks, but we believe that the base of the app should be as stable as possible (meaning proven efficiency and great support). Everybody can (and should) try to benefit from the most recent tech on the market (like we do with e.g. GraphQL, Prisma, Apollo, or even Vue.js), but should be aware too of the risks involved and definitely should secure the project as best possible.

From our experience, as much as we prefer JavaScript frameworks, we don’t recommend using AngularJS (the old version built differently than the current Angular without “JS”). It’s outdated and no longer improved as it’s been replaced by the younger brother.

Let’s talk about the back end. Here, we go with either the most popular JS solution (Node.js with Express) or with Ruby, Rails in specifics. It depends on which one we choose for the project, but we like them both and treat them equally. What’s important to us is, once again, efficiency, stability, scalability, and a great, great community. This is what makes the app and its tech rock solid.

We don’t do Java and PHP. We may be wrong since we don’t build the teams around those technologies by choice, but we don’t like them. They seem less updated, sluggish, and the community around them is slowly dying (but this particular one is more true for Java). There are still some situations in which we have to do something in either Java or PHP (as when e.g. the project has to be implemented in some old corporate system) and it’s not as smooth as we’d like. Our advice here is to do what we do: use it when you have to, but don’t let it be your first choice or the base for the application. It’s simply not worth it. It’s a slightly different story with Python as there are no technologies which could replace it when it comes to heavy data analysis and machine learning. But it’s a very specific need and doesn’t apply to a typical web application. We’re looking into the topic and we’ll definitely implement Python to our technology stack when such projects come.

What’s important about choosing the stack for the project (and it’s easy to forget about it) is what developers think. Being skilled in a language is one thing, but being excited about it a completely different topic. A happy developer is a good developer. They’re the core of almost every tech company out there and we shouldn’t force them to work in an environment which is a so-so for them. They won’t be awesome and, therefore, our product will suffer. The community (according to Github’s study confronted with Stack Overflow insights) states their love for Ruby, TypeScript, and JavaScript. They’re not the fans of Java and PHP. Interestingly, there’s something dividing about TypeScript: developers haven’t been very fond of it according to GitHub, but Stack Overflow states that it’s gaining more and more popularity and love. Among all the projects Githubbers contributed to this year, filtering by web frameworks only, we have two JavaScript representatives in top3 tags (React and Node.js) and Angular with Electron on positions 7 and 9. There’s no sign of Java and PHP languages/frameworks. We believe in data, trend analyses and listening to day-to-day users, and we’re sure that those takeaways from the report matter.

When it comes to practices, we always choose to separate the front end and the back end. Separate code, separate repository. These two groups need to focus on different things: UX, design, attention to visual details on the front, and more of a performance and architecture on the back. That’s why we don’t want to bother one group with the challenges of another. You won’t find Ruby bits in our front-end code, and you won’t find our backenders worrying about CSS. Our whole back end is simply an API. It communicates flawlessly with the front, but it’s not an integral part of it. Frontenders won’t be concerned about server problems and builds, and they could stay focused on their part of work. Again, we are on for efficiency.

So after all those trade-offs and data, we can conclude that: we build in React, Angular on the front end, and Node.js, Ruby on Rails on the back end, in various combinations. Sometimes we use other languages to support the project, but we hardly ever base the app on other technologies. We believe this is the right choice as we believe in data, developers’ satisfaction, stability, fast-paced development, results, and community, but we also love to follow the trends and to be a part of the group actually improving the web.

We’re open to questions about the future of web technologies and our choosing. Let us know if you’d like to know more about any particular software framework or its usage in specific situations. Do you agree with our way of building, or do you prefer doing it otherwise? 

Any comment you want to share with us? Drop us a line: hello@start-up.house

You may also like...


How can a monorepo help you build a scalable project more efficiently?

There are a few ways to handle multiple packages used to create one project. The multirepo model assumes that the packages are located in different code repositories. Monorepo is a singl...

Aleksandra Borowska
02 March 2021
4 min read

How to use Early Adopters to create a better product?

It’s no surprise that the number one reason for startups failing is not solving an existing market problem. Identifying real users’ pains is crucial when creating a new produ...

Marta Przyłęcka
23 February 2021
3 min read