Microsoft may halt development work on Silverlight plugin after next release(theverge.com)
theverge.com
Microsoft may halt development work on Silverlight plugin after next release
http://www.theverge.com/2011/11/9/2548975/microsoft-may-halt-development-work-on-silverlight-after-next-release
Interesting announcements from Adobe and Microsoft, one after another.
141 comments
Until a year or two ago there was a stalemate as far as "rich web" development technologies goes. Neither flash, Silverlight or HTML5 was the clear winner. I remember people being incredulous that the iPad didn't support Flash, saying that while it might be ok for the iPhone to not support it, nobody would take the iPad seriously if it didn't support Flash.
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.
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.
Stalemate?
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.
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.
I guess I mean that for people who were considering which platform to build their rich internet app on, there was not a obvious choice.
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.
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.
Your choice of words was unfortunate, then - "stalemate" implies a tie with no possible move for any player.
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).
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).
I don't think that's true.
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).
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).
HTML5 support still sucks. I work with companies daily who are forced to use old versions of IE. So, we're forced to use plain HTML to build our business on, technology is going backwards.
HTML5 support doesn't suck. Check out http://caniuse.com, and you'll notice that non-IE browsers are doing a rockin' job supporting HTML5. If you develop for iOS or Android, HTML5/CSS3 has been a joy. Sure, there are hiccups, but support is far from "sucking".
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.
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.
It doesn't help that Flash was deficient in a variety of ways. I think this was Adobe's fight to lose.
I am/was a Silverlight fan. When Microsoft made it clear that they were focusing on JavaScript (I realize it's not standard's compliant) with Windows 8, I finally spent a lot of time considering the situation. Apparently a lot of the Silverlight team quit or was moved to other divisions. The wriitng was on the wall.
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.
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.
> nobody would take the iPad seriously if it didn't support Flash
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.
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.
At Microsoft you have a bunch of brilliant programmers who are forced to follow "strategic direction" from above. Even if they wanted to, there's no way they can continue working on a mothballed project they still believe in.
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.
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.
I would love to know what Microsoft's strategic direction is.
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?
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?
The 'official toolkit' Metro is XAML + (C++ or .NET or MSHTML5). I've been told by a (true) Silverlight/WPF expert that the Win8 XAML most resembles the Silverlight API.
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.
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.
If all the Silverlight team have been taken out and shot does XAML have a future?
If from a developer's viewpoint, XAML looks identical to Silverlight, and there are the same number of people working on XAML for the Windows team as there used to be working on Silverlight for DevDiv, does it matter?
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.
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.
I assumed that XAML was the silverlight team (why duplicate effort) and if silverligth is gone how much core knowledge stays in XAML?
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.
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.
There you go, no problems then.
"they don't have an API for writing native code apps on Windows"
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.
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.
Good riddance.
And once again, all the companies that decided to rely on a proprietary, non standard technology are going to get bitten.
And once again, all the companies that decided to rely on a proprietary, non standard technology are going to get bitten.
In the meantime, there's no really reliable standard, cross-platform and cross-browser way to play back audio or video in the browser as major browser vendors still cannot agree on a single codec that would work everywhere.
That magical method of playing audio or video has never existed, though. The elimination of the Silverlight plugin (and mobile Flash!), neither of which were reliable cross platform/cross-browser, should speed up the efforts put in to finding such a perfect solution.
Hopefully. Unfortunately, any time anyone talks about cool new innovations in the browser, we have to use the word "hopefully".
What was the alternative? HTML/CSS?? Hah.
Not really. Silverlight will be about as dead as VB6.
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?
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?
Have to disagree with the VB6 analogy. There was a huge investment by customers in VB6. It had more developer seats than any other Microsoft development environment. There were simply too many LOC to be re-written. Silverlight has not achieved that market penetration. If Microsoft stops backing it the drop off from all radars (bus., dev., game) will be very quick.
I wasn't saying that Silverlight reached the same market penetration as VB6. What I said was that Microsoft isn't going to take it away and make it not work. Like VB6, you'll still be able to run it if you want.
> Not really. Silverlight will be about as dead as VB6.
It will be much easier to move away from Silverlight than it is from VB6. VB6 will haunt us for generations.
It will be much easier to move away from Silverlight than it is from VB6. VB6 will haunt us for generations.
Damn, we're getting ever closer to Atwoods law!
"Any application that can be written in JavaScript, will eventually be written in JavaScript."
http://www.codinghorror.com/blog/2009/08/all-programming-is-...
"Any application that can be written in JavaScript, will eventually be written in JavaScript."
http://www.codinghorror.com/blog/2009/08/all-programming-is-...
I don't know what Silverlight does under the covers, but the event handling language in Flash is Actionscript, which is a dialect of Javascript. So in that sense we're already there.
Silverlight is just C# (or theoretically any CLR language) with XAML layouts and a specialized set of libraries.
Microsoft's IE9 product lead, said - without even saying that it was confidential or not to repeat - 'Silverlight is dead, I give it six months tops' at OnGameStart a couple of months ago. I believe him.
Just the web plugin. No evidence of it going away on WP7 or Windows 8.
That isn't what I've heard (from people still at Microsoft). Everything points to Silverlight and WPF being frozen because the teams are pretty much broken up at this point.
Also, this is pretty clear as well:
http://www.ustream.tv/recorded/17254070
Also, this is pretty clear as well:
http://www.ustream.tv/recorded/17254070
The branding might be going away, just like the Zune brand, but the core technologies are already part of the Windows 8 SDK.
What core technology - XAML & .NET ? AFAIK WinRT is a rewrite and is not compatible with WPF & Silverlight. Silverlight (cross-platform RIA plugin) seems dead.
Certainly Win8 and Windows Phone are not binary compatible with WPF and Silverlight but if you wander around the portion of msdn dedicated to Metro apps or to phone development and look at the available types and methods from the core runtime up to the presentation layer you can see that the common overlap is very large and that they probably started from the same place.
So the namespaces have changed, but the techniques remain the same. XAML remains the same. I can't imagine anyone expecting their WPF application to compile for a new interface with different metaphors.
Forget silverlight, .net itself has a questionable future on windows client. WinRT went back to C++. .NET is being positioned a server side technology.
It depens on what you consider .NET. The CLR? The .NET metadata schema? C#/VB? The only thing that isn't incredibly important in WinRT is the CLR proper. But the other aspects of .NET play a huge role in WinRT. They even went and largely reimplemented the BCL. And the API design guidelines across the board are .NET based. WinRT looks a million times more like .NET than Win32.
WinRT supports .NET applications.
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.
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.
WinRT works just fine with .net.
There were updates made to WPF in the recent .NET 4.5 beta that was released at BUILD. Not immense updates, but non-trivial ones either.
Get out your magnifying glass and find Silverlight and .NET on this diagram from Build:
http://blog.discountasp.net/build-conference-developers-have...
With Microsoft diagrams, the importance of the technology is proportional to the size of the box.
http://blog.discountasp.net/build-conference-developers-have...
With Microsoft diagrams, the importance of the technology is proportional to the size of the box.
Isn't XAML another name for Silverlight and/or WPF?
The XAML/C# stack is called many different things within windows. Silverlight and WPF are just two names for it. Keep in mind though that even things that are branded silverlight (desktop/web apps and wp7 apps) aren't even the same thing. The WP7 API differs heavily from the desktop API. The XAML/C# stack for metro apps is also just a very small subset of the silverlight stack.
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.
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.
Sort of. That is, traditionally XAML has been used primarily for Silverlight & WPF applications, but it's actually just a declarative language used for laying out (usually) Silverlight & WPF controls.
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.
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.
WP7 and 7.1 have just a few apps. Do you think WP8 won't use something like winjs ala Windows 8?
The year before the Silverlight team were saying that
WPF is dead and Silverlight is the future.
Good job we all switched to Qt and C++
Good job we all switched to Qt and C++
I'm curious what Netflix has in the works to move off of Silverlight. I remember reading that their biggest problem with HTML5 players was the lack of good DRM options to please the studios.
Someone needs to explain to the studios about how computers are really great at copying stuff, which means DRM only ever has to be broken once by one person, and it doesn't matter if it's Netflix or Blu-ray or HBO.
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.
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.
No, Netflix has to prove that they aren't the point of failure. Which means DRM is a requirement. Content owners demand it.
What does Netflix use for their iOS app? That's not based on Silverlight is it?
Likely what they do on every other platform already; a sandboxed HTML5 "native" app. They could also take the NaCl route like they do for ChromeOS; but I don't think NaCl is available in plugin form yet (not that it matters for Win8; plugins of any kind are verboten in Metro mode)
Why would they want to move off something that works? The plugins will be getting security updates after all.
.. fixes for OS updates? Comparability with newer drivers?
One code stream for obsolete windows a different one for new windows, another for iPhone/OSX, another for Android......
It's a great day, both Flash and Silverlight are on the road to obsolete.
I look forward to our new HTML5 overlord.
I look forward to our new HTML5 overlord.
Well, now that you mention it...
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.
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.
Yes, the clientside web stack needs to be obseleted as well.
I hope that someday the farting around with compile-to-js stops and we get a true bytecode VM-in-browser.
I hope that someday the farting around with compile-to-js stops and we get a true bytecode VM-in-browser.
We had true bytecode in the browser already, it was called Java.
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.
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.
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.
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.
So apparently people are highly opposed to the idea? What would be a better alternative for creating and laying out web apps without the overhead of the full document object model?
Java in the browser has been a horrible experience since the 90s until now. I suspect part of that is the fact that it is always a non-native plugin and has an excruciating load time.
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.
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 "get" it when it comes to silverlight for public facing websites. Really. I do. The general populace doesn't want to have to install a plugin. But what about intranet apps? Silverlight is so incredibly easy to work with (compared to html/css/js) that there are lots of companies that have built intranet apps with it because they control the end point.
I really hope this isn't true.
I really hope this isn't true.
> But what about intranet apps?
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?
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?
You're comparing apples to oranges. IE6 is a browser, Silverlight is a plug-in. Using Silverlight doesn't mean that you can't switch browsers.
As long as your browser supports the SL plugin.
Incorrect. Silverlight runs out of browser.
Oh... You mean using Silverlight for intranet applications without a browser...
That's an interesting idea. Allow me not to take part on it.
That's an interesting idea. Allow me not to take part on it.
You're allowed. I'm also allowed to not be held hostage by a "standards committee" that never gets anything done.
Wouldn't you say HTML is at least partially done?
You know you are hostage of a company that may discontinue the technology you depend on any moment they want, right?
I prefer being hostage to Microsoft rather than Apple, the Gnome team or the KDE team. Outside of building your own OS and your own user interface, you only have slightly more of a degree of freedom with 'nix.
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.
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.
It can happen with Apple, if you rely on a proprietary technology they control, but it cannot happen with Gnome or KDE because, if you don't like what they do, you can always roll out your own.
I see you are unfamiliar with modern *nix OSs. Mine gives me both creation time and access time:
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.outctime is change time, not creation time.
http://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.
http://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.
Interesting. In this case, the creation time and i-node change time are the same - the file was written as new.
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.
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.
[deleted]
A lot of companies that said the same about ActiveX are still limping along with IE6. I'd rather ask my boss to budget for more development time than to suggest rolling out a single-platform solution in 2011.
The takeaway is this: don't build your mission critical internal apps on a Microsoft browser plugin. This has never worked out well.
The takeaway is this: don't build your mission critical internal apps on a Microsoft browser plugin. This has never worked out well.
One really important reason is not to tie your intranet to the Silverlight/Flash/runtime N roadmap. Better to hook up to something that will run in browsers without painting yourself into yet another proprietary corner.
Yeah, let's have a richly, wonderful, HTML interface that still can't replicate desktop GUI productivity from the 90's...
I have very rich HTML+JavaScript+JSON interfaces here that make me orders of magnitude more productive than I was in the 90's, but that may be me.
OTOH, you may be tied to IE6 and unable to see all this.
OTOH, you may be tied to IE6 and unable to see all this.
Please, show me your best HTML UI components and we will compare them to the native ones or even the Silverlight ones that are available (from Telerik, DevExpress, Infragistics, ComponentOne, etc)
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
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
Can't tell. It won't run on my computer.
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.
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.
For a few decades people accessed email on text based terminals. There's plenty of applications with more complex UIs than email...
I have other applications with more complicated UI's also relying on HTML and AJAX and they work just fine. What kind of web applications do you have that would require Silverlight or something similar?
How about an email application that handles keyboard acceleration really well? This can be done easily with Silverlight (in or out of the browser), but not so much with HTML. That's why Gmail has crummy keyboard handling. In Thunderbird, I can tab my way around the entire interface if I want to or use keyboard shortcuts.
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.
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.
It does look powerful, but the font rendering is dire. So the browser gets at least one plus.
I don't see anything particularly remarkable there.
http://www.trirand.com/blog/jqgrid/jqgrid.html
http://www.trirand.com/blog/jqgrid/jqgrid.html
Is pagination of the data (as shown in those examples) mandatory? It seems kind of annoying to have to limit the amount of data actually in the browser at one time, especially if it's done for "performance" reasons.
Pagination isn't even necessary if you load chunks of the table as needed. You can even render proportional scrollbars if you know how large the table should be.
The trirand grid that you linked to doesn't even get keyboard or mouse focus right. It doesn't even get row selection right.
If you think that's a good grid, I don't expect you to see anything remarkable about the grid I posted.
If you think that's a good grid, I don't expect you to see anything remarkable about the grid I posted.
The most remarkable thing about the grid you posted is that it won't run on my computer. In fact, it won't run on any of my computers.
Looking around my office, I gather it would run on about four or five computers out of the about 50 here.
Looking around my office, I gather it would run on about four or five computers out of the about 50 here.
Fine. Let's compare it to any native grid that runs on your preferred OS then.
Both of those work fine here, and there are a half dozen other jQuery grids available if you want to try them out.
You've obviously never used the Telerik components. If you want to build the thing in their demo the controls are fabulous. If you want to build anything else you'll suffer more than you can imagine. I've had the misfortune to use several revisions of the Telerik for ASP.NET controls, and the Telerik for Silverlight controls. The Silverlight controls were atrocious.
It won't even run on OS X so that's a pretty big plus for HTML UI components, given that modern web UI frameworks are all pretty reliably cross-browser.
FWIW, Silverlight does run on OS X[1]. The demo link above was for WPF. The Silverlight version is here: http://demos.telerik.com/silverlight/
[1] http://www.microsoft.com/getsilverlight/Get-Started/Install/...
[1] http://www.microsoft.com/getsilverlight/Get-Started/Install/...
This is exactly the problem. HTML/CSS/JS is disgusting to someone who knows the power of a good native SDK.
People who only do web dev just don't know what quality is.
People who only do web dev just don't know what quality is.
Quality is also your stuff running on anyone's computer, and not depending on a big company that has the power to kill your stuff and force you to rewrite it.
Sure. That's nice about HTML, but too bad you lose almost every other quality thing because of it.
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.
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.
an intranet is the sign of a lazy IT department. put that stuff up on the internet, let employees access the resources they need wherever they are, from whatever device they are using.
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.
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.
Not that simple. There are tons of rules and regulations businesses may have to follow. Some data may never leave company premises. Some data may never leave the room it exists.
if data can't leave the room and it's on your network, you are in violation of that policy whether you have an intranet or an internet.
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.
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.
We don't have anything like that here - we don't do top secret stuff - but, in that case, the machine wouldn't be on the network.
But why require your developers to learn another set of technologies? Much better IMHO to just have a good web development team who can make internal applications too.
I think most corporations already have people with C#/XAML skills.
The odds are much higher that they have some in-house web developers.
Oh, so everybody should just do HTML no matter what, from now on, for ever and ever, amen?
Nobody should ever invent a competing technology because HTML is good enough for you? Is that it?
Nobody should ever invent a competing technology because HTML is good enough for you? Is that it?
> Nobody should ever invent a competing technology
As long as this technology is easy and free for everyone to implement in compatible ways, yes, you can.
As long as this technology is easy and free for everyone to implement in compatible ways, yes, you can.
"You can" implies that you have some sort of say in the matter. Why should everyone have to implement technologies that are "easy and free" just because you say so?
Good point. You can, but you shouldn't. And I won't use it or encourage its use. In fact, I'll speak against it on every opportunity I have.
So you don't use any proprietary technology then? What kind of car do you drive?
Of course I do. But I avoid it whenever it's possible and active advocate for non-proprietary alternatives.
That's cool with me. I choose technology on quality alone, with regards to my use cases. I certainly don't tell people that they shouldn't use what they're using, I just give my opinions. People such as yourself are often telling me I shouldn't do this or that. I don't mind it, because I enjoy talking about technology and sharing my point of view. Some people just don't see it though.
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.
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.
It's unfortunate but it was inevitable. HTML 5 is definitely the future. Although, the ability to write an app using type-safe, object oriented code that can run on both the client and server was very compelling.
the Mary Jo Foley article this one loosely references is here: http://www.zdnet.com/blog/microsoft/will-there-be-a-silverli...
A tangent but why is "TheVerge" getting so much play on Techmeme's front page if it produces articles like this one?
What will Microsoft do for 3D on the web, then? They've said the won't implement WebGL and Silverlight 5 + XNA was supposedly their solution.
If I were a betting man, I would guess "build some new proprietary technology", but they may just go back to WebGL now that they are committing to HTML5.
I really do hope they decide to go with WebGL.
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.
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.
I have been working on a silverlight app for almost 2 years. We started in silverlight 2 and are now on silverlight 4. There have been a million twists and turns but our business demanded things that simply are not practical from HTML/JS.
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.
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.
They should've stuck with Silverlight as a rich javascript library (similar to v1), and used the Silverlight CoreCLR to power the javascript JIT in IE, providing a superior user and/or development experience compared to other [desktop] browsers.
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.
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.
they should have probably made this decision before starting the first release!
Wonder what will happen to NetFlix for web. Fallback to Flash I'm guessing...
They already have a HTML5 client, created for the PS3:
http://techblog.netflix.com/2010/12/why-we-choose-html5-for-...
http://techblog.netflix.com/2010/12/why-we-choose-html5-for-...
Are Netflix's streaming videos DRM'd? On a closed system like the PS3, an HTML5 video player might be possible, but how would they protect their video in a HTML5 video player on a desktop computer? DRM'd desktop video seems like a good opportunity for Flash and Silverlight since HTML5 is unlikely to offer might DRM support.
Just because your app is HTML5 doesn't mean you have to run it in a browser. Just like on phones, drop a WebView in and you're set. IIRC, Spotify actually uses Chromium in some capacity on their native client.
So what does this mean for Windows Phone 7? Will Silverlight eventually go away for it as well? Since the majority of WP7 apps are developed with Silverlight (i think?) what will replace it?
Good riddance! I spent the last 5 months at a gig working on a massive Silverlight 4 application. I've been a web guy forever, but I took this job thinking it would be good to learn how the other half lives. After experiencing the pain and drudgery of working with Silverlight, I couldn't be happier that it's going away.
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!
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!
Interesting... I as a Silverlight dev now learning JS/HTML/CSS would say the complete opposite. I find it very difficult to create similar layout functionality like DockPanel and friends. Any tips?
You know it's interesting that you're seeing lots of pain going the other way. I realized part of my issue with Silverlight was just how different it was from what I was used to. I don't like things I don't understand :) That being said, I did like the Stack Panel and the Dock Panel. I liked them because they worked more closely to the way HTML layout works. It was the Grid that I despised. The markup was tough to follow (putting Grid.Row="" and Grid.Column="" for each element inside the grid was stupid) and ultimately positioning in Silverlight was very much about absolute position and fixed dimensions.
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 :)
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 :)
Thanks.
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.
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.
I was a ruby on rails dev for about 3 years up until a year ago, when I got hired by Microsoft. I now work almost entirely on the XAML/C# stack. Honestly, I really like it. There are some very key improvements in the stack that I see over HTML/JS. Javascript is a great language for small and simple scripts, but for larger js-heavy applications it gets pretty hairy quick. Likewise, html is a fantastic markup language for webpages, but for embedded applications it's horrible.
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.
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.
I see your gripe with the REPL loop and binding but . . .
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.
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.
For one thing, with Prism, binding events to view model methods was a giant pain, specifically if you wanted to pass event args. I know I ended up having to write a number of attached properties to handle different event binding scenarios. With jQuery it's a cinch to handle user interaction. (I guess my major gripe in this case is with Prism, which is perhaps separate from SL).
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.
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.
XAML worse than HTML/CSS? What about the fun task of hacking your HTML/CSS app to look the same across browsers?
Wait, you're looking to Silverlight for cross OS/browser support? ha!