|
Alright then, I am surprised...
To be honest I did search the web much for various sample, just did read the whole documentation and build provided sample locally...
I did notice at that stage it was downloading the .NET Assembly as is (the DLL) and maybe it takes time to parse the IL to WebAssembly on slow computer, but I have a fast one,so it went instant for me...
|
|
|
|
|
It depends on what you are doing and who your audience is.
I looked at Blazor and thought it looked great for 'external' users on mobile phones etc. But my users are all internal using PCs so Razor Pages was better - not as leading edge (so easier to learn) and faster response.
|
|
|
|
|
Thank you for your input. I was unaware that it could run on phones, but I'm glad to find that out.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It is definitely designed to work on non-Windows platforms as its slowness is caused by having to write the .Net framework as WASM code to the device first; the documentation said (As far as I can recall) that it is slow for Windows as it still downloads the .Net stuff. Perhaps I interpreted non-Windows as including phones as many of them are Linux based or perhaps it actually said it. Don't trust my recollections - I could be wrong. The key message that I took was that it was inefficient for Windows and anything other than that could have gone though my 'not relevant to me' filter and not be accurate.
I've just tried a quick look on a well known search engine for 'blazor mobile development' - this produced a lot of hits (some explicitly citing iOS and Android), a very brief scan of which suggests that my memory was not playing tricks; but they don't look as though it is simple.
------------------------
<edit>
I've been looking at What's behind the hype about Blazor? - Stack Overflow Blog[^] - that says there are / will be multiple delivery mechanisms. One (web assembly) does send Mono to a device as a mini .Net download and then runs natively so it is slower to get started; but another has the browser communicating to a .Net server using SignalR which obviously has latency which could impair the user experience, but the author of the article suggests this is not normally significant. So it is definitely worth looking at and making a decision based on your actual requirements.
Oh! I've just remembered one of the pragmatic reasons why I had rejected Blazor - it needs versions of .Net Core (?) that are not supported in our environment.
modified 27-Jul-20 7:23am.
|
|
|
|
|
IMO, It would be good to have C# instead of JavaScript if it's extensible, fast and have a growing support development community. JavaScript over last few years has leaped quite ahead and it would take some time to catchup in case its promising.
With .NET5.0 around the corner (later this year), it would be good to see how entire .NET tech gets placed.
|
|
|
|
|
You have to have the green blazor version to Master Blazor.
I'd rather be phishing!
|
|
|
|
|
In general; if you need to ask then no. Spend your time on where you needn't ask.
So what's a blazor, and why should I care?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It looks useful if you have some C# code that you want to run in a web page without porting it. Except that might not work, because "APIs that aren't applicable inside of a web browser" don't work .. but it looks promising? For code that doesn't do anything crazy anyway.
I just hope it isn't like Google Web Toolkit, which pretended to be like Java but blatantly violated Java semantics, making it a portability nightmare. (if you've ever seen ~~ in "Java", this is why that silly construct exists)
|
|
|
|
|
Client side, Blazor just isn't fast enough yet. WASM will get there, but I don't think it's there yet.
|
|
|
|
|
Over the years Microsoft has tried quite a few things on the web that quite simply have had varying degrees of success:
- ActiveX (dead)
- VB6 Web-Classes (dead)
- ASP.NET WebForms (more dead than alive)
- Silverlight (dead)
- ASP.NET MVC / Razor (still-around but long in the tooth)
- Blazor (we'll see)
Everything before ASP.NET MVC, IMHO, was not in line with the way the web worked. It almost seemed as though Microsoft tried to create a Win-Forms based thinking for the web. Web-Forms attempted to place an object model around HTML which was admirable but probably quite unnecessary. With MVC one could even replace the view engine but that never *really* took off.
The web is a funny environment but I quite like it. I prefer writing web-based applications. The ecosystem is huge and as soon as you move away from it you are creating a parallel universe. When you play on the same field then you are going to find a lot of support.
This is why I don't even use Visual Studio for web-based work. I used to use WebStorm but VSCode is just great for folder-based development.
Should Blazor integrate seamlessly with any coming WebAssembly bits then it stands a chance. I don't think I'm really sold on WebAssembly yet as plain JavaScript gets the job done. I don't even bother with TypeScript although should I have to use it then fine. I'll probably like it 
For now I'll take a wait-and-see approach.
|
|
|
|
|
I dunno. I'm very very good with javascript (JQuery especially. Love that AJAX) and see no need to go to Blazor. Up to now, the main use of Web Assembly has been malware, though I guess Blazor is catching on. I've "read" articles describing weird potential vulnerabilities of it though, that if true, sound like technology killers. I've looked at it a couple of times but it clearly wasn't ready for prime time yet. I'll wait and see but why use C# (my language of choice) when javascript is a web native language?
|
|
|
|
|
I've read an article about a few WebAsm's potential vulnerabilities. (Wish I could remember where, sorry.) I recall being suspicious. WebAsm run inside the same sandbox as JavaScript itself. They are peer technologies. So any vulnerability in WebAsm should also be in JavaScript. The article I read didn't reference that fact at all. The article also seem to forget that WebAsm was meant to run inside a browser. To me the article felt like a hit piece.
True that WebAsm's biggest use to date has been malware. Sad to see any new tech abused like that. I've also recently read about JavaScript cyrpt miners being included in website ads. It's frustrating cuz crypto miners on website could be a whole new way to fund websites instead of using ad networks. But the idea is getting a bad reputation. 
- great coders make code look easy
- When humans are doing things computers could be doing instead, the computers get together late at night and laugh at us. - ¿Neal Ford?
- Nano naked and you'll Win nude! :P
|
|
|
|
|
Let me tell you a story about a similar product: Visual WebGui. It used C# and converted everything to javascript. You could use almost all of the .NET api.
Advantages
- If you came from Windows Forms it felt natural and very easy to use. Also you could use almost all of your old code.
- It did not have a long load time, it was quick.
- The final users found the software very usable as it did resemble the Office applications.
Disadvantages
- The runtime had to be kept up to date with new browsers versions.
- The .NET implementation was propietary and only 99% identical.
- There was no formal way to interact with other javascript libraries. But I did not need them at that time.
Bad news
- The company lost money because a product of this kind was not very popular. At first they charged for licenses but the low usage made them give it out for free and only charge for support.
Then they changed their strategy and Visual WebGui was no longer supported. The community got together and asked the company to release the source code or to sell it. They did not want to do this.
So, a good product and a great idea came to an end. Today you can find paid support from one of the original developers, but no new versions are being made.
--
Is all this relevant to Blazor? Knowing Microsoft and their habit of abandoning their own technology I would say: yes.
|
|
|
|
|
Blazor takes 'full stack developer' to the next level.
WebAssembly.. we'd expect to have a slower startup. No brainer. Following that it's fast. Server side using SignalR is fast without the startup liability.
There's starting to be a demand. So it's worth getting your toes into if you wouldn't mind doing a different level of C# coding. And expanding your utility.
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
Although I've been mainly interested in Blazor server so far, I'm really excited about this tech because I never liked the JS experience. I have no idea if it will catch on, but I really hope so -- whether in server or WASM form.
|
|
|
|
|
Disclaimer: I've disliked JavaScript since learning it in the late 90s, early 00s. That might be an unpopular opinion, but certainly not an uncommon one.
That said, I use server-side Blazor now and love it. It doesn't have quite the scalability of other web tech, but the server-side functionality is (close to) unique and fascinating. I'm flipping a site to client-side Blazor now... so more on that later.
Is it worth learning... IMHO, this tech is different enough I feel most would benefit from its perspective. WebAsm (in general) has many years behind it, and made it as a browser standard before Blazor existed. (That alone is a feat.) So it's here to stay.
Will non-JavaScript haters gravitate to it? Good question; time will tell. WebAsm should have slightly faster load & execution times. But I feel not enough for that to be a practical factor in most cases. Dependency control will be a much greater factor in performance.
In the end it's just a tool. One I personally hope will dislodge JavaScript, but that's just one code-monkey's opinion.
- great coders make code look easy
- When humans are doing things computers could be doing instead, the computers get together late at night and laugh at us. - ¿Neal Ford?
- Nano naked and you'll Win nude! :P
|
|
|
|
|
I am actually implementing a production application in Blazor with an ASP.NET core backend. All of our previous web development was done in Angular with some large typescript libraries we developed.
The iteration time to make a change in your source code, rebuild it, and then restart your test from scratch in the browser is very painful. They claim to be working on this, but as far as I know, it is not done yet and I question how much they will be able to accomplish. The workflow with angular using typescript and a development server is much faster and quicker to iterate on. To circumvent some of this, we have created a complete POC html only application first to get the layout of what is required and then just mapping that HTML into the Blazor application so that we are never iterating on the SASS or HTML of the application within Blazor. I think they will have to move the compiler to the browser to accomplish this and then handle incremental compilation.
Another issue, that I have to admit I don't fully understand what they can do about it yet, is the download. As I understand it, you are downloading a version of the .NET runtime meant to run inside of WASM and then downloading all of the assemblies that your application uses. MS claims to be working on a way to remove the unneeded parts of the application kind of like the linker does in a native build. I have been developing in .NET for some time, and because so many of its patterns are based on reflection, it can make getting this removal of only the parts you are actually not using after reflection is taken into account very tricky. I suppose they could dictate an attribute of what not to remove. I am not 100% up to speed on their efforts to remove the unused parts of the application. So perhaps they have some interesting tricks up their sleeves.
One of the reasons I almost always desire compiled languages over interpreted ones is that the compiler eliminates many bugs and wasted test cycles. I have noticed that many times my razor files will compile, but fail at runtime due to an issue I feel the compiler should have caught. I believe Angular and Typescript did not have this issues especially if you did a complete build. This makes me a little less happy about Blazor.
On the positive side, the C# experience, dependency injection, and type safety that C# developers have become accustomed to are all in tact (if you ignore the .razor files). And once the application is downloaded, it is lightning fast in its execution. The robustness, clarity, and typechecking of the C# language (if you ignore extension methods) can't be ignored. FYI, I hate extension methods for discoverability and static analysis of code.
The few times I have had to call Javascript code from the C# code, the experience was very straight forward and pleasant. Kudos to MS on this one.
While MS has seemingly embraced opensource, you will find that things like their C# debugger are only allowed to be used with VS and VSCode. If you have leveled up to using a faster development environment, then you may suffer by being forced back into the MS fold.
I should know far more in a month as this project comes to a close. But my current take aways are:
1) If you have a set of C# business logic you would like to leverage between multiple deployment targets, the web being one of them, and you can get it in a small assembly, Blazor can be a valuable tool to avoid the cost of reimplementation in a typed language like Typescript. But you will pay for that cost in other areas.
2) Using Blazor increases the number of technologies and moving parts a front end developer needs to maintain expertise in and that will likely drive down productivity.
3) I am not betting on iterating in CSS and HTML within a Blazor application every hitting the efficiency of SPA development with Angular or other frameworks that live in Javascript. But perhaps MS will surprise me.
4) While we will complete this application in Blazor, we may replace the entire thing with an Angular application later to avoid this outliar and minimize the cost of technology headspace.
5) It is important not to conflate Blazor WASM with Blazor Server. The Blazor branding refers more to the patterns and code within the application and very little with how they are deployed or where they make sense to deploy.
If I could have my cake and eat it too, the common code used between multiple applications would be in a language like C++ or Rust so a proper linker could eliminate what was not required. But even if you stuck with .NET or a language with a GC, I would change the pattern to have the view models maintained in the WASM portion and allow the developer to develop the views with more traditional tools such as HTML, SASS, CSS, TS, ... that simply used the view model as a data source to bind to and send user events to. I believe this separation of concerns would make the most sense and allow the fastest iteration.
|
|
|
|
|
I have been programming with Blazor for over 2 years now, starting with the previews. It's incredibly easy to program and if you use a code-behind file for each component to separate the code from the markup, everything is tidy and pretty, unlike React or Knockout. I switched the project to Blazor WebAssembly in May. It's fast.
Judging by the number of job postings requiring Blazor, it doesn't look like anyone is using it much already, but I'm hoping this changes in the next few months. One good thing to note about Blazor is that it doesn't require node.js, etc., so the solution footprint is much, much smaller. And you don't need to wait endlessly when you have to rebuild the entire solution.
I'm sold.
|
|
|
|
|
The consensus of this population of 1 is that Blazor is the best current way to develop websites.
May JavaScript die a quick death, or at least quickly get consigned to irrelevance.
|
|
|
|
|
WASM allows for non HTML UI... Blazor is not the answer WASM was meant to solve.
JS isn't the only problem with web dev. HTML is as well.
How MS continues to miss the mark for innovation is beyond me.
|
|
|
|
|
|
My coolest article this last week was probably my "Await on anything" article that allows you to extend things other than Task to accept the await keyword.
Yet people liked my Windows Message Queue for C# developers article even though it doesn't present any sort of technique you'd want to use in production (don't use these from C# please - it's just silly) - i even put a prominent disclaimer about that in the article, but at this rate it may be in the running for best article for this month. It certainly has a lot of votes and downloads. About what my MIDI library had.
I wish I knew what people liked so much about it so I could replicate whatever it is.
Real programmers use butterflies
|
|
|
|
|
Synchronicity. The right article at the right time.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
what i don't understand is how it's the right article for anyone. it's purely illustrative, and not even of a concept used in .NET except to make winforms work. oh well.
Real programmers use butterflies
|
|
|
|
|
"Message Queue" (or messaging) references come up more frequently than threading when it comes to corporate development.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
