Using JavaScript to Build HTML5 Tools (Ian Maffett)

Future of Applications
Ian Maffett – Intel Software Engineer
October 28, 2014
FOWA Boston

 HTML5 Team & the Intel® XDK
 Tools we use and why
 Tips/Tricks
 Final thoughts
Copyright © 2014, Intel Corporation. All rights reserved. *Other names and brands may be claimed as Optimization Notice the property of others.
2
Overview

The HTML5 Tools team is part of the Software Services Group
division (SSG).
SSG employs thousands of developers who work on projects such
as Android, the Linux Kernel and compilers
HTML5 team focuses on runtimes, code optimizations, and tools.
Intel® XDK is a tool to build cross platform mobile applications
(Cordova) without any native SDKS.
MASSIVE single page application.
(most of our team had never wrote a web app before)
3
HTML5 team

The HTML5 team has developers in the following locations
Lancaster, PA
Hillsborough, OR
Santa Clara, CA
Cordoba, Argentina
Novosibirsk, Russia
Hudson, MA
Merrimack, NH
China
4
Developers spread worldwide

5
Intel® XDK – build cross platform hybrid
applications

Quick demo of the Intel® XDK
6
Intel® XDK Flyby

Tools used to build the Intel® XDK
7

8
(how many logos can we fit)?

Chromium up front, node in the back. Node Webkit allows us to
distribute specific versions without requiring the user to install
anything. Used in apps like Popcorntime and Phonegap Desktop
Single threaded process. This causes problems with the
emulator. Users code could hang the XDK with a synchronous
script load. Had to change to client/server mentality.
Check it out - https://github.com/rogerwang/node-webkit
9
A desktop app that’s really a web app.

10
Q.js / Promises (breaking callback hell)

Client is built using Backbone and jQuery. We use RequireJS to
load our components in our application.
Initial architects created base developer guidelines. *ALWAYS*
have one in place when starting a new project. Half the team had
never written a web app before.
Component based – each component is its own entity, but may
need to listen to other components for events (like project
changed).
Components have their own dependencies too.
App Designer – uses Angular/LESS.js
11
Front side: Backbone, jQuery and RequireJS

12
Components loaded asynchronously

 Normal “backend” server
 Client code makes calls via HTTP to “server” components
 Great for us to write JS for everything.
 Tests created using Mocha and run by the CI server (and
developer)
 UserFS – wrapper to various file systems (native, s3, etc)
 We were writing the XDK to work on the desktop and “cloud”
 Growing pains trying to re-implement an FS.
 Still use some NodeWebkit “magic” for gathering server side
objects that developers can use CDT to inspect.
13
Server Components (node modules)

Register components from package.json (it is a Node app)
Wrap server side component calls through a proxy function
- “local” – direct access through Node Webkit
- “browser” – make calls via HTTP Request
Devs run in “local” mode for server side debugging in CDT.
Switch to “browser” to test installed versions.
14
NW Magic

Components
Client
Emulator
emulator.js
emulator.css
Server
Emulator
emulator-webserver.js (web server)
emulator-notification.js (replicate push notifications)
15
Component folder structure (example)

16
We almost wrecked the original groundwork.

Adopted Google’s JS style guideline (for the most part).
Mocha tests for server side.
Selenium for Client side – created user tests and end to end (E2E)
tests for Windows, Mac and Linux.
JIRA for bug tracking
Crucible for code reviews (which ties into JIRA)
Team City for CI/builds
Daily emails about commits/builds
UI Style guidelines
17
JSHint, Mocha, Selenium and CI to the
rescue.

If you’ve configured your git hooks properly we have scripts to run
before the push. These check node modules, commit messages,
will run jshint, etc.
CI server will run throughout the day and run tests/jshint.
Create a code review if needed.
CI server kicks off daily build kits which then goes through Q/A
Grunt used to run tests locally and also create our install kits
(minification, concatenation, etc)
18
When a developer commits…

Tips/tricks/thoughts
19

20
Memory becomes an issue
The browser is not reloaded, so you must manage events
properly.
Using established libraries can help with cleaning up orphaned
children.
CDT has great tools for tracking down performance issues.

21
Focus on UX (versus regular web)
Don’t be slower then a full page reload.
Make the app snappy and fluid.
Watch flash of content on repaints.
Remember browser performance of desktop, mobile and other
devices.

22
Pick the best tools for the project
Don’t start a massive new project just because you want to use
tool XYZ.
Introduce new tools/frameworks on new functionality that can be
separated.
* With the XDK being component based, we are testing React.js in
Brackets and Polymer in the core UI framework.

23
Web apps are so much more these days
Desktop apps
Mobile apps
Websites
Intranets
Portals
IoT companion apps
In Vehicle Infotainment apps (IVI)

24
Not Invented Here syndrome
This can kill your project. Use existing tools to help scale your
development cycle.
Also for UI/UX* - Use existing frameworks and tools.
*Do invent and share your own projects. There is a thriving
community right now around JavaScript; join and participate.
That’s why we are here today.

25
Popcorn time (Desktop/Mobile)

26
IoT Companion app
http://xdk-software.
intel.com/iot_edition_demo_video/

27
Desktop/Mobile websites

28
Tizen IVI

Questions/comments?
ian.maffett@intel.com
@imaffett
29

Legal Disclaimer & Optimization Notice
INFORMATION IN THIS DOCUMENT IS PROVIDED “AS IS”. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL
OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. INTEL
ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY,
RELATING TO THIS INFORMATION INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A
PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER
INTELLECTUAL PROPERTY RIGHT.
Software and workloads used in performance tests may have been optimized for performance only on Intel
microprocessors. Performance tests, such as SYSmark and MobileMark, are measured using specific computer
systems, components, software, operations and functions. Any change to any of those factors may cause the results to
vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated
purchases, including the performance of that product when combined with other products.
Copyright © 2014, Intel Corporation. All rights reserved. Intel, Pentium, Xeon, Xeon Phi, Core, VTune, Cilk, and the Intel
logo are trademarks of Intel Corporation in the U.S. and other countries.
Optimization Notice
Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are
not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other
optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on
microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for
use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel
microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the
specific instruction sets covered by this notice.
Notice revision #20110804
30

Using JavaScript to Build HTML5 Tools (Ian Maffett)

Using JavaScript to Build HTML5 Tools (Ian Maffett)

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Using JavaScript to Build HTML5 Tools (Ian Maffett) (20)

More from Future Insights (20)

Recently uploaded (20)

Using JavaScript to Build HTML5 Tools (Ian Maffett)

Editor's Notes