5 ms·

Silverlight Shouldn't Come Back to Life

44 points by 4mpm3 7y ago

kid64 7y ago
It’s been a long time since I’ve seen so much misinformation in a single article .. not even sure where to begin.
- nxc18 7y ago
  I'd appreciate it if you could begin. I read the article and didn't spot anything seriously wrong.
bad_user 7y ago
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.
diego_moita 7y ago
Who cares? Now we have WebAsm. This article is flogging a dead horse.
- 4mpm3 7y ago
  Plot twist: OpenSilver uses WebAsm. That's part of what makes the story so bonkers.
iou 7y ago
Haha, didn't even need to read the article, I'm in agreement with the title alone!
Ididntdothis 7y ago
“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.
- brightball 7y ago
  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.
  - Ididntdothis 7y ago
    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.
superkuh 7y ago
At least Silverlight can be blocked and pages will still work. Javascript is worse than flash, worse than silverlight, worse than java applets.
- mrec 7y ago
  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 7y ago
    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 7y ago
      > 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 7y ago
        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.
deleted 7y ago
[deleted]
tabtab 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      I feel like RAD tooling is the best way to do UI work, it's a shame we keep going backwards on that.
      - tabtab 7y ago
        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.
StaticRedux 7y ago
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 7y ago
  They are selling premium support so I’d consider it in that context.
  - notRobot 7y ago
    Right, so? The few (if any) who need it can opt for it, the rest can ignore it?
  - StaticRedux 7y ago
    In that context they saw a market opportunity and took a chance. Makes it even stranger to dedicate a takedown post to it.
paulhodge 7y ago
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.
lxe 7y ago
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.
JamesBarney 7y ago
I think this author is the only person alive who fears some Silverlight revival.

44 points by 4mpm3 7y ago

kid64 7y ago

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

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

bad_user 7y ago

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.

diego_moita 7y ago

Who cares? Now we have WebAsm. This article is flogging a dead horse.

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

iou 7y ago

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

Ididntdothis 7y ago

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

brightball 7y ago
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.
- Ididntdothis 7y ago
  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.

superkuh 7y ago

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

mrec 7y ago
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 7y ago
  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 7y ago
    > 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 7y ago
      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.

deleted 7y ago

[deleted]

tabtab 7y ago

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 7y ago
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 7y ago
  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 7y ago
    I feel like RAD tooling is the best way to do UI work, it's a shame we keep going backwards on that.
    - tabtab 7y ago
      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.

StaticRedux 7y ago

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 7y ago
They are selling premium support so I’d consider it in that context.
- notRobot 7y ago
  Right, so? The few (if any) who need it can opt for it, the rest can ignore it?
- StaticRedux 7y ago
  In that context they saw a market opportunity and took a chance. Makes it even stranger to dedicate a takedown post to it.

paulhodge 7y ago

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.

lxe 7y ago

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.

JamesBarney 7y ago

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