No Hard Feelings, Silverlight

by Jon Davis 13. September 2010 00:26

I very rarely just hard-link to someone else’s blog from my blog just because I liked an article’s content. But this guy has “seen the light” in so close to the same way that I did that I can’t help myself.

He writes,

Now, some of us that have been doing web development for some time, and have suffered the pains of cross-browser compatibility, JavaScript (the copy/paste snippet joke language), CSS (the “crap, I moved a DIV and all hell’s broken loose” language), have also seen the advances in these fields. Not to sound repetitive, but jQuery for example has not not only made JavaScript fun, but opened our eyes in seeing how powerful this so called “joke” language actually is. CSS has become easy. I actually really dug into CSS after learning jQuery and realized how stupid I was to ignore it for so long.


Some say “Sure, I can also program in Assembly and not use C#”, to which I reply "Open your eyes". Using HTML, jQuery and CSS is by no means less productive or harder to do than learning XAML, MVVM and asynchronous programming.

I’ve learned to love strongly typed languages, and I greatly admire Silverlight (as I do Flash, but Silverlight is spoken in my native tongue, C#). But I am not so hard-nosed as to think that the dynamic and “simpleton” language that Javascript is is not immensely powerful, productive and even often adequate on its own. We sometimes choose our priorities based on our habits and interests, not based on actual output and facts, and this is often because our view of the facts is tainted by the prior experiences of the earlier decades (late 90s and early 2000s). And we choose not to examine the realities of changing times because we’ve either a) become complacent with our strongly-typed languages, and/or b) our prior biases hold us back. Or perhaps c) our over-experience in strongly-typed languages has made our egos too smug to consider that the value of functional languages versus strongly typed languages is not a black vs. white, improper vs. proper matter.

Much has changed in the past two years. Two years ago, I said the same thing—2007 to 2008 saw the widespread adoption of major game-changing Javascript libraries like Prototype+Scriptaculous, MooTools, and, yes, jQuery, which is when client-side development became almost as interesting as it was in the IE4 days. But in 2009-2010 the changes were far more significant. Proposed overhauls to the web platform from WHATWG broke the web browser from its 1999-esque chains with rich RIA capabilities, and the plug-in model thus became antiquated.

None of this is to say that Silverlight isn’t the best RIA platform since, well, Flash. But then again, “best” is in the eye of the beholder. Five years ago, as Microsoft was laying out the game plan for WPF and then Silverlight, it was fairly obvious that that team couldn’t have been more on the right track. Silverlight’s innovation and its evolution and Microsoft’s support of Silverlight have been amazing, arguably even close to perfect.

But there was an error made by Microsoft, and that error was made several years ago, when Microsoft declared that they would no longer innovate in Internet Explorer itself. (This is a particularly stupid move business-wise for Microsoft since nothing would make the Windows platform stronger than a rock-solid web browser that runs only on Windows and does more than what the other browsers do.) I’ve dug this error up multiple times before, but it keeps coming back to haunt Microsoft. They chose to sit on their laurels because big corporations kept IE6 installed on Windows XP on corporate employees’ workstations and never upgraded nor migrated.

Silverlight does what it attempts to do very well, the same thing that Flash and Java applets back in the day used to do, and that is to be a workaround to the limitations of the web browser. But the web has caught up with the demand, and not only Chrome but also Opera, Safari, and Firefox can run most of the projects at It’s possible that Internet Explorer 9, with its promises of partial HTML 5 support, will be able to run a project or two over there, which is great. The Internet Explorer team is back in gear, catching up to modern standards, more or less, and even throwing an innovation in here or there, as with DirectX rendering. But the point of all this is that Silverlight is here to scratch an itch that already healed. That’s a good thing. Silverlight is wonderful, and it’s still useful for multicast video broadcasts and for line-of-business moderately secure web UIs where it should be more difficult for the user to view source or to select text and copy and paste it somewhere else. Some corporations need that, I’m sure. I also need Silverlight or Flash for webcam input support. Silverlight also fills the need for RIAs written in C# for those developers that refuse to master Javascript because they still see it as a simple language that one simply cannot be productive in. But those developers are wrong. For the bulk of the web, sorry, no hard feelings Silverlight, but this other thing over here seems to have snuck up behind you and fixed the problem you were hired to solve. HTML does RIA. Thanks, though, and nice scrollbars. *wink*

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


The File Hierarchy Standard

by Jon Davis 5. September 2010 00:00

I stumbled upon this while trying to figure out where to copy a Mono app I was deploying to Linux. I’ve always been confused about the *nix file system hierarchy even though they look familiar across the board between Linux, Solaris, Mac, et al. I always thought the “standard” is so ugly and even stupid, and I used that as a reason for dissing Linux but whatever. My negativity dissipates rather quickly when I understand the basics in the first place.

From Raphink:

The standard for these issues is the File Hierarchy Standard. It's a rather big document. Basically (and very roughly), the standard paths on Linux are:

  • /bin & /sbin are for vital programs for the OS, sbin being for administrators only ;
  • /usr/bin & /usr/sbin are for not vital programs, sbin being for administrators only ;
  • /var is for living data for programs. It can be cache data, spool data, temporary data (unless it's in/tmp, which is wiped at every reboot), etc. ;
  • /usr/local is for locally installed programs. Typically, it hosts programs that follow the standards but were not packaged for the OS, but rather installed manually by the administrator (using for example ./configure && make && make install) as well as administrator scripts ;
  • /opt is for programs that are not packaged and don't follow the standards. You'd just put all the libraries there together with the program. It's often a quick & dirty solution, but it can also be used for programs that are made by yourself and for which you wish to have a specific path. You can make your own path (e.g. /opt/yourcompany) within it, and in this case you are encouraged to register it as part of the standard paths ;
  • /etc should not contain programs, but rather configurations.

If your programs are specific to the services provided by the service, /srv can also be a good location for them. For example, I prefer to use /srv/www for websites rather than /var/www to make sure the directory will only contain data I added myself, and nothing that comes from software packages.

There are some differences between distributions. For example, RedHat systems use libexecdirectories when Debian/Ubuntu systems don't.

The FHS is mostly used by Linux distributions (I actually don't know any other OS that really complies to it). Other Unix systems don't follow it. For example, BSD systems tend to use /usr/local for packaged programs, which is not the case for Linux. Solaris has very different standard paths.

I strongly encourage you to read the FHS document I linked above if you wish to know more about this.

Nice cheat sheet. I might print this out until I can manage to memorize it.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5



Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar