"Editor's note" This writer is the author of "JQuery UI practice", TJ Vantoll, a senior web developer who focuses on mobile WEB applications and their performance.
This article is compiled by OneAPM engineers, and the following is the second part of the text. Click here to read the first section.
Local mobile apps
In 2015, a new category of JavaScript-based mobile application development was introduced: JavaScript Native. Unlike Cordova-or PHONEGAP-based applications, JavaScript native apps use the platform's local control and paradigm to build a user interface without involving a browser or Web view.
The JavaScript Native framework tries to provide a way to build IOS and Android apps with both worlds: Using JavaScript to write program logic (not Java,swift, etc.), using the platform's local user interface API to build an application that adapts to the native OS, To achieve the best possible performance.
For examples of mobile apps built with JavaScript, click here to get the source code.
React Native and Nativescript were the first publicly released two JavaScript Native frameworks in 2015 and later included Fuse and Tabris.js. Naturally, different frameworks provide different functions. For example, React Native allows the React JavaScript framework to be reused, while Nativescript allows direct calls to IOS and Android APIs. However, they all have advanced methods for building real native apps using JavaScript.
While the idea of using JavaScript to build on-premises apps is tempting for web developers, the JavaScript Native framework has some of the following drawbacks compared to frameworks like Cordova:
Since the JavaScript Native framework does not use a browser, you must learn the framework-related APIs used to build the interface, rather than using the HTML language as easily as you would create a Cordova application.
Because JavaScript Native applications are local applications, memory management is an additional consideration when building larger applications, as is the case with native IOS and Android apps.
Finally, because the JavaScript Native framework is very new, there are limited cases and tutorials to refer to. These frameworks are still immature compared to the frameworks that have evolved over the years.
On the development of these frameworks in 2016, the author interviewed Christopher Chedeau (aka Vjeux) from the React Native team and Nativescript's product manager Valio Stoychev. Both are closely aligned with the stability.
"As far as React Native is concerned, we have been through the early stages of the new phase, and the stage we are entering now requires us to become more secure." As you can see, we've put a lot of effort into performance tool optimization, core APIs promotion, error message optimization, and edge case repair. This makes it possible for engineers, both inside and outside of Facebook, to build higher-quality mobile apps at their whim. "--facebook,christopher Chedeau (Vjeux).
"With the continuous expansion of the user base, we want to ensure a robust framework for users to build practical applications on this basis." Therefore, we intend to continue working on performance and debugging tools to improve the experience of nativescript developers. In addition, another center of gravity is the collaboration with the Angular 2 team, which is expected to run through the year 2016. "--telerik,valio Stoychev.
JavaScript Native 2016 outlook
For the JavaScript Native platform, the 2016 focus is on improving stability and adoption rates. With frameworks such as React Native and Nativescript consolidating their feature sets, it is expected that there will be more tools around these frameworks, such as Telerik Nativescript Telerik for building Platform applications.
Of course, time will tell us whether the great heat of the 2015 JavaScript Native application can be converted into large-scale use in 2016. However, the large number of high-quality applications that have been successfully built using these frameworks (see the React Native case Show and the Nativescript Case showcase) seem to imply that the pattern of application creation using the JavaScript Native method will be popular for a long time.
For companies that need to combine local UIs with local applications, the JavaScript Native framework builds IOS apps with Xcode and Objective-c/swift and uses Android Studio and Java to build Android Applications, providing more powerful options, especially considering that most companies have a certain JavaScript development capability.
All in all, the JavaScript Native app is an exciting new battleground for JavaScript developers. JavaScript developers no longer need to learn local programming languages to write local mobile apps. However, native mobile apps are not the only area where JavaScript is infiltrated-JavaScript is also involved in traditional desktop applications.
Desktop Apps
As a rule, if you want to build a Windows or Mac app, you'll use platform-specific tools such as WPF and Windows Forms, or cross-platform interfaces like Java, Adobe Air, and so on. However, as with the other software ecosystems discussed in this article, JavaScript-based solutions are slowly invading this landscape.
The first JavaScript-based solution in the field was Node-webkit, created by Intel and open source at the end of 2011. Node-webkit is now also known as Nw.js because it has switched from WebKit to Chromium. Nw.js is implemented in a similar way to Cordova, except that it is for desktop applications.
Nw.js was first developed by Intel and released publicly in 2011.
Nw.js will package the Web app to the local shell, while providing access to local desktop APIs such as file selectors, window menus, and more. This combination allows you to build Windows,os X and Linux desktop applications using unified standards-based web technology.
If you move forward for a year or two, you will find that nw.js is not the only framework for using this infrastructure. In April 2015, GitHub announced the introduction of Electron, a similar framework for creating cross-platform applications.
GitHub announced the introduction of Electron in April 2015
The Electron was first developed as the shell of the Atom (GitHub Web-side text editor), which was later split to be easier to use in other projects. With GitHub's support, Electron's popularity has soared, and now there are more than 20,000 stars on GitHub (quickly catching up to Nw.js's 25,000 stars).
In 2015, as the engine behind Microsoft's new cross-platform Visual Studio Code IDE, the Electron was once again on the headlines. In addition, a look at the list of electron resources created by the community will see how popular electron is in the development community.
Desktop Apps 2016 outlook
Similar to many of the techniques discussed in this article, the future of these cross-platform JavaScript tools for desktop applications seems promising. With GitHub, Microsoft, and even Slack these precedents--slack are not built on nw.js or Electron, but also use web technology to create local apps-other companies can confidently use web technology to build desktop applications. It is expected that in 2016, projects such as Nw.js and Electron will create more desktop applications.
New areas of JavaScript 2016
Although the topics discussed in this article seem somewhat fragmented-server-side code, mobile apps, and desktop applications-the main body of the narrative is basically the same: in just a few years, running JavaScript in these environments has evolved from unimaginable to inevitable. In less than 10 years, JavaScript has evolved from the pediatric language used to handle picture flipping into perhaps the most popular programming language in the world. There seems to be no limit to the future of JavaScript.
In 2007, Jeff Atwood: "Any application that can be written in JavaScript will eventually be written by JavaScript." This sentence is almost as accurate as the prophet. In fact, JavaScript has been extended to a number of areas not covered in this article, such as running on hardware through johnny-five projects, or even becoming a class-one citizen to create local apps in Apple's recently announced TvOS for Apple TVs.
One of the main reasons for the growing JavaScript is the desire to build multiple models of software using a single development model. Most companies, especially small companies, are unable to hire enough developers to meet the myriad of operating system and device types that people are currently using. Even in companies of this size, this is a big problem, as Christopher Chedeau said:
"In my eyes, one of the great sorrows of the developer world is that communities are divided by language (or even ecosystems). JavaScript, Java, Objective-c, Python, C + +, and more. In fact, this leads to a huge waste of resources, because for each ecosystem, a similar set of tools such as Package Manager, IDE, core function library, knowledge base, etc. are developed.
For example, on Facebook, we have to implement three times for each feature: Web, IOS, and Android. To make things worse, because an engineer is often difficult to master these ecosystems at the same time, we usually need three people to implement a function. This is really sad.
To solve this problem, the first thing I think about is that we need a single language or ecosystem. With React Native, we tend to be more JavaScript language, but from a macro point of view, which language is not important. It is important to keep only one language. "--facebook,christopher Chedeau.
With JavaScript rapidly gaining popularity in the mobile, desktop, server, and hardware sectors, it has become the only language that could make this vision a reality. Time will tell us whether JavaScript's breakneck growth lasts for 2016 years. However, the rapid popularization of JavaScript tools in the software ecosystem seems to herald the limitless future of JavaScript.
Based on this, the author will use Brendan Eich's famous quote as the end of this article: "Always believe in JS (constant bet on JS)." ”
This article is compiled and presented by OneAPM engineers. OneAPM Browser Insight is a real user-based Web front-end performance monitoring platform that can help you locate site performance bottlenecks, website acceleration effect visualization, browser support, App browsing HTML and HTML5 pages. To read more technical articles, please visit the OneAPM Official technology blog.
This article was transferred from OneAPM official blog
Original address: http://developer.telerik.com/featured/what-to-expect-from-javascript-in-2016-beyond-the-browser/
2016 JavaScript Outlook (next)