sebastianbk

He's been with Intel since 1979 (only interrupted by a stint as CEO of EMC/VMware).

I may have made a mistake in designing the architecture of our app. Since we're a small team, I opted for a big ol' monolith, hosting our APIs on the same server as our Blazor Server app. We normally serve a few hundreds requests per second on our APIs, which is totally fine. However, sometimes we got some spikes up to thousands of requests per second, which has the unfortunate consequence that our Blazor Server app becomes laggy and starts to drop WebSocket connections frequently. So, now, we are in the process of moving our API controllers to another project, which will be hosted on a separate server.

It can be hosted by either WebAssembly or by the server (in which case the server will render the DOM and send diffs to the client over a WebSocket connection). Blazor Server probably isn't the best choice for a popular SaaS app, mainly because of its dependency on WebSocket connections and less-than-perfect reconnection logic.

I'm optimistic about the auto-rendering mode, which will serve the app via Blazor Server (using a WebSocket connection) the first time the user hits the app. It will download the WebAssembly DLLs in the background so that the next time the user comes by, they will get the WebAssembly-hosted version. It's an interesting mix combining the best of both worlds (hopefully).

In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. So, when I started my own company last year, I quickly jumped on Blazor Server, which has been an absolute joy from a developer productivity perspective.

You can build really rich interactive experiences in Blazor at a fraction of the time required to build the same thing with the standard JavaScript SPA architecture. However, now that we have many customers using the application in production, we're starting to see some of the not-so-pleasant side of Blazor Server. When experiencing a lot of requests, the experience is degraded for all users of the app. In addition, it's not very good at re-establishing the WebSocket connection if it fails, giving a poor impression to the user. Though, I'm impressed with the latency—we're hosted in Europe and have customers in New Zealand who use the app without any latency issues whatsoever.

I'm excited about the auto-rendering mode, which looks pretty straightforward. I don't really buy the author's argument that it introduces an extra layer of complexity—we're still light years away from the complexity that a modern JavaScript SPA involves. For small teams with just a couple of full-stack developers, Blazor is still one of the best and most productive stacks, in my opinion.

As a Microsoft employee I am so happy that we got rid of stack ranking a few years ago. It encourages a bad behavior and goes against helping your coworkers with whom you are essentially competing for compensation. I am surprised to see that a company like Valve, which seems to be held in high regard by many developers in the industry, still operates with this compensation system. It's system of the 80's if you ask me.

Same here. I have read several of the IMF Blanchard's school in grad school and naturally thought it would be the same guy. I got a little confused too.