Silverlight Shouldn't Come Back to Life
medium.com
medium.com
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.
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.
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:
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.
This article is flogging a dead horse.
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.