
Silverlight Shouldn't Come Back to Life - 4mpm3
https://medium.com/young-coder/the-open-source-project-that-wants-to-reboot-silverlight-74817b430ee7
======
Ididntdothis
“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.

~~~
PaulHoule
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.

~~~
jdsully
> 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.

~~~
Ididntdothis
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.

~~~
jdsully
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.

~~~
Ididntdothis
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.

~~~
jdsully
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.

~~~
Ididntdothis
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.

~~~
JamesBarney
Most desktop projects I've seen have stuck with WPF and they've all been happy
with that decision (except for a few who wish they'd gone web).

~~~
Ididntdothis
That’s pretty much how I feel. Go to web if possible. It’s also better for the
resume :)

------
bad_user
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.

------
StaticRedux
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.

~~~
nxc18
They are selling premium support so I’d consider it in that context.

~~~
StaticRedux
In that context they saw a market opportunity and took a chance. Makes it even
stranger to dedicate a takedown post to it.

------
tabtab
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.

~~~
giancarlostoro
Would it be too wrong if we took XAML and standardized it for other languages?
Pretty sure it's generic enough.

Look at Avalonia:

[https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia)

Seems they wanna spec it out:

[https://github.com/microsoft/xaml-
standard](https://github.com/microsoft/xaml-standard)

~~~
tabtab
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.

~~~
giancarlostoro
I feel like RAD tooling is the best way to do UI work, it's a shame we keep
going backwards on that.

~~~
tabtab
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.

------
lxe
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.

------
kid64
It’s been a long time since I’ve seen so much misinformation in a single
article .. not even sure where to begin.

~~~
nxc18
I'd appreciate it if you could begin. I read the article and didn't spot
anything seriously wrong.

------
JamesBarney
I think this author is the only person alive who fears some Silverlight
revival.

------
paulhodge
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.

------
diego_moita
Who cares? Now we have WebAsm.

This article is flogging a dead horse.

~~~
4mpm3
Plot twist: OpenSilver uses WebAsm. That's part of what makes the story so
bonkers.

------
iou
Haha, didn't even need to read the article, I'm in agreement with the title
alone!

------
superkuh
At least Silverlight can be blocked and pages will still work. Javascript is
worse than flash, worse than silverlight, worse than java applets.

~~~
mrec
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.

~~~
tabtab
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.

~~~
kevin_thibedeau
> you controlled the layout

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.

~~~
tabtab
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.

