back to Jitbit Blog home About this blog

Jitbit is ported to .NET Core

by Alex Yumashev · Updated Sep 15 2021

I figured we owe this post to our customers (mostly) because of all the fluctuations we've been going through lately.

There's been no downtime, but every now and then some of the customers did experience hiccups with the SaaS-version of our Helpdesk. Some people reported UI bugs, some experienced the occasional "HTTP 503" errors in their browsers this past weekend, a small number of folks complained about the sluggishness and a couple of people even said their Office-365 email was delayed... Etc.

That's because...

We rewrote Jitbit Helpdesk last week

Well, this was not a complete rewrite, but... Yeah, Jitbit SaaS has been ported to ".NET Core".

As you might know, Jitbit Helpdesk is (was) based on ".NET Framework", particularly "ASP.NET". It is a robust, well documented and battle-tested web application framework. And I'm a huge fan of old, boring, unsexy and reliable tech (as opposed to "hot", "new" and "awesome") when it comes to production, client-facing code... But it's time to move on. Mainly from ".NET Framework" to ".NET Core" (aka ".NET 5" as Microsoft decided to drop the "Core" from the name confusing some people along the way).

Even though the new name sounds similar and uses the same C# programming language, about 50% of the code is mostly incompatible and needs to be thrown away. System libraries and classes have been renamed, moved and sometimes... deleted, so you have to hack your way around. Not to mention it uses a completely new runtime that has nothing to do with the "old" .NET Framework.

It's like rewriting an app from Windows to Mac. You use the same programming language, even some overlappng libraries, but the toolset, the code, the boilerplate - are very different. I'll post a more detailed technical article about the actual rewrite later, consider this a quick writeup to keep everyone updated.

Why move?

Some of the customers have asked a fair question - why even do that? Why take a reliably working app and tear it apart? Oh, believe me, we didn't do it out of fun. It's been 2.5 weeks of nonstop hard work, staying up late, writing thousands lines of code and testing, testing, testing... And before that - months and months of preparations to make the code more "portable".

I even wrote an angry post about not moving to .NET Core right in the middle of the rewrite... So why do that?

1. Performance

.NET Core is fast. Ridiculously fast. Even faster than C++ on some benchmarks. In fact, .NET is currently the fastest backend technology available.

.NET is 20x faster than Ruby, 10x faster than Python, 7x faster than PHP, 5x faster than Node.js, 2x faster than Kotlin/Java, 10% faster than C++ and 5% faster than Go. Rust is the only thing that beats it (for now).

.NET is truly async (means the app keeps processing other requests while i/o operations are pending), and uses less memory.

But enough with the technical details. What this means in plain English, is that our customers get a helluva snappy app. The TTFB (time to first byte) is 3-4 milliseconds. Three to four! Try to beat that, Ruby!

2. Linux-compatible

Finally. This is not something our SaaS clients would care about, but it still counts: linux is faster than Windows and it takes the app less time to "warm up".

Also this is a huge, huge benefit for our self-hosted customers, who are getting the linux compatible update within 2 months.

3. Most importantly: .NET Framework is dead

It still comes bundled with Windows and all, it is still supported, but make no mistake, MS's attention is with "Core" now. All the latest fixes, updates and performance improvements are going that way now. The more we postponed our rewrite, the more incompatible our codebase would become.

What's next

The SaaS-version is now .NET 5. We still keep a close eye on the app, the logs and the metrics, but most of the bugs and hiccups have been fixed. Next week we'll get back to working on your feature requests and the backlog.

In 1-2 months we hope to release the self-hosted, linux compatible version. Probably even sooner but I'm being cautious.

Stay tuned!