OpenSilver looks like a fun effort. I wonder, though, if it's commercially viable (just out of curiosity.)
Wikipedia [1] says:
> In July of 2015 a Microsoft blog post finally clarified matters: "...we encourage companies that are using Silverlight for media to begin the transition to DASH/MSE/CENC/EME based designs". Microsoft plans to terminate Silverlight support on October 12, 2021.
How widespread is adoption of Silverlight? Could OpenSilver become someone's bread & butter by 12 Oct 2021?
Office and WinDev teams are the main reason why Longhorn failed, their collaboration with DevDiv wasn't particularly stellar.
They were pretty happy to redo Longhorn ideas using COM instead, then rejuvenating it into what is now UWP, naturally creating an incompatible .NET stack in the process, which might finally be done with when .NET 5 gets released.
Also Office team is so deep into C++ they even maintain their own VC++ branch.
You won't see those guys touching anything .NET beyond the absolutely necessary.
Otherwise I agree. Blazor will never be what they imagine it will be. And why should the office team migrate to another tech stack. That is wasted money.
When I see how absurdly complicated these front-end JS frameworks are it makes me really hope that Blazor can deliver. But for some reason it also feels similar to times in the past where a word for promising tech was never more than a word. But please work, I don’t need or want two routing implementations and an entire MVC stack to manage on the damn client...
I've now done two small client projects in blazor(server side) and it's amazing for small to medium sized cruddy apps with a small user base. I
On the fist project I was able to build out small apps almost twice as fast as react. And this was with 1 day of previous blazor experience before the first project.
Yeah blazor seems to be a re implementation of the same ideas with webassembly and a newer version of .net. I have a feeling it will have the same security holes eventually.
Since it runs in the Browser JS sandbox there will be a lower security footprint than the NPAPI Silverlight plugin. JS libraries can certainly still cause other web security issues but you shouldn’t be able to escape the browser just because you’re running this library.
What is your complaint about silver light? From a user perspective, the only issue I had with it was that you had to install yet another software plugin. But if it’s invisible to end users, I don’t see an issue. Though maybe you developed in it?
I honestly don't know if that's a silverlight issue or implementation problem, but having to work with admin consoles implemented in silverlight in Microsoft product I can say they offer awful experience.
Loading time is terrible, movement between fields is clunky and if you use tab to pass fields your input will be deleted.
Left clicks are not a thing.
Moving back and forth lose state.
Responsive design is not a thing.
I'm waiting so long for it to reach end of life already.
Most of those things happen regardless of UI tech, in HTML as well. That's less an argument against a particular framework, but rather an argument to not build shoddy UIs.
It is way worse than your average HTML. Again, I'm not sure if those defects are the framework faults or the UI implementation, but deleting input from field when pressing tab isn't something I encountered in any HTML interface. Loading time is also similar to a desktop 1st person shooter, not to HTML.
Trust was my biggest objection to it... There was no reasonable/complete Linux implementation available, and at that point Microsoft had never supported a technology (other than office) outside of Windows for more than 2 releases that I could recall.
In general, I really liked the package model, it's close to what I'd hoped Flash would become after Adobe acquisition. I do like React a bit better than Silverlight, but the tech and usability wasn't really bad, just more of a risk aversion for myself.
If MS had created an open-source client implementation that was patent unencumbered that other browsers could have integrated, with open tooling, I think it would have gone better. Can't speak to this implementation. For the Blazor efforts, payload size just feels excessively huge to me, and server-side renders feel as laggy as the original ASP.Net lifecycle round trip.
I'd probably be more inclined to work towards tooling for other languages that have a lighter wasm target (Rust in particular) and either web canvas or something like yew. All of that said, I'm pretty happy with React these days.
At least you can sandbox and run webassembly everywhere with an open interpreter/JIT.
With plugins you have to trust and install some binary code on your system, no sandboxing, no idea what it does and what it can access, etc. Much worse.
It looks like it's a plugin for Visual Studio and from what I can tell Visual Studio requires a Microsoft account. There's a link to their Github repository and it has the project files for compiling OpenSilver in VS. I think the Microsoft account in required for installing plugins hosted by MS.
yup. I did a lot of WPF/Silverlight work 2008-2012 and I STILL get emails from recruiters (one this week even) asking if I want a job doing that kind of work.
ah i was hoping it was for osx too :) been reading my ISPs apology for not support safari now for 2 years i think... they only do silverlight streaming
Wikipedia [1] says:
> In July of 2015 a Microsoft blog post finally clarified matters: "...we encourage companies that are using Silverlight for media to begin the transition to DASH/MSE/CENC/EME based designs". Microsoft plans to terminate Silverlight support on October 12, 2021.
How widespread is adoption of Silverlight? Could OpenSilver become someone's bread & butter by 12 Oct 2021?
1 - https://en.wikipedia.org/wiki/Microsoft_Silverlight