Skip to content
markdown guide

Well, this might be a quite generic answer, but: it depends on the project.

First of all, if it's a work project, I'm usually not the one choosing.

If it's a side project (personal), it depends on the complexity of the project. If it's not too complex I might choose a tech that I don't know or lack experience with, to learn more about it. If it's a more complex project, I might go with some more familiar technologies, for efficiency.


Well, I don't code outside of my work that much, but at the work whenever we have a new project to be created, we just discuss what tech stack fits into the app (also it depends on how much time we have to provide a MVP, so if there's plenty of time we'd go with something we don't know that much, and vice versa). Python and some frameworks in most cases. And outside of my work, it depends on the project I'm contributing to 😊


Usually, I don't, somebody chooses it for me.

But if I can choose, I always prefer the one the maintainers will be more comfortable with. For example, when building something for a company with many PHP developers, I'd chose PHP. Applies well to languages, databases, operating systems etc.

(Of course, my previous choices create a bias here. I'm quite language agnostic but I rarely do anything for Windows, for example.)

If I have even more choice, I choose the most boring technologies available. The ones with more developers, more history, more projects. They tend to be more stable and cheaper.


I think in terms of constraints.

In my case, when I started my current project I was new to programming and working alone. Those constraints meant that I needed technologies that had a fast learning curve, great documentation, and the ability to build quickly. Rails checked all those boxes, and Heroku abstracts away most DevOps concerns, so I can focus on the app itself.

For experienced programmers (familiarity), large teams (clarity/explicitness/decentralization), or businesses with legacy infrastructure (interoperability), the constraints are different.


Basically based on familiarity. In this decade we have the luck of having a huge variety of technologies which all work great, so it doesn't really matter if you use .NET or Java, Vue.js or Angular. But then that's just me.


Dont mix "technology" with "programming language". Like: are you using a relational db or a nosql option? Are you going to run on premise or on the cloud? Would you use heavy batch processing or message streaming and lambda architecture? A desktop app, a web or a mobile app? I could continue but I asume I made muy point. I have read the following in this thread, but I think it's so important I'll repeat it: you need a strong part to be able to innovate somewhere else. Tip: make your decissions thinking on tour project, not your CV


I am usually in charge of the front-end-part of the projects we do. It's e-commerce-websites done with Hybris mostly, so I'm pretty free to pick an approach.

We usually need CSS, JS, Icons and static templates for prototyping.

For CSS I would stick to SASS with auto-prefixing and uglifying by PostCSS. I went with PostCSS-only for a former project, but I wouldn't againβ€”SASS is just so much simpler to handle and set up.

For JS it's usually ES6-Syntax with modules in their own files. There's a global event-handler for cross-module-communication and if state is needed it's stored in data-attributes in the DOM. I probably wouldn't need jQuery for new projects, but some Out-of-the-box-Hybris-Stuff still needs it so we might as well leverage it where it makes sense (getting DOM-Nodes out of HTML-Strings mostly).

For icons I tried Sprites, Icon-Fonts, Grunticons, but nothing beats inserting SVG into the DOM. Never doing it differently again. (Until something better shows up!)

For HTML-Templates I try to pick the simplest to set up, which has been for the last projects. I hope to find something quicker and simpler, though. I might use Hugo for the next.

This is all for server-rendered sites. I don't have prod-experience with SPAs like React/Angular/etc. yet, but I'd most likely go with Angular if I were asked forced to pick one, because it seems to be the best for hiring and prominent in the enterprise-area (as in "nobody ever got fired for picking Angular").

Personally I prefer React and use it with styled-components for the new frontend for I like its functional nature and how lightweight it is.

Classic DEV Post from Sep 21 '18

Tried TDD and didn't realize the benefits? Try it the next time you get writer's block

Originally published at This is a cross-post from my content bl...

Tailo Mateus Gonsalves profile image
I'm also addicted to learning new things.

Don't ghost on us ❀️