Top Ten Rising Web Technologies in 2010
In Highlights of web technology surveys, January 2011: Top 10 rising web technologies in 2010, Matthias Gelbmann posts a list of web technologies that were most frequently adopted by web sites in 2010. The results are based on absolute number of sites adding the technology rather than on percentage adoption. Web technologies on the list include UTF-8, Google Analytics, and XHTML.
It was the XHTML adoption that I found to be particularly interesting. The quote that really got me thinking was a quote addressing the current trend of widening XHTML use: "This trend could be reversed in 2011 by the movement towards HTML5." HTML5 brings the XHTML and HTML specifications back together under a single specification (its single sentence description is "A vocabulary and associated APIs for HTML and XHTML"), but it is interesting to consider that there is potential for this combined HTML/XHTML specification to actually reduce the number of sites using XHTML.
The history of HTML/XHTML is full of political intrigue. The HTML5 specification attempts to gather everyone back into the fold. The specification overview (see HTML versus XHTML section) currently describes when the HTML5 "concrete syntax" is expected to be used and when XHTML "concrete syntax" is expected to be used in conjunction with HTML5:
The first such concrete syntax is the HTML syntax. This is the format suggested for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with an HTML MIME type, such as text/html, then it will be processed as an HTML document by Web browsers. This specification defines version 5 of the HTML syntax, known as "HTML5".
The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5 of the XHTML syntax, known as "XHTML5".
There are several things worth highlighting here. First, applying XHTML continues to be more than a matter of simply using XML grammar and maintaining well-formed XML. XHTML-ness is really determined by the use an on XML MIME type (typically application/xhtml+xml). Second, I found it interesting that the statement is made that HTML5 (as opposed to XHTML5) is "the format suggested for most authors."
It will be interesting to see if HTML5 adoption does indeed reduce the popularity and use of XHTML.
What Makes Technologies Hip?
Su-Shee's post And suddenly, you're hip makes some interesting observations. The author looks at how certain strategies and tactics have made certain languages and software development tools popular. A differentiation is made between concepts like recognition and publicity versus real user base. An example used in this post is vim and the author maintains that there has been renewed interest in vim recently because of certain events and actions in the vim community. I'm a fan of vim. I blogged on Faithful Old Development Tools and mentioned using vi, but the truth is that I actually use vim much of the time.
Besides the author's observations about what types of things can make a language or tool be perceived as cooler, more hip, or more exciting, I found it interesting that this thinking was applied to Perl. For me, there are some similarities, but there are also some differences. Both Perl and vim (or vi more strictly) are available on practically any Linux-based system I might ever encounter. I have used both vim (vi) and Perl throughout my software development career. All of this being stated, however, I can still say that while I enjoy vim, I generally avoid Perl when I can.
Java IDEs have come a long way and they are very powerful. I use them for most of my Java development. There are times, however, when I need the conciseness and different type of power of vim and I use it then. I know when each type of editor works best for me and use them when appropriate. The best of both worlds is obtained when I can have a vi emulator on my Java IDE.
One of my issues with Perl is that although most of us have had to dabble in it from time to time, it is still very difficult to read anyone else's Perl code. There are too many ways to do the same thing and we all seem to choose a different way. I don't even like to read my own Perl too far out from when I wrote it and I certainly don't want to read the other person's Perl. If Java is the "write once run anywhere" language, Perl (for me) is the "write once" language (hope you never need to return to maintain it).
I think there are times when a scripting language works best and times when I want more of a full-fledged production language. The problem is that Perl is never my first choice for either. For development of applications, I prefer language such as Java and C#. For scripting, I prefer Ruby or Groovy. I have not done much with Python, but my guess is that I'd prefer it over Perl as well.
My general avoidance of Perl is a matter of personal taste gained from experience with it and with alternatives. I don't think there's much the Perl community can do, short of overhauling the language, to change my mind. That being stated, I actually agree with most of the author's sentiments regarding what makes a technology appear "cool." It's just that in my case, it's difficult to imagine these same tactics having the same degree of positive effect for my perception of Perl.
I expect that I'll be using Perl for years to come. There's just too much of it out there to think otherwise. I don't see myself choosing to start greenfield scripting with Perl. The author also implied (to me at least) that the impact and influence of Ruby might arguably be even greater than its actual deployment base. Perl has had both: it has been heavily deployed and has influenced newer scripting languages. The modern scripting languages have, in my opinion, taken the best of Perl and left some of its warts behind.
Putting my natural reaction to Perl aside, I also appreciate the author's delineation of the types of strategies that can make a language or framework or tool more likely to be used and discussed. The author outlines strategies such as creating screen casts, providing more beginning-level documentation, and "confessional blog posts."
Even if you don't use Perl, hope to never use Perl, and don't care what the Perl community does to make Perl more popular, you still may find this post interesting. It's a reminder of how easily perception can be formed if enough evangelists keep pounding the message and presenting it in appropriate and mixed ways.
HTML5 Does Not Mean the Death of Silverlight
There are all types of posts claiming Java is Dead or Flash is Dead or Silverlight is Dead. Of course, these are usually the post author's hope rather than reality. Dan Wahlin's post Silverlight is Dead, the Moon is Made of Cheese, and HTML 5 is Ready for Prime Time does a nice job of explaining the upside of HTML5 while also injecting some reality into the HTML5 hype. He explains why he both plans to invest time in learning and using HTML5, but also plans to continue using Silverlight. Many of the same arguments can be used to understand that although HTML5 has much promise, technologies such as Flash/Flex or even Java on the web are not going away anytime soon.
It is easy to get caught up in the HTML5 wave of enthusiasm. There is much to be excited about and the perception tactics discussed earlier in this post are being used in full press. However, one simply needs to use most of the HTML5 features across multiple browsers to realize that HTML5 support is still wanting. There is also the now well-known statement from a W3C official that HTML5 is not ready for primetime. There are also numerous online posts explaining why HTML5 won't be the end of Flash anytime soon.
Other recent articles on the HTML5 subject range from the ultra positive Why HTML5 Will Really Matter in 2011 to the negative ("HTML5 is a scam!") lies and facts post.
DZone's Refcard on REST
DZone has issued a new (#129) Refcard in its popular Refcardz series. This newest edition is called REST: Foundations of RESTful Architecture and focuses on principles behind the Representational State Transfer architectural style.
The "REST: Foundations of RESTful Architecture" refcard is written by Brian Sletten and covers topics such as the basics of REST, REST frameworks, REST definitions, REST resources (in multiple senses), and the Richardson Maturity Model.
Understanding How Java Debug Works
Carlo Scarioni's post Understanding How Java Debug Works is the type of post I often like to write in that he focuses on details at a lower level than many of us traditionally think. Understanding things at a deeper level than that which we use them can be of tremendous value at times. For example, most of us use calculators for a wide variety of mathematical operations, but it is always better to understand the math behind what the calculator is doing.
Java Concurrency Bug Patterns for Multicore Systems
I believe that concurrent programming is the "next big thing" in software development. The transition to "thinking in threading" is going to be similar to the transition from procedural programming to "thinking in objects." Because of this, I like to read as much as I have time for related to Java concurrency support and best practices. The IBM developerWorks article Java Concurrency Bug Patterns for Multicore Systems is informative and is focused on six "bug patterns" that are perhaps less well known than others, but which "do show up frequently in real Java applications."
No comments:
Post a Comment