Go was a natural choice for the backend of the Portainer web application. It makes the creation of HTTP API/services a breeze with a lot of standard features available in the ecosystem.

One of the main thing we like with Go is its synergy with Docker and how easy it is to leverage this synergy to easily distribute an efficient software:

• Go allows to compile a program for multiple platforms and OSes easily (it's just a matter of options when starting the compilation process, no matter the execution context)
• Go binaries are lightweight, fast and can have a low memory footprint

Combining these points with the empty scratch Docker image and multi-platform images, we can distribute Portainer for any environment that is running Docker. It allows our users to get started using the software in a matter of seconds.

Go is also heavily geared toward the creation of HTTP/API services and is a language that is easy to read and also quite easy to learn, making it a first choice in the context of Portainer.

So when starting a new project you generally have your go to tools to get your site up and running locally, and some scripts to build out a production version of your site. Create React App is great for that, however for my projects I feel as though there is to much bloat in Create React App and if I use it, then I'm tied to React, which I love but if I want to switch it up to Vue or something I want that flexibility.

So to start everything up and running I clone my personal Webpack boilerplate - This is still in Webpack 3, and does need some updating but gets the job done for now. So given the name of the repo you may have guessed that yes I am using Webpack as my bundler I use Webpack because it is so powerful, and even though it has a steep learning curve once you get it, its amazing.

The next thing I do is make sure my machine has Node.js configured and the right version installed then run Yarn. I decided to use Yarn because when I was building out this project npm had some shortcomings such as no .lock file. I could probably move from Yarn to npm but I don't really see any point really.

I use Babel to transpile all of my #ES6 to #ES5 so the browser can read it, I love Babel and to be honest haven't looked up any other transpilers because Babel is amazing.

Finally when developing I have Prettier setup to make sure all my code is clean and uniform across all my JS files, and ESLint to make sure I catch any errors or code that could be optimized.

I'm really happy with this stack for my local env setup, and I'll probably stick with it for a while.

I've always been passionate about knowing more about how #UX the products that I'm building and have used a bunch of session replay tools in the past, tools like Crazy Egg Hotjar Mixpanel but i am developing affinity for FullStory. I find searching for events to be effective and fast. i live the ability to see when users are frustrated and also skip inactivity, it's pretty intuitive.

I also feel that the creating funnels could be improved (like Mixpanel ) and also give recommendations about using your data tier more efficiently.

#StackDecisionsLaunch

When we rebooted our front-end stack earlier this year, we wanted to have a consolidated and friendly developer experience. Up to that point we were using Sass and BEM. There was a mix of HAML views, React components and Angular. Since our ongoing development was going to be exclusively in React, we wanted to shift to an inline styling library so the "wall of classnames" could be eliminated. The ever-shifting landscape of inline CSS libraries for React is sometimes difficult to navigate.

We decided to go with Glamorous for a few reasons:

1) Previous team experience with this library 2) We can write our styles in plain JavaScript (which brings many benefits) 3) It supports server-side rendering 4) It has great composition patterns

As you may or may not know, Glamorous has ceased active development and been mostly superseded by Emotion. We are planning to migrate to either Emotion or @styled-components in the near future, and I'll write another Stack Decision when we get there!

#inlinecss

We undertook the task of building a manufacturing ERP for small and tiny craft workshops. To have clear focus on product delivery we chose JavaScript , Heroku and Heroku Postgres . This decision has guided us to picking other key technologies. It has granted us high pace of product delivery and service availability.