Deeply understand the current status of HTML5 development in mobile development

"We're writing our next set of mobile products in HTML5." "Yeah, a lot of people are playing with Appcelerator these days, and I'm playing with it too." "Well, that's not the kind of HTML5 product I'm talking about."

I've been having a lot of similar conversations lately, probably because I'm developing an HTML5 application. Just like "AJAX" in 2005, the term "HTML5" has not yet been clearly defined. Before it was determined what advantages this new technology had, it had already been used everywhere and even put into operation.

If you work for a company controlled by managers who are keen on new technology, if you're lucky, the comic character Mr. Dilbert might be very willing to sit in the cubicle next to you.

Two views

When people discuss HTML5 on mobile devices, they usually have two different opinions.

From a perceptual point of view, the rendering process of HTML5 technology is mainly performed by browsers, applications with embedded HTML5 parsers (such as PhoneGap), applications that support bookmark opening, or mobile phone products (iPhone and iPad). The advantage of this technology is that existing web page designs can be reused, making it easier for web developers to get started. At the same time, the products have higher quality and are more suitable for multi-platform products. It is also easier to debug and fix errors, and version updates will be faster. The advantage is its functionality. If you use an embedded architecture like PhoneGap, you will have fewer problems. The disadvantage is its performance, which is also the biggest challenge facing HTML5 technology.

From a rational point of view, HTML5 technology is to use the JavaScript engine to directly control local functions and change the browser components on mobile devices. The performance issues on HTML5 applications are more controlled by HTML/CSS rendering technology rather than JavaScript parsing. If used correctly, HTML5 technology can undoubtedly give you a lot of new performance effects. Current examples of HTML5 technologies include Appcelerator Titanium, Mobage/ngcore, Game Closure, and PhobosLabs.

Node.js Toolkit

Taking the PhobosLabs project as an example, this project was completed using the JavaScriptCore component of WebKit, using OpenGL to render the interface on the device side, and using the HTML5 canvas component API for development. This means that a developer can develop and test his HTML5 game in a desktop browser with good support for canvas, and when he opens the game in a browser on a mobile device, the performance will be equally good (or even better). The effect of developing with HTML5 is very similar to that of developing with the Node.js toolkit. When using Node.js, you only need to enable the JavaScript engine, and you only need to add the Node.js components you need to use to your application.

Appcelerator's Titanium elaborates on the concept of HTML5 technology and presents us with a complete abstraction layer of UI tools, which makes it possible to be applied to generate other game products. This means that an HTML5 application developer can create a button through Appcelerator's JavaScript UI library, and Appcelerator's internal logic will convert this button into a native interface button for iOS. We can control the native buttons on the interface through JavaScript. In theory, developers don't need to write a single line of Objective-C code.

HTML5 technology has its advantages. When you are still using JavaScript to write code, you can say goodbye to those annoying HTML/CSS layout logic and style declarations. You can also say goodbye to those great debugging tools. But this technology also has its downsides. For example, the HTML5 game API Mobage has some minor issues. The canvas component can be displayed smoothly on a relatively small screen, but if the screen becomes slightly larger, as in the Appcelerator example, you also need to consider the additional complexity of the interface layer when debugging. There are a lot of negative reviews of Appcelerator out there, and if you keep the above points in mind, then those negative reviews are actually understandable.

The problem is still in the browser

The first difficulty in developing a complete HTML5 mobile application is that it runs too slowly. The second biggest problem is the very stupid tool constraints. Many components have some vulnerabilities in different browsers, such as the navigation component of jQuery Mobile and the innerHTML component of iOS. So you need to reduce functions to avoid vulnerabilities, or you are willing to spend some time to fix these vulnerabilities.

You can do an experiment yourself. When you use only one or two interface libraries in an iOS application, plus a small amount of JavaScript code you wrote yourself, without more JavaScript libraries, you will find that this HTML5 application runs smoothly and completely, but has no functions. PhoneGap iOS projects only take 1 to 2 seconds to be published and run on iPhone 3GS. This fact alone can tell you that even the most basic HTML5 applications run really smoothly. So, when you find that some operations in your HTML5 application take 10-15 seconds, or it takes 15 seconds to load the entire program, it is all due to some JavaScript interface libraries.

Two representative UI libraries

An HTML5 mobile application programmer usually needs only two things: the first is the grafting layer between the native platform and the web interface; the second is the mobile UI library.

PhoneGap has gradually become the default grafting layer choice in recent years. It allows HTML5 applications to call the camera of mobile devices, access mobile phone contacts, and read and write files through JavaScript. The most popular mobile UI libraries include jQuery Mobile and Sencha Touch.

jQuery Mobile was created only last year, so it is very new and obviously not very mature. jQuery Mobile's navigation bar component is terrible. It's significantly slower than native paging when turning pages, and if you don't refresh the browser, you can't increment the list content. When tested on a PC desktop platform, its CPU usage was also very high (the version was alpha 4 of jQuery Mobile). My project uses it mainly because it is relatively simple (easier to crack), and because this library is built on jQuery, it is easy for any experienced web programmer to get started.

Sencha Touch is said to be more mature and faster than jQuery Mobile. But when I see things of high complexity, I don’t automatically hate them. Because my subconscious mind tells me that there are many features that I will never use, but I force these extra things to be loaded into my app, which makes the overall performance of my app much worse. Although I could be wrong, the most powerful mobile app on the PhoneGap app page is IGN Dominate, it runs very smoothly and it is built on Sencha Touch, but I am sure they must have spent a lot of time optimizing this product.

Debugging and Modification

When developing HTML5 applications, many people may have overlooked the fact that debugging or modifying an HTML5 application is very simple. Any developer who has worked on a large HTML5 development project can tell you that debugging and maintenance can take up 80% of the project lifecycle, if not more. This means that when you hear a development tool claiming that it can develop a chat application in 15 minutes, it may only allow you to solve 20% of the work in 15 minutes. For the remaining 80%, you may have to spend more than 3 times the effort to complete it.

There are some issues when debugging HTML5 mobile apps because the console log cannot be printed out. So, if there is a vulnerability or error in the JavaScript code, you need to alert() the error, otherwise you may not be able to find it. PhoneGap fixes this problem. It can print the console debugging log through XCode's console, but the functionality is still very limited.

The most effective solution at present is weinre. Despite all the bugs, it can run. With it, you can also debug the UI of your mobile application at breakpoints. Weinre is a web inspector based on WebKit. Its debugging tool background obtains and replaces debugging code through a remote server. Two or three weeks ago I did some research on the web inspector code and I found that it was not really that hard to convert it into a remote debugger. Weinre's development will progress more rapidly in the coming months, and someone may even develop a replacement for it. Let's wait and see.

In the next few years, debugging tools for HTML5 technology in mobile application development will undoubtedly become more important, as it can solve 80% of the workload of most developers. Do you want to change your interface design using Objective-C? Edit, recompile, and run. Repeat these three steps until you are satisfied. If there are many recompilation steps, this may take a day. Use HTML5 technology to achieve it? Edit some CSS properties with weinre and test them. You don’t even have to close the app to continue debugging. To a certain extent, you can also debug your HTML5 mobile app in a desktop browser. But believe me, your app may end up with a bunch of vulnerabilities on mobile devices, so you have to use weinre.

Unfortunately, people often praise a toolkit or feature, but you rarely hear anyone praise a debugging tool as being great. So I guess even though it is the most commonly used tool by HTML5 mobile programmers, we rarely hear it discussed.

Summary: Current situation

Although this article is a bit long, I still have to summarize it:

1. There are only two ways to develop HTML5 applications on mobile devices. Either use the HTML5 syntax or use only the JavaScript engine.

2. The construction method of JavaScript engine makes it possible to make mobile web games. Since the interface layer is complex, I have reserved a UI toolkit to use.

3. Pure HTML5 mobile apps run slowly and are full of errors, but the effect will be better after optimization. Although not many people are willing to do such optimization, you can still try it.

4. The biggest advantage of HTML5 mobile applications is that they can be debugged and modified directly on the web page. Native application developers may need to spend a lot of effort to achieve the effect of HTML5, constantly repeating coding, debugging and running, which is a problem they have to solve first.

5. Yes, the HTML5 port is pretty straightforward, but I'm assuming everyone will make this an automated operation.

The above in-depth understanding of the development status of HTML5 in mobile development is all the content that the editor shares with you. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM.