Let's start with the weaknesses mentioned by the subject.
WASM packaging starts slowly
Is defect. Initial startup requires downloading and initializing the necessary parts of the runtime, class libraries, and so on. Officials are still refining the cropping feature to reduce the volume of content loaded on first launch, but that's about it for now.
WASM+AOT packs large volume
Larger pack size after AOT is expected, not a drawback. Used conditionally, AOT is not a panacea.
Server mode occupies Socket and Server memory
That's not a weakness... This is a project design pattern supported at the framework level, where the interaction between the front and back ends is handled through long connections and the logic is mostly done on the back end. If you use such a design, the back end of course takes up sockets and memory. This is a statement, not an evaluation.
(P.S. I prefer to learn the Client mode, which is closer to the general front-end development)
Let me take a personal view.
Blazor has two major disadvantages:
Wasm's popularity and support is not widespread enough
Ecological problems
The ceiling Blazor develops is definitely constrained by WASM. For the 2C market, where browsers such as IE 9-11 do not support WASM or only partially support it, adopting Blazor means abandoning a large number of lower-level users. The 2B market is up for grab, but there are many enterprise and corporate hardware environments that don't support WASM, and that's where Blazor can't get its cake. In summary, in the short term, there is a relatively limited buyer's market for enterprises or individuals to choose Blazor as their product.
The ecological issues are divided into two parts: one is that Blazor itself has not been around long, and the various open source components, applications, designs, and best practices still need to be enriched and matured; Another is that the domestic C# ecology is relatively weak. The combination of these two can easily lead to a vicious circle of "many people who offer, few people who contribute", and finally both sides give up. If the community doesn't come alive, Microsoft machete might...
For now, Blazor has a late-mover advantage, and many of the design ideas are in line with mainstream front-end development, with fewer twists and turns.
Looking ahead, browsers that don't support WASM will become obsolete, so the first (inherent) drawback isn't the most serious. Perhaps the most serious "drawback" is the open source community. For example, the domestic open source project Ant-Design-Blazor provides a set of enterprise-oriented components. As far as I know, the project managers have spent a lot of time and energy in their spare time, but there are many known problems that need to be solved by manpower. I have personally experienced a significant improvement in development efficiency while using ANTD-Blazor, and have also contributed PR for some of the issues I have encountered. This is a two-way process, so I hope to get more of my peers involved in the open source community.
If developers who have used open source products always look to "off-the-shelf" and do not actively participate in its efforts to "mature", then Blazor's future is indeed bleak.
BTW, as for my friends who regard it as a "weakness" that they can't replace the js/ TS-based three frameworks... I think too much...
The performance of WebAssembly is better than that of Js, and although Js is now JIT enabled with V8 engines, the loss caused by repeated unboxing and predictive errors in dynamic languages is not to be underestimated. So for example function add(a,b)
{
return a+b;
}
Like this code, the compiler looks at it, it's an addition, and it compiles it, but in the actual process, it passes in a string and the compiler blinks and recompiles it, and if someone's code repeatedly jumps around this function, it's going to be very bad performance. To solve this problem, experts have come up with another method, which is ASM. let x = a | 0; // let y = +a; / / y floating-point number this thing just provide the two types, | 0 integers +? Floating-point, which improves compilation accuracy on supported machines and reduces the number of cases described above, does not change the result if it is not supported, further improving performance. But there was still room to explore, and WebAssembly emerged. Originally designed to develop web pages in C/C++, Microsoft built Blazor on this basis. I was there at the time, and Blazor still has some drawbacks. Server versions consume Server performance. WebAssembly is not lean enough, requires downloading a lot of native libraries, takes up time and lacks a developer base. (The more it lacks, if we.net developers don't work hard, it's a vicious cycle. Blazor WebAssembly also needs to do dynamic loading of components to speed up the loading even further. Make a beautiful, single-page application.
By the way, I am a game developer, running game-related calculations every frame on the web side, as well as physical collisions, and a little bit of performance is very sensitive to the game. I have actually tested WebAssembly and the performance improvement is huge, and unity-generated H5 games already use WebAssembly. Quite a few other WebGL projects use WebAssembly.
1. Because blazor uses Microsoft C# to develop front-end rendered web pages! 2. C# is an object-oriented software released by Microsoft that runs on. The.net Framework and. A high-level programming language on top of NETCore(fully open source, cross-platform). In other words, write front-end pages in back-end languages. Why would you do that? C# in the Internet industry used to write the back end is basically a corner, now also used to write the front end, will there be market recognition? This, among other things, is a weakness in itself. If blazor is currently written in JAVA as the popular choice, look at the response. 3. Why Blazor? The reason for this is that browsers support WebAssembly, a new way of coding that can run binary format files in modern Web browsers with near-native performance. Blazor attempts to use WebAssembly and DotNetAnywhere. NET brings back to the browser. However, although the version is now iterative, it is only suitable for developing management systems because the response is still a bit slow. 4. Back to C#, if blazor is to be used, the front end needs to learn C#. It is not necessary to give up the current vue/ React framework to accumulate, although you can call JS, but always feel useless. In conclusion, I think it is suitable for those who know C# to write management projects. The rest is in the eye of the beholder!
Blazor is currently good in my opinion except for the following three drawbacks: 1. It is not suitable for JS developers, that is, the mainstream front-end developers 2. The initial load is slow and the subsequent load is a bit slow (correction, the subsequent load is actually quite fast, the first load currently takes about 2 to 5 seconds) 3. 4. While it is useful enough to use, Blazor has been cut down by Microsoft. Despite these shortcomings, Blazor has taken off. It looks like another WebForm product, but to be honest, WebForm really doesn't deserve to be compared to Blazor, WebForm is not a thing of its time. However, due to the second and third drawbacks, Blazor is currently not comparable to React and others. Our company was transferred from WebForm to React. We also planned to transfer to Blazor half a year ago, because we were busy all the time and put it on hold. I myself have tried to build some basic functionality based on the requirements of our existing projects, the process of writing code is very comfortable, and there is a lot of logic to share with the back end (our back end is C#). For those of us already familiar with C#, Blazor is much better than the React stream. While I would love to see our project ported to Blazor as soon as possible, I am not in a hurry to move forward with Blazor due to its current critical shortcomings.