The similarities and differences between Web front-end development and iOS terminal development

[[125065]]

language

As user-oriented programs, the front-end and the terminal have a common feature: they need to rely on the operating environment of the user's machine, so there is basically no choice of development language. Unlike the back-end, you can use whatever you want. iOS can only use Objective-C, and the front-end can only use JavaScript. Of course, iOS can also use RubyMotion, and the front-end can also use GWT/CoffieScript, but they are not mainstream and few people use them. If they do, it will cause a lot of trouble.

There is an interesting contrast between the two: the naming styles of variables and methods are exactly opposite. Apple has always advocated user experience, and writing code is no exception. Program names are all named in full English and as detailed as possible, so that you can know what the variable and method name is by looking at the variable and method name, such as application:didFinishLaunchingWithOptions:. And because js has to be downloaded from the Internet every time, it is necessary to try to reduce the code size, so variable and method names are abbreviated as much as possible. In fact, there are code compression tools. No matter how long the variable name is, the final online effect is the same, but everyone is also used to using short names. For example, the application:didFinishLaunchingWithOptions: method of objc mentioned above is usually named: $() in js.

Both objc and js are dynamic languages, and they are quite similar in use, but objc is compiled, fast, and many errors can be found during the compilation process, while js is interpreted, and its performance depends on the interpretation engine. Even under the powerful v8 engine, its performance cannot catch up with compiled languages. The language is too dynamic, and variables have no types at all. It is fun to write, but a little bit difficult to debug. I always feel that js is light, flexible, uninhibited, and full of various tricks, while objc is quite standard, not as serious as c++ java, and not as flexible as js.

Threads

Front-end development hardly needs the concept of threads. The browser implementation of HTML and CSS parsing and rendering of the page may not be in the same thread as js, but all js codes are only executed on one thread and will not be executed concurrently, so there is no need to consider various concurrent programming issues. In the new JS feature, worker tasks can be created. Such tasks can be executed in parallel on another thread, but since not all browsers support it, the standards for data transmission between different threads are different, and there are few usage scenarios, it seems that they are not used on a large scale. For tasks such as database operations/sending network requests, they are executed in threads different from js code execution, but these are managed by the browser, and the front-end does not need to care about or affect these threads. It only needs to receive event callbacks and does not need to deal with any concurrency issues.

Terminal development requires extensive use of multithreading. iOS has a main thread, and UI rendering is all done in this thread. Other time-consuming logic or database IO/network requests need to be executed in separate threads, otherwise they will take up the time of the main thread, causing the interface to be unable to respond to user interaction events, or slow rendering causing scrolling to freeze. The program logic is distributed in multiple threads, and it is necessary to handle problems such as data inconsistency/timing disorder that may be caused by the concurrent execution of various codes. Concurrency also makes some bugs difficult to troubleshoot, and you will fall into the pit if you are not careful. It is necessary to use some queues/locks to ensure the execution order of the program. iOS provides a set of multithreading management methods GCD, which has encapsulated threads and queues to be very simple, easy to use and powerful, which is much better than other terminals or backgrounds, but it still takes a lot of effort to deal with multithreading issues.

storage

Terminal development requires a lot of data storage logic. Mobile APP is not like a browser. When a user opens a browser, he must be connected to the Internet. However, when opening an APP, he may be offline or in a mobile GPRS with extremely poor network conditions. Therefore, the data requested previously must be saved. After saving the data, it is necessary to synchronize with the latest data on the server. If the full synchronization data volume is too large and the data consumption is slow, incremental synchronization is required. It is necessary to work with the server to develop a plan to return incremental data and handle the problem of data consistency between the client and the server. When the data storage volume is large and the structure is complex, it is also necessary to make good use of limited memory for cache and optimize the performance of various storage queries.

The front end rarely needs storage on the desktop, unless it is a Single Page App. Without storage, there is no need for a series of data updates. The data is retrieved from the backend and displayed directly on the page. Even if Weibo can continuously load more data on the page, the data only exists in memory and will not be persistently stored. Because the desktop network speed is stable and traffic is not counted, all data can be directly obtained from the backend, and the client does not need to have another set of storage. Mobile web applications that are made to look like native apps are the same as terminal development. Data is also saved to SQLite, and the storage logic and problems to be handled are similar.

frame

In terms of third-party frameworks, Web front-end and iOS development are completely opposite. The Web is natively weak but very open, allowing a large number of third-party frameworks and libraries to show their strength, while iOS is natively powerful but very closed, resulting in little room for third-party frameworks to survive.

At first, browsers were designed only for content-based web pages, and js was just a scripting language that could add some small special effects to this web page. It could not keep up with the development in the era of Web applications, and needed a lot of third-party libraries and frameworks to assist. In addition, front-end development is a completely open field, which led to the proliferation of libraries and frameworks. In the early days, most libraries focused on encapsulating DOM operations, and everyone kept reinventing the wheel of DOM operation basic libraries. After a period of contention among a hundred schools of thought, jQuery became the only one. Among the websites that use libraries, more than 90% use jq, which has almost become a standard basic library. Later, everyone no longer reinvented the wheel of this basic library, and there were more frameworks for code organization and front-end architecture, such as require.js, which helps modularize projects, and MVC frameworks backbone/angular.js.

Apple has provided a complete development framework, Cocoa, for iOS development. This framework has been upgraded, optimized and improved in each generation of the system. The development model has also been finalized. There is not much room for third-party frameworks to survive. A large number of popular open source projects are some common components and libraries, such as the network request library AFNetworking and the database operation library FMDB. Some large frameworks such as beeFramework/ReactiveCocoa are difficult to become popular.

compatible

Front-end development requires compatibility with a large number of browsers, including desktop Chrome, Safari, IE6-IE10, Firefox, and various shell browsers such as Cheetah 360, and mobile iOS/Android browsers, as well as infinite different screen sizes. It looks scary, but it's actually not that difficult to deal with. It's just used to scare people. Desktop Chrome/Safari and various shells' extreme speed modes all use Webkit, with little difference. Firefox also generally follows the standard implementation and is not much different from Webkit. Old IE6/7 needs special care, but many websites do not support IE6 anymore. Mobile terminals are even more like one family, all using Webkit. Except for the different support levels for new features, there are not many other differences. For different screen sizes, high-end ones will use responsive layouts, adapting to different layouts for different screen sizes. Generally, desktop terminals have a fixed width, and mobile terminals can stretch the adaptive width to get it done.

Terminal development also needs to be compatible with various system versions and phone sizes. Android is not to mention, iOS also has 3.5/4/4.7/5.5/9.7 inches. However, compatibility is as easy as Web, that is, adaptive width. iOS UIKit handles all of this, and there are advanced features such as autolayout and sizeClass available, so you don’t need to spend too much effort on size. iOS7 is a watershed in system versions. The UI differences before and after iOS7 are quite large, so some efforts need to be made to make them compatible. However, iOS users update very quickly, and it is expected that users below iOS7 can ignore it in one or two years.

performance

Both the terminal and the front end are user-oriented, and the purpose of performance optimization is to present content as quickly as possible and to allow the program to run smoothly under user operation. The terminal mainly focuses on storage/rendering performance. When an APP stores a large amount of data and the data relationship is complex, data query can easily become a performance bottleneck. It is necessary to continuously optimize the efficiency of data access, plan data IO threads, design memory cache, make good use of the limited memory of terminal devices, avoid repeated rendering, reuse views as much as possible, and find the most efficient rendering solution.

The front-end focuses on page loading speed. Since the structure/style/program/resource images of a web page are all requested in real time, in order to make the page present content faster, it is necessary to optimize these requests so that these resources can be loaded at the fastest speed, including merging images/merging codes to reduce the number of requests, compressing codes, parallel requests, caching code requests according to version numbers, gzip compression, lazy loading of modules/images, etc. In addition, like the terminal, it also pays attention to rendering performance, follows some rules to avoid page reflow, avoids using special effects such as CSS shadows that consume performance, and uses CSS3 animation instead of js, etc.

Compile

Terminal development requires a compilation process, which compiles the program into machine language, and then links it with various libraries to generate an executable file corresponding to the platform, which is finally scheduled for execution by the operating system. In iOS terminal development, Apple has packaged the compilation and linking rules in the development tool xcode, so general developers don’t need to worry about them. However, when there are deep requirements, you still need to deal with compilation a lot, such as using the compilation front-end Clang to customize static code detection rules, writing compilation scripts for automated compilation and continuous integration, packaging to generate static libraries, and optimizing the size of the APP based on the composition of the linked executable files.

Programs developed on the front end do not require a compilation process. Instead, you only need to throw the code to the browser, which will parse and execute the code. Although the browser can parse and execute the js/css code without doing anything after it is written, in order to optimize the performance mentioned above, all code and resource files will be processed before the front-end code goes online. These processes include: compressing and merging js/css, merging CSS sprites, processing module dependencies, processing code resource version numbers, processing resource locations, etc. This process is very similar to the compilation of traditional programs. The code for humans is optimized for machines and some dependencies are resolved. This can be regarded as the compilation process of the front end. Tools such as grunt.js/fis can help complete this compilation process. Usually, front-end compilation is combined with online deployment as part of the online system.

Safety

Although the security issues of the front-end and terminal do not need to be considered as much as the back-end, there are still some things to pay attention to. In terms of request security, the terminal and the front-end are the same. The requests sent by users to the back-end need to go through layers of routing, and it is unknown where they are intercepted, tampered with, or replayed. Therefore, some measures need to be taken to prevent these situations. The most common one is identity authentication, which often uses an expired token instead of a username and password to prevent hackers from logging into the account forever after being captured. Those with high data security requirements will use encrypted transmission or https. In addition, it is necessary to deal with some DNS hijacking, operator advertising implantation and other issues depending on the situation.

Other security issues are rarely considered on the terminal. On non-jailbroken iOS machines, the system has helped to ensure the security of the entire APP operating environment. On jailbroken machines, malicious programs have root privileges and can do anything, and APPs are also difficult to prevent. In terms of the front-end, the characteristics of the browser make front-end development have several security risks. First, js code can be dynamically inserted anywhere on the web page, and the browser will execute these codes indiscriminately. Second, the authentication information is uniformly saved in cookies. Third, the page can be freely embedded in other websites through iframes. This causes XSS, CSRF, cookie hijacking and other attack methods, so when writing code on the front end, you need to consider these security issues and take corresponding precautions. The simplest and most important precaution is to completely filter all user input and output content to avoid malicious code being embedded in the page.

Interaction/Development

Finally, let me talk about my personal feelings about the interaction and development of these two fields. When I was working on the front end of the Web, I felt that the Web had set human-computer interaction back ten years. The interaction was rigid, and the results came out in a snap. The scrolling was refreshed one by one. Many people were advocating how cool the effects of HTML5 could be. In fact, FLASH could be made ten years ago, and it was smoother than the most modern browsers. After the popularity of the iPhone, human-computer interaction finally returned to its proper level, and the experience was much smoother than the Web. Fingertip interaction/smooth animation/convenient sliding gestures/unlimited implementation, the mainstream finally returned to or surpassed the level of Flash ten years ago.

However, while human-computer interaction has improved, the development method has regressed greatly. The development method of the Web is very advanced, and users use the latest version. Bugs can be fixed online in seconds when they are found, which is particularly suitable for rapid iteration in the Internet environment. However, terminal apps are not like this. Apart from the review of iPhone, Android cannot guarantee that users use the latest program. They all use the traditional client update method. Bug fixes cannot be provided to users in a timely manner, and cannot be released online dozens of times a day. Many old versions need to be maintained, and the development method regresses to the pre-Web era. This is all due to the instability of mobile networks and limited traffic. Mobile terminals cannot rely entirely on the network like desktop browsers, so the development method will not change much before the mobile network is stable and traffic is free.

In addition, I am not optimistic about HTML5. People have been saying on the Internet that it can replace APP for three or four years, but it has not achieved any results so far. I don’t see its advantages. Native APP can obtain more system resources and provide a smoother human-computer interaction experience. HTML5 will never be able to match it in this regard. Under the limitations of mobile network and traffic, it cannot give full play to the development advantages of the Web, so it will not become mainstream and is only suitable for making some lightweight small things.

This article comes from: http://www.199it.com/archives/316224.html