A developer and project manager from our team X says the following about our use of Rails at i22:

"We use Rails to build stable and flexible backend systems. Rails is extremely good for managing data structures and quickly setting up new systems. It is the perfect base for most use cases."

I asked the same Team X member why the team prefers to work with Ruby on Rails, rather than Python and Django:

"Because Python is a scripting language and from my point of view not suitable for building stable web services. Python is for me rather good for scripts and fast small tools. Not for stable business applications. And if I want it fast I prefer Go."

• Client-Side: \ The form of our product is a web app because we would also provide a dashboard for displaying data and for some further purpose including data filtering and comparison. Hence, we would definitely use HTML5 for structuring the web, CSS3 for styling the web, and JavaScript for building the front-end logic. As for frameworks, we would use React because it is component-based that can keep our front-end code clean and organized. The virtual DOM of React also provides better efficiency in time when rendering the page. Furthermore, React has a greater number of users than Vue and Angular, thus have active communities for problem-spotting and problem-solving. We would also incorporate Bootstrap into our web app to provide an aesthetic user interface and thus to improve the user experience. The fact that Boostrap supports responsive site would also ease our workload if future adaptation for mobiles is needed.

Frontend:

• For our web app frontend, we decided to use TypeScript as our programming language because it supports all functionality of JavaScript and supports optional typing to the language, which can help us take advantage of OOP.
• We chose ReactJS as our frontend library because its state management would be very handy for our single-page app. React is also component-based, which can help us improve the modularity and extensibility of the project.
• Aside from the standard web technology HTML/CSS, we will useBootstrap to style UI components and make our web app responsive to different screen sizes.

I was considering focusing on learning RoR and looking for a work that uses those techs.

After some investigation, I decided to stay with C# .NET:

• It is more requested on job positions (7 to 1 in my personal searches average).

• It's been around for longer.

• it has better documentation and community.

• One of Ruby advantages (its amazing community gems, that allows to quickly build parts of your systems by merely putting together third party components) gets quite complicated to use and maintain in huge applications, where building and reusing your own components may become a better approach.

• Rail's front end support is starting to waver.

• C# .NET code is far easier to understand, debug and maintain. Although certainly not easier to learn from scratch.

• Though Rails has an excellent programming speed, C# tends to get the upper hand in long term projects.

I would avise to stick to rails when building small projects, and switching to C# for more long term ones.

Opinions are welcome!

We have a lot of experience in JavaScript, writing our services in NodeJS allows developers to transition to the back end without any friction, without having to learn a new language. There is also the option to write services in TypeScript, which adds an expressive type layer. The semi-shared ecosystem between front and back end is nice as well, though specifically NodeJS libraries sometimes suffer in quality, compared to other major languages.

As for why we didn't pick the other languages, most of it comes down to "personal preference" and historically grown code bases, but let's do some post-hoc deduction:

Go is a practical choice, reasonably easy to learn, but until we find performance issues with our NodeJS stack, there is simply no reason to switch. The benefits of using NodeJS so far outweigh those of picking Go. This might change in the future.

PHP is a language we're still using in big parts of our system, and are still sometimes writing new code in. Modern PHP has fixed some of its issues, and probably has the fastest development cycle time, but it suffers around modelling complex asynchronous tasks, and (on a personal note) lack of support for writing in a functional style.

We don't use Python, Elixir or Ruby, mostly because of personal preference and for historic reasons.

Rust, though I personally love and use it in my projects, would require us to specifically hire for that, as the learning curve is quite steep. Its web ecosystem is OK by now (see https://www.arewewebyet.org/), but in my opinion, it is still no where near that of the other web languages. In other words, we are not willing to pay the price for playing this innovation card.

Haskell, as with Rust, I personally adore, but is simply too esoteric for us. There are problem domains where it shines, ours is not one of them.

A major part of our project includes visualizing the data through graphs and charts. We chose to use d3.js since it provides a wide selection of well-designed graphics and animations. As a library, it is also easy to use and be included in our UI. JavaScript which our team has experience with was also selected to integrate graphics from d3.js into the UI, as well as to integrate the UI with the backend system. Along with JavaScript, HTML5 and CSS 3 are also selected mostly for styling and formatting the webpage. These three languages are widely used which means that more support will be available, making the implementation process easier.

The key to our product relies on explainability and user experience when using our product. With this is mind, it is important to build a clean, readable web interface that a user will be able to navigate easily and quickly debug their security issues. The stack chosen for the interface of our product includes: JavaScript + React, CSS, HTML, Material UI and D3.js.

React provides us with simplicity to allow us to deliver the MVP as soon as possible. React also has multiple open source libraries to ease our development. Being able to reuse React components will help in developing the product fast as well as making the user interface modular. Since we're using React, we will also be using JavaScript, HTML, and CSS to create the frontend.

To design the UI, using a minimal approach would be the best solution. The Material UI library provides us with minimal and aesthetically pleasing React Components which would make our frontend look pleasing to the user.

Finally, our UI will consist of displaying information from our Machine Learning model in a dashboard type view. To display data in tasteful manner, we have chosen to use the D3.js library. This library is the most popular data visualization library for React with over 80k stars on Github. D3 also provides seamless compatibility with React and has a variety of features which would make the data we produce visually pleasing.

As our team will be building a web application, HTML5 and CSS3 are one of the standardized combinations to implement the structure and the styling of a webpage. Material-UI comes with all sorts of predesigned web components such as buttons and dropdowns that will save us tons of development time. Since it is a component library designed for React, it suits our needs. However, we do acknowledge that predesigned components may sometimes cause pains especially when it comes to custom styling. To make our life even easier, we also adopted Tailwind CSS. It is a CSS framework providing low-level utility classes that will act as building blocks when we create custom designs.

Am I the only one to think that libraries like Bootstrap, Vuetify, Materialize, Foundation are too much sometimes ?

Most of the time you are loading all the library and using 10% of it. And on that 10% you are modifying 90% of it.

I feel like using grid and pure CSS / JS are enough and cleaner.

In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.

To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.

Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.

For us it came down to C#, JavaScript, and Ruby. At the time we owned our infrastructure, racks in cages, that were all loaded with Windows. We were also at a point that we were using that infrastructure to it's fullest and could not afford additional servers running Linux. That's a long way of saying we decided against Ruby as it doesn't play nice on Windows.

That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.

We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.

As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.