Flash died because it was on the wrong side of the technology fence. The vast market share it picked up during the 'desktop' phase of the internet gave it huge inertia, but this was only sustainable in a mac/pc safari/IE duopoly. Once other devices started to arrive - TV's, set top boxes, fridges, kindles - the writing was on the wall. Adobe just couldn't sustain the investment (didn't have the business model) required to port to those devices, let alone the engagement with the vendors concerned. When smart phones took off, the dam burst.
Silverlight died because it set out to compete with an already obsolete technology, sustained purely by its own market share, as opposed to any real long term benefits at the time. All the downsides, none of the benefits - not a great sales pitch. The lesson here is that - in the end - interoperable standards do win out, through market forces alone. ________________________________ From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf of DotNet Dude <adotnetd...@gmail.com> Sent: Wednesday, January 30, 2019 5:30:43 PM To: ozDotNet Subject: Re: Blazor comments I believe Silverlight died mainly because of the lack of support for the plugin on iPhones. Blame Apple. On Wed, 30 Jan 2019 at 17:53, Arjang Assadi <arjang.ass...@gmail.com<mailto:arjang.ass...@gmail.com>> wrote: until a rendering engine is included I can not see any benefit to using blazer or any other WASM equivalents. Flash as bad as it was , was a better solution , no idea what the big idea was to kill it off , or for that matter ms unilaterally killing silver light. On Wed, 30 Jan 2019 at 5:26 pm Greg Keogh <gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote: Folks, has anyone else in here given Blazor a good bash and got comments? I've run some sanity tests on 0.7 and it's looking pretty good. You can reference packages and projects, there's basic binding (which I hope they improve), you can break things up into "components" and nest them, separate code-behind if you want, register and inject services, define routing, make async web calls, deploy to Azure web apps, etc. All this stuff I mentioned is in the docs, but I had to try it myself to see if it really works. The only thing I haven't tried yet is rendering a large complex page to see how it performs and responds to DOM changes. So finally it looks like there's a real chance in the .NET ecosystem that the crazy zoo of JS frameworks to make SPAs will be displaced by a familiar and respected languages and frameworks. Great, but suddenly I was slapped hard by a shocking realisation … we're still stuck using the web browser and HTML (and some JS glue) for rendering the UI. The web browser cannot render complex business app UIs. Where are the rich controls and layout features we are used to on the desktop, or in Silverlight, or Flash or Java Applets for that matter? HTML was created to render simple text and pictures and now 27 years later it's completely effing stupid that we're still trying to create apps with it. We're changing how those apps are written, but we're still stuck with the damn browser and HTML for rendering. I have an example … a few weeks ago I wondered by a web page was taking 40s to load. It turned out I was loading a tree (a fake one, as there is no tree control) with 4000 nodes, each one in a div and 3880 of them were hidden. So the page looked small and tidy, but there were thousands of hidden divs. I spent hours of suffering inventing a click-demand-load technique. There is no virtualisation in HTML, which is taken for granted in real UI frameworks. There endeth the good news and the bad news. Greg K
