Archive for the ‘html5’ Category
The Web as we know it have been born and matured on computers, but as it turns out now, computers no longer have dominance in it. According to a recent report by analyst Mary Meeker, mobile devices running iOS and Android now account for 45 percent of browsing, compared to just 35 percent for Windows machines. Moreover, Android and iOS have essentially achieved their share in just five years and their share is getting tremendously larger.
According to some forecasts their worldwide number of mobile devices users should overtake the worldwide number of PC users next year. If forecasts come true, this shift will not only continue, but accelerate. Based on data from Morgan Stanley, Meeker estimates roughly 2.9 billion people around the world will be using smartphones and tablets by 2015.
What does it mean now that more people are accessing the Web through tablets and smartphones rather than laptops and desktops? And is it really a big deal? Anyway, Internet is intended to be accessed from anywhere and thus from any device. Well, it is quite a change at least in terms most people consider the Web and how it gradually adapts to be used on mobile devices.
As mobile devices take over, the use of today’s desktop browsers like Internet Explorer, Chrome, Firefox, and Safari will decline. Mobile browsers are already very capable and will increasingly adopt HTML5 and leading-edge Web technologies. As mobile devices naturally have less screen area, the sites need to function more like mobile apps and less like collections of links. So the sites are likely to look like apps.
Apps may rule
Native apps for smartphones and tablets almost always surpass websites designed for mobile devices because they can tap into devices’ native capabilities for a more responsive and seamless experience. This is most likely to change in the nearest future – most experts agree HTML5 is eventually the way of the future. This is already the status quo in social gaming: for example Angry Birds and Words with Friends. Some services won’t be available at all to traditional PCs — they won’t be worth developers’ time.
Less information at once
Web sites and publishers will no longer be able to display everything new for users and hoping something will catch the user’s eye. Smaller screens and lower information density means sites will need to adjust to user preferences and profiles to customize the information they present. Increasingly, the Internet will become unusable unless sites believe they know who you are. Some services will handle these tasks themselves, but the most likely contenders for supplying digital identity credentials are Facebook, Google, Amazon, Apple, Twitter, and mobile carriers.
Sharing by default
In a mobile-focused Internet, anonymity becomes rare. Virtually every mobile device can be definitively associated with a single person (or small group of people). Defaults to share information and experiences with social circles and followers will be increasingly common, along with increasing reliance on disclosure of personal information (like location, status, and activities, and social connections) to drive key functionality. As the Internet re-orients around mobile, opting out of sharing will increasingly mean opting out of the Internet.
Emphasis on destination
Internet-based sites and services will increasingly function as a combination of content and functionality reluctant to link out to other sites or drive traffic (and potential advertising revenue) elsewhere. These have long been factors in many sites’ designs but mobile devices amplify these considerations by making traditional Web navigation awkward and difficult. Still URLs are not going to die – people will still send links to their friends and Web search will remain most users primary means of finding information online.
Going light weight
As people rely on mobile, cloud, and broadband services, the necessity to do things like commute, store large volumes of records or media, or patronize physical businesses will decline. Businesses won’t need to save years of invoices, statements, and paperwork in file boxes and storage facilities – cloud storage comes as their rescue. Banks will become purely virtual institutions consumers deal with online via their phones. Distance learning and collaborative tools will let students take their coursework with them anywhere — and eliminate the need to worry about reselling enormous textbooks.
Going mobile is an obvious trend today. Experts envisage that nearly every service, business, and person who wants to use the Internet will be thinking mobile first and PC second, if they think about PCs at all. Do you agree? And what other related changes can you imagine?
Many thanks for sharing your thoughts
The IT world is constantly forging ahead. There already exist several dozens of programming languages and software technologies. At the same time to choose the right thing for a specific project is not an easy thing to do.
Every technology has its own advantages and disadvantages. Hence, if you want to choose a certain implementation, which will be effective for both-development and its further support, you need to consider following issues: project scalability, its tasks and timeframes.
Large-scale projects (high load systems)
For big and high load systems (more than 3000 queries per sec, beginning from 10000 database tables) it is necessary to choose the technologies very comprehensively, as it will influence the general project productivity and security.
There are 4 suitable languages for the backend: Java, NodeJS, PHP and ASP. Though it’s better to use Java, as it allows achieving effective work speed, and gives the possibility to support hyperthreading and refacoring. Moreover, Java is one of the best fit from the point of view of development speed – there are plenty of handy frameworks.
It is better to remember, that NodeJS is a bit difficult to use when it comes to complicated calculations. Nevertheless, it helps to provide an easy project scalability and processing speed.
When it comes to high load systems, one should remember about extensibility, because it is one of the problem developers face to most often. Hence, it is necessary to think over the work layout with a database in details. For big projects it is better to put away relational databases, and turn attention to non-relational models, such as MongoDB и Redis. It is possible to use CouchDB as well.
It is relational bases that place a limit on the projects and do not give an opportunity to be extended easily. Non-relational models have a completely different structure: instead of SQL-queries API are used.
While working on middle-scale projects (1000-3000 queries per sec, 2000-10000 database tables), i.e. not too load, but not home pages either, it is possible to use Java and PHP. In this case NodeJS will not give such attractive results as in high load projects.
Databases can be both relational and non-relational. Everything depends on the further project development. If it is planned to grow rapidly, it is better to use non-relational models MongoDB or Redis. If a too big scalability is not required, Oracle will perfectly fit. The point is that in spite of being relational, Oracle is used in many projects that have a potential to scalability. At the same time there no extension problem emerge, even if several servers are used.
When the question is about small projects (less than 1000 queries per sec, 2000 databases), it is essential to put away all the complicated things, that present in high load systems. Consequently, PHP, Ruby on the Rails (this framework allows fast development), Erlang are best for development here. No doubt Java can fit as well, though it would be much faster and easier to use PHP or Ruby.
Anyway, apart from the project scalability it is essential to consider its potential. The reason is that the problems start after the project growth, when developers face to inability of an adequate project transfer to other servers and workload distribution. Besides, it is important to keep in mind the project tasks. It is highly possible to turn out, that what is popular today will not be effective for a specific project.
You know that my opinion is not the ultimate truth I would be glad to read about your experience of using languages, databases while working on different projects!
Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a “write one, run many” solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route.
1. We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device’s ecosystem, e.g. for Android, this would be features like widgets and notifications. In terms of app experience, native apps can do more.
2. It’s true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web skills are, if your app is stuck in a sandbox with no camera API, it won’t be taking snaps anytime soon! Making a hybrid – native plus web – app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn’t be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it’s possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.
Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it’s not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.
Native is a fast-moving target, but the web is closing the gap.
3. Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.
What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it’s no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation. On the other hand Web is often easier to develop, especially if targeting multiple devices.
4. One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a “long hold” (keep touching an element for several seconds)? Platforms have standard idioms for such things, and you can’t satisfy them all with a single HTML5 app.
Furthermore, platform look-and-feel is orchestrated by the platform’s native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel “for free” just by using the native toolkit.
5. App distribution mechanisms, like Android’s Market and Apple’s App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you’ve done your job right, the glowing ratings and comments will convince users to hit the all-important install button.
It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.