Russel Werner

If you want to prioritise language familiarity, JavaScript is more like Java than the other choices; and it can be optimised to run very fast. However if you need really fast cold-start times, you can't beat Go since it's compiled. There are other things to consider, such as the massive amount of community packages and help/documentation in the JavaScript ecosystem. Go is newer but seems to be quite popular if you need something that runs fast in a single binary.

I chose WebStorm because its a mature and stable production that has every feature I could ask for in an IDE. It saves me time and catches mistakes. All my normal development tasks, including amazing VCS integration, can be done quickly from a single place. They continue to make updates and integrate popular tools and frameworks.

Some people might complain that WebStorm costs money, however it is a relatively cheap piece of software for the number of hours you use it. Definitely worth it!

All of JetBrains other products are equally as awesome and provide a common interface. I also use Goland, RubyMine, and CLion. I used PHPStorm for 7 years and loved it.

I work at the same company as you and I use WebStorm for 99% of my tasks. I also have RubyMine installed and use that when I have to tweak some backend code. I tried using RubyMine for JavaScript but was unhappy with how it felt and I believe that WebStorm is faster because it has less plugins and language extensions running. Summary: Buy and use WebStorm for primary development and keep VS Code around for when you have to touch Ruby.

We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.

We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.

The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.

We use Yarn because at the time we decided to adopt it, npm had some missing features and issues. We like the speed and determinism provided by Yarn. We could probably use npm at this point, but we have no real reason to switch from Yarn. If you have a convincing argument to switch from npm to Yarn please leave a comment on this decision!

We use Jest because when we rebooted our "front end" stack earlier last year, we need to have a testing solution (we didn't have any front-end tests before that!). Jest is fast and convenient and it has plenty of community support behind it. It let's us run our unit tests with Enzyme and snapshot tests.

This is an area that we are constantly reviewing to see what can be improved, both in terms of developer needs, accuracy, test maintainability, and coverage.

I'm currently exploring using React Storybook to be the record of snapshot tests and using some online services, such as Happo.io and Percy in our CI pipeline.

We use Babel because here at StackShare, we love using the latest and greatest technology, and this includes the latest and greatest JavaScript language features. We try to keep it simple, while maximising our developer happiness and efficiency.

We are currently using the @babel/env and @babel/react presets, along with a few plugins, including the "dynamic import" syntax, so we can pull in bundles async.

We use Prettier because when we rebooted our front-end stack, I decided that it would be an efficient use of our time to not worry about code formatting issues and personal preferences during peer review. Prettier eliminates this concern by auto-formatting our code to a deterministic output. We use it along with ESLint and have 1st-class support in our WebStorm and Visual Studio Code editors.

We use HTML5 because it has now become the standard in building websites. We have recently performed a "semantic sweep" of our markup and are now using the newer HTML5 semantic tags for the various content across our pages. This includes <aside>, <header>, <main>, <nav>, etc. We are also making more use of CSS transitions where it makes sense and enhances the user experience.

Some of our existing pages use MobX however we decided to stop using MobX for new work for a few good reasons:

1. It forced us to use an experimental language feature (decorators)
2. We went all-in on GraphQL and Apollo to manage our data and local state.

For all the places where we don't store state in Apollo Client, we use plain old React and hooks (useState and useContext). Our first choice in state management it to have all state stored in Apollo keeping local state accurate by using mutation updates, client resolvers, and local cache.