ASP.NET vs Meteor

When I started on this project as the sole developer, I was new to web development and I was looking at all of the web frameworks available for the job. I had some experience with Ruby on Rails and I had looked into .net for a bit, but when I found Laravel, it felt like the best framework for me to get the product to market. What made me choose Laravel was the easy to read documentation and active community. Rails had great documentation, but lacked some features built in that I wanted out of the box, while .net had a ton of video documentation tutorials, but nothing as straightforward as Laravels. So far, I am happy with the decision I made, and looking forward to the website release!

Comparing to ASP.NET Core MVC or ASP.NET Core Web API Simplify.Web allows you to easily build your web-site or REST API without any additional/complicated setup, covering cases like localization by default. It's projects structure very lightweight, just a minimum amount of what you need to setup ASP.NET Core request pipeline.

It is build on top of Simplify.DI IOC container abstraction, no dependency on Microsoft.Extensions.DependencyInjection and it's syntax. You can easily switch between DryIoc, SimpleInjector, CastleWindsor etc.

Any internal module of Simplify.Web can be easily replaced on extended by your custom module, covering your custom cases.

For HTML pages generation Simplify.Templates can be used allowing you to use just regular plain HTML without additional setup.

Can be easily integrated with Simplify.WindowsServices converting your web application not just to web-application, but a standalone windows service which can also do some background jobs via Simplify.WindowsServices.

And it is open source, of course :)

This basically came down to two things: performance on compute-heavy tasks and a need for good tooling. We used to have a Meteor based Node.js application which worked great for RAD and getting a working prototype in a short time, but we felt pains trying to scale it, especially when doing anything involving crunching data, which Node sucks at. We also had bad experience with tooling support for doing large scale refactorings in Javascript compared to the best-in-class tools available for Java (IntelliJ). Given the heavy domain and very involved logic we wanted good tooling support to be able to do great refactorings that are just not possible in Javascript. Java is an old warhorse, but it performs fantastically and we have not regretted going down this route, avoiding "enterprise" smells and going as lightweight as we can, using Jdbi instead of Persistence API, a homegrown Actor Model library for massive concurrency, etc ...