Microsoft may halt development work on Silverlight plugin after next release
theverge.com
Interesting announcements from Adobe and Microsoft, one after another.
theverge.com
In a way, I think it might be the combined weight of the iPhone and iPad that's broken the stalemate in HTML5's favour. Apple sold so many of them, that website makers had to take notice.
When Microsoft announced that Windows 8 metro mode (which may well be the only mode available for low power Win8 tablets) would not support Silverlight, I think the game was well and truly up.
Two years ago, flash was the only game in town; Good HTML5 implementations were no where to be found, and Silverlight adoption was a joke. It's not like you could HTML5 an equivalent to flash on an iPhone OS 3.
I agree that things started changing rapidly two years ago, with the introduction of iOS 4. But there was never a stalemate -- Flash was king; then there was chaos; and now HTML5 is winning (for the time being, though not for long, Flash is still among the royalty). Silverlight had always been a wannabe.
EDIT: I admit, there was a time when Flash was the only option, but as early as 2003 I recall "Ajax" being used in preference to Flash for web user interfaces that needed an element of richness. So, I think there has been dissatisfaction with Flash for longer than you imply.
In 2003, there was Ajax rich (you could do some nontrivial client side processing -- like hide and show elements), and there was Flash rich (antialiased polygons, sound). I was talking about the latter, and so do most people that consider HTML5 a worthy flash replacement (even though e.g. you still have to use Flash for proper sound support).
Canvas tag was in safari (both desktop and mobile) and Firefox. Flash (at it's core) is just a canvas you can draw on.
2 Years ago, Flash (or Flex) was immature (for RIA), had poor tools, and poor runtime support (i.e half implemented exception handling, memory leaks etc), impossible to test.
HTML by comparison had a lot of tools for interaction models, and was only immature around canvas (animation/effects). Was easy to test etc.
They were kind of the inverse of each other. Flash was definitely not king. The company I worked at, was working on one of the largest flash apps around, and we constantly had problems with flash, to the point where a silverlight or HTML5 port was considered. (Not sure what they ended up doing).
It sounds like your companies upgrade policies suck! OR, their decision to support/build around proprietary web technologies, hindering their ability TO upgrade. That sucks.
For the last three years, I'd find anyway to build a RIA in anything but JS/HTML. I'd use GWT/Cappuccino/Silverlight/Flex, etc. After Microsoft's move, I finally just embraced JS/CoffeeScript; I love every bit of it.
That sounds like revisionist history to me. Plenty of people complained about the lack of Flash and speculated that Apple might eventually have to give in and allow it, but I don't think any significant number of people suggested or believed that the iPad wouldn't be taken seriously without it.
People who relied on the Silverlight plugin certainly cannot continue to develop it, either.
Long-run, there's more security in relying on software created by a sufficiently large and capable community of enthusiasts. Such software will never die if it's good enough to be useful - sunk costs, NIH, and all that.
The "strategic direction" of a community won't change except by consensus. People will enter and leave. By the time the community withers and dies, nobody cares any more.
While announcing lots of C++ love for Visual Studio and promises of C++11 compliance they don't have an API for writing native code apps on Windows
The 'official toolkit' is WPF and whatever managed C++ is called today. But with Silverlight dead what future does it's under regarded cousin have?
So no problem we all switch to it's new tablet/phone OS. Only they won't tell us which of the windows phone toolkits are going to be on tablets and PCs - if any.
Or are we supposed to be developing all our apps for Azure and the cloud now?
Or are they just abandoning the PC like HP and we write everything in HTML5 for the browser?
Silverlight used to be promoted as:
* Flex/Flash compete * Public web compete (I never recommended it for such) * line-of-business (not publicly available) apps * (recent) Windows Phone 7
Silverlight is now promoted as:
* line-of-business apps * Windows Phone 7, but maybe Win Phone 8 will look more like the Win8 Metro XAML (I don't think they've said anything yet)
Metro is now promoted for:
* Win8 tablet apps * Win8 native apps(? who cares I guess?) * possibly Win Phone 8 apps
I don't know what apps you write, so I don't know what your specific roadmap may look like. I've leaned toward recommending web apps over "client" apps for .NET devs the past few years, and will heavily lean that way going forward. ASP.NET MVC skills translate easily to open source/competing web frameworks. WPF or Silverlight developers can't say the same thing.
But I bet you're feeling betrayed. I understand. I felt a little betrayed a few frameworks ago. Post-betrayal, I stick to focusing on transferable skills and JIT learn the rest of .NET. I'm on a WPF project now, have not studied WPF deeply.
My advice: if you have any say in the matter, try to work with ASP.NET MVC as opposed to the .NET alternatives, so your skills transfer.
Footnote: I don't know how many worked on Silverlight/WPF/WP7 versus how many work on XAML now. I assume XAML will march on. But no one will care unless/until the Windows tablet is successful.
Personally I stuck to C++ and moved MFC->wx->Qt !
.Net is interesting for the way it allows things like Ironpython and F# in as first class languages and wpf is fun to play with, but if you can't write something like Office or photoshop in it then it's just a toy.
I'm still writing to the native WIN32 API (albeit via Borland's C++Builder which uses the VCL 'Visual Component Library', the same library that powers Delphi) and that stuff still runs on Windows 7.
And once again, all the companies that decided to rely on a proprietary, non standard technology are going to get bitten.
Plenty of companies out there are still using VB6. It's not like Microsoft is going to take away the download or something, they'll just stop developing it.
Also, why "good riddance"? Do you just hate everything Microsoft or did Silverlight really cause you any problems personally?
It will be much easier to move away from Silverlight than it is from VB6. VB6 will haunt us for generations.
"Any application that can be written in JavaScript, will eventually be written in JavaScript."
http://www.codinghorror.com/blog/2009/08/all-programming-is-...
Also, this is pretty clear as well:
But to your point, I'd wager that .NET is already used more on the server side than on clients apps as its use in enterprise line-of-business is massive.
http://blog.discountasp.net/build-conference-developers-have...
With Microsoft diagrams, the importance of the technology is proportional to the size of the box.
Silverlight may very well be going away, but XAML/C# isn't. The only thing that's most likely disappearing is the push for it to be on the web and the name "silverlight" itself.
It's sort of a combo HTML&CSS. So your statement in that vein would be like "Isn't HTML&CSS just another name for Gecko and/or WebKit?"
That said, even though it looks like XAML may be used for new WinRT-based apps in the Windows Metro stuff, I'd be surprised if it survives the deaths of Silverlight & WPF.
Good job we all switched to Qt and C++
The only thing Netflix needs to do is make it inconvenient to rip the stream, i.e. more difficult than downloading the same thing as a torrent. Anything more is pointless.
I look forward to our new HTML5 overlord.
SGML/HTML/XML/CSS/JS have the true open standard good side instead of anticompetitive proprietary grip. But let's not fool ourselves, those languages are terrible and backwards. Same with HTTP. Also HTML5 still falls short of many missing features on the web.
I'm hoping for a new generation of a better set of languages to take over. But this feels like hoping for x86 to go obsolete, even Intel couldn't kill it.
I hope that someday the farting around with compile-to-js stops and we get a true bytecode VM-in-browser.
VM isn't necessarily going to make things better. JS execution speed increased by orders of magnitude (it's getting close to decoding H.264 in real time!)
It's more likely that ES6 and future versions will make JS more palatable and easier to optimize.
Currently it's the DOM that needs work: it's full of messy, needlessly complicated C++-derived interfaces and DOM speed didn't get as much love as the raw JS.
What I'd like to see is a layer of abstraction somewhere between canvas/SVG and the DOM: you have mostly-rectangular objects, with Swing- and Qt-style layout managers used to specify their positions. The container object's CSS specifies the layout used to arrange its children. It would need to be possible to write custom layout managers in JavaScript. Then you could write a layout manager that evenly spaces its items around a circle (or any other arbitrary path), for example.
A bytecode VM would allow things like Coffeescript to run without the JS interlayer.
My larger point is that Javascript as a language is atrocious, along with SGML derivatives, along with CSS. The web stack is a polished turd that has been pretzeled far past the initial design. While HTML and CSS are not very straightforward to 'fix' today, starting with a bytecode-based execution model will allow some revolution instead of incremental JS improvements.
I really hope this isn't true.
Remember when IE6 was so incredibly easy to work with? Remember how much effort has been dedicated to port those internal "web applications" that worked on one specific browser?
That's an interesting idea. Allow me not to take part on it.
At least my master gives me a 'created-date' field on every file. Gosh, that makes sense. I'd have to write my own file-system or use some outdated, unsupported crap to have that on 'nix.
I see you are unfamiliar with modern *nix OSs. Mine gives me both creation time and access time:
rbanffy@computer:~$ ls -l --time=atime a.out
-rwxrwxr-x 1 rbanffy rbanffy 8378 2011-11-10 15:24 a.out
rbanffy@computer:~$ ls -l --time=ctime a.out
-rwxrwxr-x 1 rbanffy rbanffy 8378 2011-10-22 19:31 a.outhttp://unix.stackexchange.com/questions/20460/how-do-i-do-a-... "Note that the ctime (ls -lc) is not the file creation time, it's the inode change time."
So, like I said...yes you do have to roll your own to get it. Enjoy that.
I see where you are going. I guess I'll have to move to FreeBSD to get file "birth time" support (or look into POSIX extended attributes). It's more or less a painless change. FreeBSD also has ZFS support, which is the filesystem to rule'em all. Either way, I don't expect Silverlight or WPF to run on FreeBSD.
The takeaway is this: don't build your mission critical internal apps on a Microsoft browser plugin. This has never worked out well.
OTOH, you may be tied to IE6 and unable to see all this.
Can you even get a data grid that is half as powerful or has as robust an API as something like this? http://www.telerik.com/products/wpf/gridview.aspx
Which is the whole point. Gmail runs on my Mac, on my Linux machines, on my OpenSolaris server (actually, it runs OpenIndiana these days) and on my tablet. It would probably run just fine on my AIX boxes if I compiled Firefox or Chromium for them. If Google abandons it (but keep the servers running) it will continue to operate on newer computers and newer browsers until Google pulls the plug.
I'm sure the Gmail team could do a bunch of hacks to fix this, but that's the problem. You have to hack-up everything to make HTML work well as an application platform.
If you think that's a good grid, I don't expect you to see anything remarkable about the grid I posted.
Looking around my office, I gather it would run on about four or five computers out of the about 50 here.
[1] http://www.microsoft.com/getsilverlight/Get-Started/Install/...
People who only do web dev just don't know what quality is.
I don't understand why everyone is so hung up on HTML though. The internet is not HTML, the internet is TCP/IP and all the protocols that ride on it like HTTP.
Why can't we just leave HTML the way it is, use it primarily for making nice documents and come up with something new for apps? You know, instead of trying to shoe-horn everything into a spec that has to cover both apps and documents or anything in-between?
Why isn't there a standards committee for a kit like Silverlight or Flash? The runtime would have to be built once for each platform, but that's no different than HTML.
every discussion i've ever seen about advancing the state of the web, the sticking point has always been "what about intranet/corporate networks?". well, if you run an intranet, fuck you. stop using the idea that you control the endpoint as an excuse to write crappy apps. you shouldn't be controlling that end point, you should be giving your users freedom to access your services in as many ways as possible rather than limiting their productivity by restricting their usage to your approved endpoints.
security policies like those are stupid, and an artifact of a time before networks. we shouldn't have to build our networks around outdated policies, security policy should be built to accommodate the technologies of the time.
Nobody should ever invent a competing technology because HTML is good enough for you? Is that it?
As long as this technology is easy and free for everyone to implement in compatible ways, yes, you can.
I think that I understand why someone would wish to exclude all proprietary technology. No advocacy is the best advocacy though. If the product is so great, it sells itself. It does. People use 'nix all the time for the things it's good at and then they go use other stuff too. Hostility towards that "other stuff" really works against the cause IMO. Why not spend the same time an energy to make the product better? Then people will just use it and nobody will have to argue about it.
Keeping a fragmented ecosystem with a 'WebDirectX' or some other proprietary new tech will just slow overall progress in this area. For web developers doing 3D it means "This site requires IE/This site doesn't support IE" unless you can support two parallel codebases.
People within both Microsoft and Google use my app, and I recently heard from our division president that they were "blown away".
With this news the mandate came down to prepare to "rewrite in python". How is that for marching orders. Makes no sense but management is so anti-Microsoft at this point they are irrational.
As a developer I have sunk years of time and effort into this. I guess I can take my XAML knowledge and build windows 8 LOB apps down the street.
Of course, it's entirely too sensible to have actually happened. Instead the IE team went off and wrote their own JIT for IE7/8/whatever and are still playing catch up to Chrome.
At this time about 2 years ago they did have JS running on CLR and it was 2x faster than any browser out there.
http://techblog.netflix.com/2010/12/why-we-choose-html5-for-...
The most maddening part of working on a Silverlight app was that things that are dead simple with HTML/JS/CSS are tons of work with SL. I was always amazed at the gymnastics required to get even simple UI functionality to work.
Xaml itself was a problem. Why in god's name to we need another superset of XML? Especially with all that atrocious binding syntax.
And also, every time you want to see a UI change you have to build the XAP. When you have tons of Xaml is takes forever to compile to see a minor change!
As far as tips - vertical stack panels are just a series of unfloated divs (or other block element). Horizontal stack panels are a series of floated divs.
Vertical positioning with HTML/CSS can be tricky, especially in older browsers. line-height and padding/margin are you friends :)
I found this a couple of weeks ago, and it seems like it might be useful: http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/ Demo: http://www.html5rocks.com/en/tutorials/flexbox/quick/ I wanted to post this for anyone who stumbles across this info via search.
Silverlight in itself was never meant for the web, it was meant for more robust desktop applications, and it shows. The C#/XAML stack works great for complex applications. Likewise, html/js aren't that fantastic of languages to work with when doing embedded applications; but they're a great team for the web.
Would you be willing to share what was easy with HTML/CSS/JS that was tons of work with SL and what gymnastics you had to go through? I'm genuinely curious.
Further, text wrapping and layout were my biggest pain points in SL. I wasn't used to having fixed dimensions on everything. That really bugged me.
Finally, I didn't like the visual state manager at all. There's not really an analogous equivalent in JS/HTML, but for a "rich" internet platform it certainly didn't seem like the way to go to me. I have to run now, but I'll try and think up some more of my pain points and edit as appropriate.