OpenSilver doesn't need to solve a problem other than the itch of their developers.
If other developers feel the same itch, or maybe if there are still projects out there that need to be ported, then OpenSilver will live, otherwise no. I'm pretty sure that there are Silverlight apps or games out there that were never ported to JavaScript. It might not have reached Flash's level of popularity, but I remember some.
Regardless, OpenSilver is an interesting piece of technology. And whether it lives or not, such opinion pieces are worthless.
“it’s almost impossible for a framework to get traction with Microsoft developers if it isn’t explicitly supported by Microsoft.”
That sentence struck a chord with me. I work in an MS shop and it always saddens me that a lot of my colleagues will always go with MS stuff. For a long time it was TFS over git, now a lot of them want Azure vs. AWS mainly because it’s MS. This attitude makes very skeptical about the recent open source efforts in the .NET world. I have a lot of doubts that any open source project that’s not from MS can be successful in this world.
My last experience at an MS shop identified what I believe to be the (intentional) reason.
Microsoft has certifications for everything. The more people with Microsoft certifications you have the more they will give you discounts on their tech stack.
This self-feeding beast creates businesses that become incentivized to hire people with MS certs to get more discounts on MS tech. Developers are encouraged to gain these certs and maintain experience in that MS ecosystem as well, which invests them in all things Microsoft.
When you factor in the vendor approval process where everything under a single umbrella has been approved (usually, MS, AWS, Google) then as a developer, you know you'll have access to those tools when you go to another similar job.
In much the same way that people are happy to invest in learning open source tools rather than internal company libraries, because the experience is portable outside of that single job.
Nobody at my company has any certifications so that can’t be the reason.
I think MS just has created a very comfortable and convenient world where it’s really easy to use Visual Studio and MS tools. Once you leave that world you have to deal with more setup work upfront. It’s really not a big deal once you are used to it but it’s a muscle that needs to be exercised and tends to atrophy when you use Visual Studio.
And there is always the fact that nobody ever got fired for using MS. I remember when my team started using git, every time there was a problem we were asked why we weren’t using TFS where things “just” work. You need a certain amount of stubbornness to use tools against the mainstream opinion.
Your examples point out how hit-and-miss Microsoft is.
When it comes to TFS vs Git, even Microsoft will choose Git. (e.g. it is the only version control designed from the start to handle a major operating system kernel)
When it comes to Azure vs AWS I see them as evenly matched. If you make a decision based on your gut it won't hurt you. (If you picked IBM cloud because you liked IBM, however...)
Some Microsoft products are pretty good but often Microsoft drops the ball. For instance, the foundation of ASP.NET is absolutely great. However, they introduced some controls that looked a lot like "Web Components" that ran (mostly) on the server side. These dealt with all the usual annoyances about HTML forms, and could have been a real productivity booster.
The fatal trouble these had was that they used a state management mechanism that wasn't compatible with the "MVC" web framework approach which is mostly a matter that forms don't live in isolation. After processing the form, the server can decide to render any of a number of possible output pages: for instance you might render the same form if the form failed validation, but deliver one of several forms depending on what the user filled out (think tax paperwork)
Microsoft might have been able to make the existing system work in an MVC framework, or made something similar from the ground up to work with MVC, or other moderate decisions.
Instead they came up with ASP.NET MVC which wasn't trying to be a market leading product, but instead is a cut-rate version of Ruby-on-Rails that cut you off from much of what was cool about ASP.NET.
Microsoft had the chance to make a system that was really worth paying for, but they blew it.
> When it comes to TFS vs Git, even Microsoft will choose Git. (e.g. it is the only version control designed from the start to handle a major operating system kernel)
Microsoft used an internal fork of perforce for most of Windows' history. Substantial changes were needed for git to handle the windows codebase. I don't know of any major project that used TFS internally, Source Depot was the primary source management.
Linux is quite small compared to many internal Microsoft code bases.
From what I understand MS never had a problem using tools that weren’t the ones they give to their developers. They used perforce while selling SourceSafe for example. I don’t think they used Winforms or WPF much either except in maybe a few projects. I always wondered what would have happened if they had made the UI libraries Office uses available to third party devs or beefed up MFC so Office could be written with it.
TFS was never really that good and I won't defend it, but Winforms and WPF are more RAD tools not really appropriate to projects like Office. They are excellent for the tasks they were designed for.
Re the Office libraries you probably wouldn't want to use them anyways. They were designed for maximum flexibility and performance not with ease of use or fast development velocity.
I think it’s a big problem if a vendor of dev toolkits doesn’t use them themselves. WPF is a great example. The underlying concept is very interesting but it seems they stopped developing it before it had the chance to be really good.
I don't think its fair to say it wasn't used. Just that it wasn't used on the big projects like Office. There were certainly a ton of internal tooling from that era that did indeed use it, which was also the primary use case in the wild: Internal line of business applications. With RAD you are making tradeoffs that aren't appropriate for massive code bases. Microsoft always took dogfooding very seriously.
It's a bit like complaining Ford doesn't use its pickup trucks to transport vehicles to the dealer. They just aren't designed for that purpose.
To some degree I understand what you are saying but it’s still a wrong strategy. It means there are easy to use tools for small apps and large apps have to deal with Win32 directly with nothing in between. No wonder the desktop is dying.
The propaganda MS has been putting out also contradicts this. I remember well how they were first telling us that WPF, then Silverlight, then WinRT is the future of windows. Got burned a few times and then refused to look at UWP which is now the future of Windows until it probably isn’t.
.NET has a very good inter-op story for win32. If you started with MFC, WPF, or another framework and then needed to add win32 flourishes you can do so quite easily.
It's quite a different thing to try and retrofit a traditional win32 message pump application with one of these frameworks. Especially if it's in an entirely different language and runtime. Had Office been born in the early 2000s its quite likely they would have tried to use .NET and had the same issues as Longhorn. I think Microsoft did have broad ambitions for the framework, but reality was the tech couldn't handle large scale software at that time and Longhorn failed as a result.
I think your right it is a little unfortunate win32 is needed if you want to make a million LOC desktop application. I don't think there really was anything better for native code up until recently with modern C++. The ugliness of COM and MFC are really due to limitations of C and C++ at the time. Now I don't think there is enough demand to really justify something radical.
.NET Always did reasonably well for web backends, and I think they have the right strategy to keep pushing there.
I'm probably one of the devs you've described. I've always worked at Microsoft shops and I love it.
A couple of advantages to the homogeneity.
I can jump on any project and be productive on day one because not only am I familiar with but I am an expert on 95% of the stack.
I can very easily hire people who can be productive from day one because they've used 95% of the stack.
I can have much a broader skillset than is possible in other ecosystems. In other ecosystems, I might be knowledgable in three different databases, three different orms, three different web frameworks, 3 different cloud hosting providers. In the Microsoft ecosystem, I can be knowledgeable in writing a mobile app, a high-performance desktop app, and a web app all at the same time in the same language.
The knowledge base is amazing. Everything that is canon Microsoft has an enormous amount of stack overflow questions and blog posts about it. And specifically, blog posts about the interacting parts. There are a thousand blog posts on a sql server/EF core/with asp.net/azure app. But less on similar combinations in more heterogeneous ecosystems.
The tooling is fantastic. The IDE was built for a very specific stack so it has a lot more functionality than equivalent IDEs.
The disadvantage is you don't get to pick best of breed products. But I think this is overrated. Outside of some very specific use cases, people can write great apps in any number of languages on any number of stacks. Picking Sql Server vs PostGres vs Mongo or Ef Core vs NHibernate vs Dapper isn't going to make a huge difference on whether your app sinks or swims.
I used to be like that but over the last few years I found the Microsoft world more and more uninteresting and intellectually stifling . Maybe using git and node was the turning point where I saw how simple things can be with the right tools vs what Microsoft offered.
With git and node it was the ease of deployment and scripting. I have done some TFS scripting which was always a total nightmare. With git it’s so easy. You can like npm or not but it’s pretty phenomenal how it’s set up and works. MS was way behind the curve with nuget. The more I look into Linux tools I find them way more practical than what MS has to offer. There is just more innovation. See containers too. MS is years late. Pretty much every new trend gets started on Linux these days.
Every Microsoft shop I've been in for the last 5 yrs has been git, and you're right git was leaps and bounds better than TFS.
Its funny npm is one of the things I always hate. Several times a project I have to rimraf node_modules at some point due to some weird hidden state in npm.
Containers are an amazing technology, but sometimes I think they make it too easy to overcomplicate a project. Been on too many projects where we solved a similar problem 4 years ago with a web app and a service and a team of 3 devs, but now the same project is a team of 8 with 4 devops guys and 7 containers.
The last node project I was on was the MEAN stack. It seemed like it was pretty similar to the standard .NET apps I work on, you have an entry point, you make some database calls and you display them. Pros were the code re-use was nice, you could copy and paste your validation logic from back end to the front end. The cons were the lack of typing made it a little hard to navigate the back end, it looked like they basically reimplemented a poor man's relational database in mongo without any referential integrity, and it was harder to come up to speed without having a schema to look at and understand the domain.
There is a certain amount of seamless integration that you get when you go all in on a platform. I find the Java platform to be an unholy mess compared to the .Net ecosystem.
TFS has supported git for ages and while I kind of fell into developing in .Net on AWS and have no complaints, logically it would have made more sense to be on Azure.
No it isn't. If the whole "page" is Flash or Java - and this absolutely used to be a thing - then if that's blocked you've got nothing. With Javascript the page author has at least the option of doing it properly i.e. semantic markup plus (optionally) progressive enhancement.
Developers loved Flash: you controlled the layout, not some greedy browser vendor and their screwy CSS anti-rules, and Flash had a lot of interactive options that have be emulated in HTML browsers using ugly work-arounds. Flash just wasn't able to solve security problems. Java applets also suffered under the security ax.
Flash was based on absolute coordinates, not client side auto-flow the way browsers usually are. This means consistency across browsers. And it doesn't rule out layout engines, for you could hook any layout engine you wanted to up to it; it just happened on the server side.
But doing it on the server side means consistency: you have one and only one layout engine, not IE 6,7,8,8.5,9 and Chrome 2,3,4,5 and Safari 3,4,5,6 etc. That's bad factoring of UI and testing, a huge DRY violation at the industry level. Humans, you screwed that up! Admit it, Web is a mass labor drain.
If you can query the monitor's size and/or preference, you can adjust as needed. Just because many applications didn't doesn't mean they can't. Most web-based apps get it wrong also. One-markup-fits-all is very difficult to do well such that usually one has to emphasize a given monitor size or use a lowest-common denominator, meaning C- quality for all sizes. Even the big vendors like MS and Google often do it poorly.
For example, on big monitors you can do more in a single step (screen). On small devices you generally have to break big UI activities into multiple steps (screens). That means more going back and forth for big screen users, which they find annoying and unnecessary. That's not JUST a widget "re-flow" issue, that's an entire UI design difference.
On real GUI's you can have pop-up dialogs or pick-lists that don't hide the underlying form, or at least that you can slide around to see the underlying form. For phone-centric UI's, you can't do this, so you have to back up to get prior-entered info and then move forward and redo your half-filled sub-form. Maybe someday somebody will invent a way to do both well without a different code base, but until then, doing both well at the same time is either a pipe dream or takes an expensive rock-star UI designer and fragile dependency-causing JS libraries.
I've ranted many times that an open desktop-friendly GUI markup standard is sorely needed. Using HTML/DOM/JS/CSS to emulate real desktops keeps failing in practice and is an IT labor drain. Tens of $billions are wasted.
Desktops/mousing is still where the vast majority of "productivity" work happens. Making everything "responsive" was an over-used trend. It failed in productivity-ville. We are using UI kits designed around social networking to make CRUD apps in our shop, and it's a match made in hell. Developers don't care because it's job security, but if you step outside your paycheck, it's mowing lawns with tweezers.
Let's do it right already. I'm not saying Silverlight II is the answer, but the fact it got attention is testament to the GUI Gap.
I don't see interactivity as part of the standard. It's all static as far as I can tell. There are language-specific API's, but that defeats much of the purpose of a markup language: you have to use two languages: the XML, and then the language-specific API's. Lack of state-handling is part of why HTML/DOM gui's are Rube Goldberg devices.
The problem with RAD has been that it makes the first 80% easy, but the last 20% a bear. You don't get enough control to give the customer what they really want and need.
I've kicked around the idea of "staged rendering". The displayed elements are generated in stages, and one can alter the meta-data used in each stage as needed via event handlers. Thus, if you need to insert an extra CSS class into an element or even totally revamp a widget's HTML, you can by altering the appropriate stage. Earlier stages would have a draft "class" attribute for the HTML element which you can change or append to. In later stages, you can overwrite the entire HTML of that element, and the very latest stages allow you change or wipe large sections of pages, like the entire form block. Similar techniques can control SQL generation.
This gives you RAD-esque automation without taking away control. The automation produces various DRAFTS which you can tweak as needed along the way.
The jury is still out on my experiments.
Still, we need an interactive GUI markup standard regardless.
I don't understand why a hobby project for a few people warrants what is essentially a takedown post.There is a ton of open source projects that are not needed. People do them for all sorts of reasons. Live and let live.
This kind of thing is what makes me nervous about what WebAssembly will do to the web. Wasm is cool, but it makes it easier to deliver on some really bad ideas. Bad ideas like: maybe some blogger decides he wants to write his click handlers in Python, and now my browser has to download a 20mb Python runtime binary.
I've been on the Internet for 20 years now, and I've noticed the following trend:
1. Browser multimedia tech (Java applets, Flash, Silverlight) comes along that allows browsers to do very advanced things, like high-performance 2D and 3D graphics, cross-platform, multimedia, performant code execution, mic/webcam and other device access, etc..
2. For some reason, the Web Dev community FUDs on it, criticizing security, accessibility, open-sourcedness, etc...
3. The preferred Web Standards body of the year comes up with a plan to replace the plugin-based tech with new JS features, asm.js, wasm, web assembly, etc...
4. The multimedia tech dies a slow death, setting back browser capabilities by a decade, while Web Devs continue to try to squeeze performance out of JavaScript, and to this day fail to achieve feature and performance parity with what Java/Flash/Silverlight could do 10 years ago.
47 comments
[ 2.4 ms ] story [ 112 ms ] threadIf other developers feel the same itch, or maybe if there are still projects out there that need to be ported, then OpenSilver will live, otherwise no. I'm pretty sure that there are Silverlight apps or games out there that were never ported to JavaScript. It might not have reached Flash's level of popularity, but I remember some.
Regardless, OpenSilver is an interesting piece of technology. And whether it lives or not, such opinion pieces are worthless.
This article is flogging a dead horse.
That sentence struck a chord with me. I work in an MS shop and it always saddens me that a lot of my colleagues will always go with MS stuff. For a long time it was TFS over git, now a lot of them want Azure vs. AWS mainly because it’s MS. This attitude makes very skeptical about the recent open source efforts in the .NET world. I have a lot of doubts that any open source project that’s not from MS can be successful in this world.
Microsoft has certifications for everything. The more people with Microsoft certifications you have the more they will give you discounts on their tech stack.
This self-feeding beast creates businesses that become incentivized to hire people with MS certs to get more discounts on MS tech. Developers are encouraged to gain these certs and maintain experience in that MS ecosystem as well, which invests them in all things Microsoft.
When you factor in the vendor approval process where everything under a single umbrella has been approved (usually, MS, AWS, Google) then as a developer, you know you'll have access to those tools when you go to another similar job.
In much the same way that people are happy to invest in learning open source tools rather than internal company libraries, because the experience is portable outside of that single job.
I think MS just has created a very comfortable and convenient world where it’s really easy to use Visual Studio and MS tools. Once you leave that world you have to deal with more setup work upfront. It’s really not a big deal once you are used to it but it’s a muscle that needs to be exercised and tends to atrophy when you use Visual Studio.
And there is always the fact that nobody ever got fired for using MS. I remember when my team started using git, every time there was a problem we were asked why we weren’t using TFS where things “just” work. You need a certain amount of stubbornness to use tools against the mainstream opinion.
When it comes to TFS vs Git, even Microsoft will choose Git. (e.g. it is the only version control designed from the start to handle a major operating system kernel)
When it comes to Azure vs AWS I see them as evenly matched. If you make a decision based on your gut it won't hurt you. (If you picked IBM cloud because you liked IBM, however...)
Some Microsoft products are pretty good but often Microsoft drops the ball. For instance, the foundation of ASP.NET is absolutely great. However, they introduced some controls that looked a lot like "Web Components" that ran (mostly) on the server side. These dealt with all the usual annoyances about HTML forms, and could have been a real productivity booster.
The fatal trouble these had was that they used a state management mechanism that wasn't compatible with the "MVC" web framework approach which is mostly a matter that forms don't live in isolation. After processing the form, the server can decide to render any of a number of possible output pages: for instance you might render the same form if the form failed validation, but deliver one of several forms depending on what the user filled out (think tax paperwork)
Microsoft might have been able to make the existing system work in an MVC framework, or made something similar from the ground up to work with MVC, or other moderate decisions.
Instead they came up with ASP.NET MVC which wasn't trying to be a market leading product, but instead is a cut-rate version of Ruby-on-Rails that cut you off from much of what was cool about ASP.NET.
Microsoft had the chance to make a system that was really worth paying for, but they blew it.
Microsoft used an internal fork of perforce for most of Windows' history. Substantial changes were needed for git to handle the windows codebase. I don't know of any major project that used TFS internally, Source Depot was the primary source management.
Linux is quite small compared to many internal Microsoft code bases.
Re the Office libraries you probably wouldn't want to use them anyways. They were designed for maximum flexibility and performance not with ease of use or fast development velocity.
It's a bit like complaining Ford doesn't use its pickup trucks to transport vehicles to the dealer. They just aren't designed for that purpose.
The propaganda MS has been putting out also contradicts this. I remember well how they were first telling us that WPF, then Silverlight, then WinRT is the future of windows. Got burned a few times and then refused to look at UWP which is now the future of Windows until it probably isn’t.
It's quite a different thing to try and retrofit a traditional win32 message pump application with one of these frameworks. Especially if it's in an entirely different language and runtime. Had Office been born in the early 2000s its quite likely they would have tried to use .NET and had the same issues as Longhorn. I think Microsoft did have broad ambitions for the framework, but reality was the tech couldn't handle large scale software at that time and Longhorn failed as a result.
I think your right it is a little unfortunate win32 is needed if you want to make a million LOC desktop application. I don't think there really was anything better for native code up until recently with modern C++. The ugliness of COM and MFC are really due to limitations of C and C++ at the time. Now I don't think there is enough demand to really justify something radical.
.NET Always did reasonably well for web backends, and I think they have the right strategy to keep pushing there.
A couple of advantages to the homogeneity.
I can jump on any project and be productive on day one because not only am I familiar with but I am an expert on 95% of the stack.
I can very easily hire people who can be productive from day one because they've used 95% of the stack.
I can have much a broader skillset than is possible in other ecosystems. In other ecosystems, I might be knowledgable in three different databases, three different orms, three different web frameworks, 3 different cloud hosting providers. In the Microsoft ecosystem, I can be knowledgeable in writing a mobile app, a high-performance desktop app, and a web app all at the same time in the same language.
The knowledge base is amazing. Everything that is canon Microsoft has an enormous amount of stack overflow questions and blog posts about it. And specifically, blog posts about the interacting parts. There are a thousand blog posts on a sql server/EF core/with asp.net/azure app. But less on similar combinations in more heterogeneous ecosystems.
The tooling is fantastic. The IDE was built for a very specific stack so it has a lot more functionality than equivalent IDEs.
The disadvantage is you don't get to pick best of breed products. But I think this is overrated. Outside of some very specific use cases, people can write great apps in any number of languages on any number of stacks. Picking Sql Server vs PostGres vs Mongo or Ef Core vs NHibernate vs Dapper isn't going to make a huge difference on whether your app sinks or swims.
Its funny npm is one of the things I always hate. Several times a project I have to rimraf node_modules at some point due to some weird hidden state in npm.
Containers are an amazing technology, but sometimes I think they make it too easy to overcomplicate a project. Been on too many projects where we solved a similar problem 4 years ago with a web app and a service and a team of 3 devs, but now the same project is a team of 8 with 4 devops guys and 7 containers.
The last node project I was on was the MEAN stack. It seemed like it was pretty similar to the standard .NET apps I work on, you have an entry point, you make some database calls and you display them. Pros were the code re-use was nice, you could copy and paste your validation logic from back end to the front end. The cons were the lack of typing made it a little hard to navigate the back end, it looked like they basically reimplemented a poor man's relational database in mongo without any referential integrity, and it was harder to come up to speed without having a schema to look at and understand the domain.
TFS has supported git for ages and while I kind of fell into developing in .Net on AWS and have no complaints, logically it would have made more sense to be on Azure.
Flash was based on absolute coordinates, not client side auto-flow the way browsers usually are. This means consistency across browsers. And it doesn't rule out layout engines, for you could hook any layout engine you wanted to up to it; it just happened on the server side. But doing it on the server side means consistency: you have one and only one layout engine, not IE 6,7,8,8.5,9 and Chrome 2,3,4,5 and Safari 3,4,5,6 etc. That's bad factoring of UI and testing, a huge DRY violation at the industry level. Humans, you screwed that up! Admit it, Web is a mass labor drain.
You don't control the display which is the entire point of a hypertext reflowable render engine.
There were a ton of crappy designery flash sites with inscrutable navigation and "works best in 800x600" inflexible layout.
For example, on big monitors you can do more in a single step (screen). On small devices you generally have to break big UI activities into multiple steps (screens). That means more going back and forth for big screen users, which they find annoying and unnecessary. That's not JUST a widget "re-flow" issue, that's an entire UI design difference.
On real GUI's you can have pop-up dialogs or pick-lists that don't hide the underlying form, or at least that you can slide around to see the underlying form. For phone-centric UI's, you can't do this, so you have to back up to get prior-entered info and then move forward and redo your half-filled sub-form. Maybe someday somebody will invent a way to do both well without a different code base, but until then, doing both well at the same time is either a pipe dream or takes an expensive rock-star UI designer and fragile dependency-causing JS libraries.
Desktops/mousing is still where the vast majority of "productivity" work happens. Making everything "responsive" was an over-used trend. It failed in productivity-ville. We are using UI kits designed around social networking to make CRUD apps in our shop, and it's a match made in hell. Developers don't care because it's job security, but if you step outside your paycheck, it's mowing lawns with tweezers.
Let's do it right already. I'm not saying Silverlight II is the answer, but the fact it got attention is testament to the GUI Gap.
Look at Avalonia:
https://github.com/AvaloniaUI/Avalonia
Seems they wanna spec it out:
https://github.com/microsoft/xaml-standard
I've kicked around the idea of "staged rendering". The displayed elements are generated in stages, and one can alter the meta-data used in each stage as needed via event handlers. Thus, if you need to insert an extra CSS class into an element or even totally revamp a widget's HTML, you can by altering the appropriate stage. Earlier stages would have a draft "class" attribute for the HTML element which you can change or append to. In later stages, you can overwrite the entire HTML of that element, and the very latest stages allow you change or wipe large sections of pages, like the entire form block. Similar techniques can control SQL generation.
This gives you RAD-esque automation without taking away control. The automation produces various DRAFTS which you can tweak as needed along the way.
The jury is still out on my experiments.
Still, we need an interactive GUI markup standard regardless.
1. Browser multimedia tech (Java applets, Flash, Silverlight) comes along that allows browsers to do very advanced things, like high-performance 2D and 3D graphics, cross-platform, multimedia, performant code execution, mic/webcam and other device access, etc..
2. For some reason, the Web Dev community FUDs on it, criticizing security, accessibility, open-sourcedness, etc...
3. The preferred Web Standards body of the year comes up with a plan to replace the plugin-based tech with new JS features, asm.js, wasm, web assembly, etc...
4. The multimedia tech dies a slow death, setting back browser capabilities by a decade, while Web Devs continue to try to squeeze performance out of JavaScript, and to this day fail to achieve feature and performance parity with what Java/Flash/Silverlight could do 10 years ago.