JavaScript is not the most beautiful programming language in the world. It is for this reason that a world-class expert has written a book on the "pure" of the language. The title of the book is "Deep Digging for JavaScript Highlights" because the good stuff is buried pretty deep. Even so, it quickly became one of the most popular languages in the world. This popularity is well deserved because, despite the language's flaws, JavaScript offers developers important advantages that other languages cannot. There are some advantages that came after browser developers agreed to Javascript (well, technically ECMAScript) as the standard for the language of the web. Others are inherently the web application programming model and much less enhanced. However, while native apps dominated the web on mobile devices, the dominance of JavaScript is gradually shifting to mobile devices. Will it eventually dominate?
Popular but not a priority
- A recent TIOBE community list ranked JavaScript as the sixth most programming language and counting. The ranking of the TIOBE method tends to favor older, more mature languages and is less adept at following trends. In contrast, the Redmonk ranking method puts JavaScript at the top of the list. The Redmonk approach is somewhat biased towards languages with strong open source communities, but at the same time essentially reflects current trends and interests. Our own overview of the developer economy has shown that the HTML5/Javascript combination is already the second most popular language used by mobile developers, used by almost 55%. Lost by only a small margin to 57% of people using java. However, while we found the combination of HTML5 and Javascript to be the preferred group (19%), it was far behind Java (29%) on this phalanx. This looks set to improve significantly over the next few years. [How do you think of this? We've got a new survey, so check it out and let us know what you think]
JavaScript flies to freedom on browsers
-
This is not a standard "net win" statement. I don't think browsers or webview based applications will eventually rule mobile devices. Even if it is used and grows it will not be the norm. If in the future open web standards are really to rule mobile devices then they need to start with the Document Object Model (DOM). The DOM is not the building blocks of applications, but the basis of documents. Of course you could initially design an application for documentation around a platform, but you'd have a hard time. Take a look at the current frameworks that allow you to design fairly performant applications for mobile browsers or web views: React.js, Famo.us and lonic. What all three have in common is to use as little DOM as possible.
-
Yes, there are too many WebGL (or HTML5 Canvas must-haves), but these are low-level APIs. What you need is a large, possibly multibyte, good framework to create an excellent platform for developing most applications. This does not fit well with the web application programming model, where the latest program code is placed on a remote server, especially in a mobile environment. It's true that you can create a hybrid application on top of a big good store of WebGL locally, and just fetch application-specific code from a remote server. But why use a browser? Why not just javaScript outperforms other cross-platform frameworks with hardware graphics accelerators (hint: Qt offers a nice offering). A high-level API doesn't have that much overhead in bridging between languages. Perhaps there is also a lack of restrictions when it comes to accessing specific functions.
-
There are now several very interesting new options that fit this description. React Native and NativeScript.. They work in different ways, but both use JavaScript to build a native UI application. Appcelerator's TiNext might also be interesting, even though they've been talked about many times over the years without a release, so let's be patient and see what it looks like.
JavaScript exception
-
Apple has revived JavaScript's dominance on mobile. One key thing that prevents most developers from adopting an agile, web-style continuous delivery model on mobile is Apple's ban on code downloads. Without this significant slowdown in iterative patterns, comparative testing would be more difficult. This actually means that developers, especially beginners, will learn more slowly. Until recently, the only way to get faster iterations was to start with Android first and develop a hybrid app because Apple made JavaScript an exception in the code download rules for webviews. In the first case, it means that most early adopters are moving away from the platform. Unfortunately the UX trade-off in the second case is simply too great, and most developers go that route because of user app glitches or switching to native. However, in ios7, the JavaScriptCore interface was added for running JavaScript, and in the latest ios developer program license terms, they modified the rules for code download exceptions to include JavaScriptCore.
-
This makes sense from a security standpoint. Apple can audit and update their runtimes, however if they allow third-party runtimes to download code, they are not effectively monitoring security issues. Because JavaScript is Apple's only scripting option and they don't allow downloading code locally, JavaScript is back in a privileged position – as the only option for those who want to iterate quickly. The availability of JavaScript has sparked some efforts like React and NativeScript and Apple's relaxed grip on code download policies has been perfectly announced.
Will opening win?
-
Web advocates sometimes say that open standards based on the web will ultimately win, because open always wins. However, Linux is a clear example, an open and rapidly growing ecosystem with no committee unifying standards. React, Facebook seems to be a rapidly building developer ecosystem among open source projects. There is already a rapidly growing committee around React.js, which clearly gives them a head start. But the NativeScript team at Telerik is working with Google, so Angualr 2.0 needs to be integrated seamlessly. Google intends to support non-DOM environments, whether or not web standards are oriented towards it. Microsoft and Google may take a long time to support the standards they will implement in future browsers. But they are working together towards TypeScript to make it easier to build a less complex application with JavaScript (which turns out the compiler is smarter than a human at finding type mismatches).
-
Apple has built quite a few pretty impressive tools for their new Swift language, especially the interactive playground. However, Facebook may already have a better coding experience on React Native based on instant feedback and high-frequency instant coding. Apple will continue to iterate on their tools, and the developer community has now added these new JavaScript environment tools. Android may be technically open source, but it's not open to community building. Google is enhancing Android's platform and tools alone. It's probably really the open developer community that wins, and truly community-based open source can iterate faster than open source standards-based open source. To that end, a "native UX builds with JavaScript" environment and succeeds, a platform like this certainly won't fail. Applications are still built according to the platform's look and feel, using new platform-specific APIs.
-
At this point, it looks like the very open JavaScript developer community is going to win, as they make apps that have the look, feel, and performance of the native platform, in addition to requiring web development experience. Closed platforms used to win because apps back then needed to be customized for their closed ecosystems. For now, open web standards are losing. If mobile browser makers can agree to a new standard that allows them to make apps with native app-like experiences, then they're bound to win.
What are you using to make it?
- Do you think JavaScript will rule the future of mobile development? Or will Java, Objective-C and Swift continue their leadership? The Internet of Things, will its backend go through Node.js? Let us know what you use to build your app by taking a survey.