Long-term technology trends developers need to know

A lire sur:  http://www.techrepublic.com/blog/programming-and-development/long-term-technology-trends-developers-need-to-know/6665

By Justin James, April 11, 2013, 8:01 PM PDT

Takeaway: Justin James highlights some factors developers should consider when making tech decisions about languages, Web Services, databases, and more.

The landscape of technologies that developers deal with is constantly shifting. Here are some of the most important long-term trends you need to be aware of and should take into account when you make technology decisions.

Languages

The .NET and Java ecosystems are taking a lot of ideas from Ruby, JavaScript, Python, and other similar systems — and for good reason. Those open source systems are moving much faster because of the way they are governed. A lot of the best ideas in development right now are coming from those projects. Does this mean that .NET and Java are headed for the scrap heap? No way. Those languages will continue to be thought leaders, and a small minority of developers will work with them and influence the greater community.
These languages will never go into a strong mainstream position because they lack the features and toolsets that allow companies with anyone other than “A players” to feel comfortable with them. Companies recognize there is a fair amount of mediocre talent in their ranks, and these languages depend upon “process” (like unit testing) to deliver good results, especially when working in a team, and companies can’t trust their teams to follow process. So instead, they need to sledgehammer them with tools that enforce artificial restrictions. Everything from strong typing to centralized version control is oriented around forcing bad developers to do the things good developers are able to do on their own. I do not see this changing any time soon.
Unless you are in an environment that is friendly to systems like Python and Ruby, you should expect to use .NET and Java for the long term.

Web Services

Web Services will continue to make progress as a tool for real work. SOAP and REST have positive and negative attributes, and neither is the “final answer” to the Web Service protocol situation. It seems likely that at some point a standard will come out that will combine the best attributes of SOAP and REST. Until then, you need to support both most likely, because REST and JSON are too useful to applications that deal with a Web browser to ignore, and SOAP has too many enterprise features and too much enterprise adoption to wish it away.

Databases

The NoSQL movement has made some advances, but at the end of the day, traditional relational database management systems (RDBMSs) make too much sense in far too many scenarios for NoSQL to replace them for most developers. Is there an opportunity for some developers to cut the cord from RDBMSs? Absolutely. But those developers are going to be working on very specific applications that lend themselves well to the NoSQL model.
I am glad that excellent NoSQL options exist, but I am doubtful they will be able to capture a lot of mindshare any time soon.

Front-end technology

HTML is here to stay. HTML is not a great format at a technical level for a lot of the work folks are doing with it, though it has matured to a very usable point. In the last several years (thanks to jQuery and similar frameworks), HTML has surpassed the UI potential of native applications at the price point of “free.” Yes, there are ways to do better than HTML with native applications, but not if you are looking only at free components.
Once you get over your sense of technical correctness (it took me a long time), HTML is a perfectly usable system for creating applications. And while I cannot point out any individual native system as “better” in one way or the other, given a choice between HTML’s compromises and learning three, four, or more front-end systems, most developers will choose HTML.
It takes a big budget to hire enough folks to cover the spectrum of Windows (now Classic and Modern), Android, iOS, Mac, and Web. Good luck finding a non-HTML tool that can handle all of those scenarios.

Mobile development

I am grateful I didn’t bet my career on mobile development, because I don’t know what tomorrow holds. Let’s look at the list of mobile players in the last 15 years, in roughly chronological order:

• Palm
• RIM/BlackBerry
• Microsoft (Windows CE)
• Nokia/Symbian
• Microsoft (Windows Mobile)
• Apple
• Google/Android
• Amazon/Android
• Samsung/Android
• Microsoft (Windows 8, Windows Phone 8)

I include Android three times because Amazon and Samsung are trying to carve out their own Android ecosystem. Microsoft makes the list three times with different iterations of its mobile operating systems. The mobile market is a merciless meat grinder, a never-ending battle for vendors, consumers, and developers. From month to month, you cannot count on a device being available for sale, thanks to legal injunctions.
There are no obvious trends in mobile other than “progress.” When Apple launched the iPhone, it looked like tightly controlled ecosystems made perfect sense. Now Android is cleaning house with a pretty open ecosystem. There is no rhyme or reason to the mobile market, and it is tough waters for developers to navigate.
J.Ja