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...
Web technologies study: Our software frameworks preferences
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:
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.
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.
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: firstname.lastname@example.org.
You may also like...
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...