Alternatives to ClojureScript

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

React is awesome, but is just a view library, when we need to manage state, there is Redux.js. The ecosystem of redux is big, complex and hard to integrate. That's why we choose to create hydux. Hydux is simple, the main idea is from Elm, a pure functional vdom-based framework for front-end. We seperate the whole app with state, actions and views. Which means not only our views are a tree, but also our state and actions. Reuse state and actions are just like reuse react components, no need to consider dependences.

Stitch is run entirely on AWS. All of our transactional databases are run with Amazon RDS, and we rely on Amazon S3 for data persistence in various stages of our pipeline. Our product integrates with Amazon Redshift as a data destination, and we also use Redshift as an internal data warehouse (powered by Stitch, of course).

The majority of our services run on stateless Amazon EC2 instances that are managed by AWS OpsWorks. We recently introduced Kubernetes into our infrastructure to run the scheduled jobs that execute Singer code to extract data from various sources. Although we tend to be wary of shiny new toys, Kubernetes has proven to be a good fit for this problem, and its stability, strong community and helpful tooling have made it easy for us to incorporate into our operations.

While we continue to be happy with Clojure for our internal services, we felt that its relatively narrow adoption could impede Singer's growth. We chose Python both because it is well suited to the task, and it seems to have reached critical mass among data engineers. All that being said, the Singer spec is language agnostic, and integrations and libraries have been developed in JavaScript, Go, and Clojure.

Most of CircleCI is written in Clojure and it has been this way since almost the beginning. Early development included Rails, but by the time that CircleCI was released to the public, it was written entirely in Clojure. Clojure is still at our platform’s core. It helps having a common language across much of our stack to allow for our engineers to move between layers of the stack without much overhead.

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen—since I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.

A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.

In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.

If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.

Our whole Node.js backend stack consists of the following tools:

• Lerna as a tool for multi package and multi repository management
• npm as package manager
• NestJS as Node.js framework
• TypeScript as programming language
• ExpressJS as web server
• Swagger UI for visualizing and interacting with the API’s resources
• Postman as a tool for API development
• TypeORM as object relational mapping layer
• JSON Web Token for access token management

The main reason we have chosen Node.js over PHP is related to the following artifacts:

• Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
• Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
• A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
• Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.

Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:

• Nuxt.js consisting of Vue CLI, Vue Router, vuex, Webpack and Sass (Bundler for HTML5, CSS 3), Babel (Transpiler for JavaScript),
• Vue Styleguidist as our style guide and pool of developed Vue.js components
• Vuetify as Material Component Framework (for fast app development)
• TypeScript as programming language
• Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
• ESLint, TSLint and Prettier for coding style and code analyzes
• Jest as testing framework
• Google Fonts and Font Awesome for typography and icon toolkit
• NativeScript-Vue for mobile development

The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:

• Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
• Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
• Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
• Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
• Large scaling. Vue.js can help to develop pretty large reusable templates.
• Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.

I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.

I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!

I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.

Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.

Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.

With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.

If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.

Your tech stack is solid for building a real-time messaging project.

React and React Native are excellent choices for the frontend, especially if you want to have both web and mobile versions of your application share code.

ExpressJS is an unopinionated framework that affords you the flexibility to use it's features at your term, which is a good start. However, I would recommend you explore Sails.js as well. Sails.js is built on top of Express.js and it provides additional features out of the box, especially the Websocket integration that your project requires.

Don't forget to set up Graphql codegen, this would improve your dev experience (Add Typescript, if you can too).

I don't know much about databases but you might want to consider using NO-SQL. I used Firebase real-time db and aws dynamo db on a few of my personal projects and I love they're easy to work with and offer more flexibility for a chat application.