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 :)

As a personal research project I wanted to add post-quantum crypto KEM (key encapsulation) algorithms and new symmetric crypto session algorithms to openssh. I found the openssh code and its channel/context management extremely complex.

Concurrently, I was learning Go. It occurred to me that Go's excellent standard library, including crypto libraries, plus its much safer memory model and string/buffer handling would be better suited to a secure remote shell solution. So I started from scratch, writing a clean-room Go-based solution, without regard for ssh compatibility. Interactive and token-based login, secure copy and tunnels.

Of course, it needs a proper security audit for side channel attacks, protocol vulnerabilities and so on -- but I was impressed by how much simpler a client-server application with crypto and complex terminal handling was in Go.

$ sloc openssh-portable 
  Languages  Files    Code  Comment  Blank   Total  CodeLns
      Total    502  112982    14327  15705  143014   100.0%
          C    389  105938    13349  14416  133703    93.5%
      Shell     92    6118      937   1129    8184     5.7%
       Make     16     468       37    131     636     0.4%
        AWK      1     363        0      7     370     0.3%
        C++      3      79        4     18     101     0.1%
       Conf      1      16        0      4      20     0.0%
$ sloc xs
  Languages  Files  Code  Comment  Blank  Total  CodeLns
      Total     34  3658     1231    655   5544   100.0%
         Go     19  3230     1199    507   4936    89.0%
   Markdown      2   181        0     76    257     4.6%
       Make      7   148        4     50    202     3.6%
       YAML      1    39        0      5     44     0.8%
       Text      1    30        0      7     37     0.7%
     Modula      1    16        0      2     18     0.3%
      Shell      3    14       28      8     50     0.9%

https://gogs.blitter.com/RLabs/xs