useerup

Death is a moral responsibility. You owe your existence to evolution. Evolution would not work if we had to compete for resources with all of the organisms that came before us when they didn't die off. Death is an integral part of living a bringing our species forward. Your responsibility is to make the best of your time here. Have fun, love, and contribute to society and science if you can. Then die and make room for the next generations.

Microsoft has ported CLR (.NET Core) to Webassembly and it runs in the browser. You can indeed run CLR code in the browser. That is how Blazor works

So much was so right about PowerShell. But it failed to attract a wider audience, and in their quest to woo Linux devs Microsoft has been undermining PowerShell lately. Knowing what PowerShell offers, falling back to bash CLI tools feels like two steps back.

Just some of the stuff PowerShell did right:

- PowerShell cmdlets are self-describing and rich in information. Rather than each command doing its own parsing of parameters, cmdlets describe parameters and delegates the actual parsing to the shell. The shell understands data types, parsing rules, e.g. how to parse a UUID or a date. Not only does this ensure a consistency that was never in *sh shells, but it also enables cool stuff like e.g. autocomplete, predictive input, help instructions etc. almost for free.

- "Simulation" mode (-Confirm and -WhatIf) where a cmdlet can describe the action it is about to take, and the mode of the shell may decline everything (effectively a "simulation mode") or may actually ask the user for permission (-Conform) for each action.

But, alas, PowerShell never caught on outside Windows, and now MS is leaving it to wither in their quest to not upset a wider non-Windows community.

The first .NET Blazor "webassembly" was the .NET runtime ported to Webassembly, but where developer code would actually be the same type of IL (Microsoft's Intermediate Labguage) as .NET runs on Windows and Linux.

Unlike those platforms however, the IL was actually interpreted by the ported .NET runtime. Only the runtime was actually running as WASM.

To this day this is still the default, but now you can use a compiler to compile from IL to WASM, and then run full WASM code in the browser. This toolchain is a bit slower on build, but the code will run much faster.

> Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise

That is a pretty bold statement considering that Blazor actually does allow you to ditch JavaScript and very much integrates with the surrounding page.

It is true that for manipulating the DOM, Blazor internally needs to go through JavaScript as there are no direct WASM-to-DOM binding (yet).

But you, as a developer, can develop sites that runs its interactivity using webassembly instead of Javascript.

I believe because the C# version has been written using rectangular arrays. This requires every array access to use a multiplication. The Java version uses array-of-arrays and hoisting the inner array out before accessing it in the inner loop.

C# also has arrays-of-arrays, and could (should) be written in the same manner.

I use grocery store apps where I can scan the items with my phone as I put them in my bag. Checkout is then only swipe to pay. There are occasional random inspections, otherwise I completely skip the checkout lines.

Here in Denmark we also have a driver's license app. The app has a feature through which the user can identify themself to another party using the same app on their phone.

When used to identify, the app displays a series of QR codes which can be recorded by the 2nd phone through the camera. No need to hand over th e phone. It tranfers identifying information such as name, age and the photo so that the 2nd party can use it to validate on their screen.

Blazor - until .NET 8 - came in Blazor Server and Blazoe Webassembly variants.

Blazor Server renders the DOM at the server and sends it to the browser. The server also holds on to some state for each client - notably the "current DOM" - so that it can calculate diffs on changes and only send the diffs to the browser.

Blazor Webassembly does the rendering in Webassembly in the browser. The .NET stack runs in the browser. Here, the code renders and diffs in the browser and the the diffs are applied to the DOM as well.

This also means that the same components can run either server-side or client-side. They basically all end up computing DOM diffs and applying those diffs to the actual DOM. Pretty neat, actually.

Each model has it's pro and cons. Blazor Server initialized really quickly and relies on minimal Javascript in the browser. But it creates load and server affinity on the server. Blazor Webassembly offloads all rendering to the browser, but at the cost of an initial load of the code.

In .NET 8 these can now be blended, and a new "auto" mode allows a component to be initially server-side and then client-side when the webassembly code has downloaded.

In addition to that is now (.NET 8) also the static server side rendering (and "enhanced navigation") which you could say is server side components without the "circuit" server affinity and server state of each client. Static server side rendering has some limitations on how interactive they can be - i.e. changing the DOM.

A cube of water 1cm * 1cm * 1cm = 1cm^3 has a mass of 1 gram. A cube of water 1m * 1m * 1m is 1000 liters and has a mass of 1000 kg

The SI units are supposed to be related like that.

This comment make me question if you really have any experience with LINQ. If you had, you would not make a comment where you seem to think that LINQ is used only for data access.

LINQ is (at the most basic level) list comprehensions done better. It is functional programming for the imperative C# programmers. It has the potential to remove most/all loops and make the code more readable in the process.

> Unfortunately basic mistakes can result in so many of those N+1 type queries if you're not careful. It can also result in reading entire table(s), possibly inside those nested N+1s.

I don't know which "basic mistake" would do this. Maybe when using Lazy loading Proxies?

We use EF Core and it is quite easy to control eager loading or load-on-demand on a per-case basis.

I dont think EF ever did that. However, if you used automatic lazy loading and you somehow inadvertently referenced the collection, then yes, it would lazy load the related entities.

> Sooo it’s dapper with string interpolation override to make queries parameterized so you don’t need to manually put the parameters on as 2nd arguments?

Pretty much. C# does some really cool innovations around string interpolation which proves very useful for logging, SQL query etc.

You can create your own string interpolation handler, which is what the new SQL query does and what several log libraries do. So basically you can use interpolation safely and remain assured that you do not introduce SQL injection errors. Also, this way string interpolation does not prevent query plan caching, as normal string interpolation would do.

Blazor computes the DOM deltas in webassembly/.NET code in the browser and then sends those deltas to the translation layer which then performs the changes to the DOM. This process would get a considerable performance boost if webassembly were allowed to access the DOM directly.

Silverlight required a plug-in. That's a barrier to adoption that they never overcame. When plugins were outlawed it was impossible to continue Silverlight. Microsoft had seen the writing on the wall and had effectively abandoned Silverligt as a strategic product long before that. Blazor Webassembly is not in the same situation. Webassembly is not going to be pulled. Webassembly is objectively better than Javascript for the task of running code in the browser, so my prediction is that Javascript will be deprecated before Webassembly.