TiConf NY 2014 - Alloy 2.0

Post on 06-May-2015

2,092 views 5 download

description

The future of Alloy and open source development at Appcelerator

transcript

2.0Leaner & Meaner

#HappyMothersDayFromTiConf

Text

Tony Lukasavage@tonylukasavage tlukasavage@appcelerator.com

MVC framework for Titanium

Declarative UI via XML

Styling via TSS

Models & data bindings

Widgets

Embeds best practices and high performance techniques aimed at delivering the most stable,

high quality Titaniums apps possible.

3 types of people

Those who love Alloy Those who have never used Alloy Those who have founded Apperson Labs

Why Alloy Works

Community-driven effort

Feedback loop

Iterations & experience

Features based on need

How can we do better?

Vision & Transparency Road map Ownership

app development Features, best practices, and stability

“If builders built buildings like programmers wrote programs, then the first woodpecker that came along would destroy civilization.”

— Gerald Weinberg

Write Once Mode

Parity Mode

Aims for a higher degree of a write once, run anywhere experience

Parity where parity matters, but still provide native experience

Large, integrated effort

Intelligently creating new normalized APIs

XML Templating

view modules

Same views you know and love

Compiled to separate modules

Promotes reuse and export

Possible to generate entirely new syntax (i.e., hyperloop)

Titanium

iOS

Windows

How do you export your own controller definition?

How can you do true prototype inheritance on controllers?

How do you create a controller-specific model in code and use it with view-model binding?

How do I get arguments in my controller without this hideous syntax: var args = arguments[0] || {};

How do you skip time-consuming AST parsing on controllers that don’t need it?

Controller Trivia

How do we solve all of that with one fundamental

change?

Pure JS controllers

TSS.. more or LESS

Alternates forms of style syntax?

What about something like LESS?

Improvements to the core of TSS, driven by external TSS pre-processor development

data models

Simpler and more focused

No more masking Backbone

Expose a programmatic interface for view-model binding

Faster, more intelligent data binding

Existing format

exports.definition? What happens to it?

Why separate definition from models and collections?

extendModel & extendCollection… WAT?!

Hey look, Backbone!

Use Backbone conventions

Simpler, pure CommonJS format

Unnecessary Cruft

nested collectionsVery specific use cases: TableView & ListView

Efficiency and convention

bidirectional binding

Very specific use cases: TextField & TextArea

Convenience where it makes sense.

dev experience faster, happier development

“I love it when a plan comes together” — John “Hannibal” Smith

local installs

Have as many non-conflicting alloy installs as you want.

Can be global or per-project

Allows you to take Alloy updates on a needed basis, just like Titanium.

Alloy as a dependency

export widgetsWidgets in traditional Titanium apps

Fully functional

Native or plain CommonJS modules

scaffoldingrobust generators for widgets, builtins, adapters, commands, and generic commonjs modules

Configurable to your environment

Not just code structure, but ready for distribution

ridiculously fast compiles

No builtins

Pure JS controllers to handle inheritance

Separation between controller and views

There’s full runtime version of the Alloy library

No more AST parsing!!!100x speed up with Alloy compiles

Leave the AST parsing to optional pre-processors

LiveView, TiShadow, and RapidDev just got extremely more powerful

parallel compiles

Android Blackberry iOS MobileWeb

$  alloy  compile  —platform  all

rock solid with metrics

!

“What’s measured improves” — Peter F. Drucker

unit testing

Travis CI for continuous integration

Covers master, branches, and even pull requests

test coverage

ti-mocha

contributing made easy

“In open source… to really do something well, you have to get a lot of people involved.”

— Linus Torvalds

npm

70K+ modules, 1/4 billion downloads a month

distribution for all widgets, “builtins”, adapters, commands, and anything we come up with.

It’ll just work with Ti.Next

require() will work like node.js

ti-commonjs in the meantime

ti-commonjs

Library and CLI hook that provides a node.js-style commonjs implementation to ti.current

Using npm for package management just works

Initially supported on android and ios

Initially alloy, but could work for traditional titanium

VS

Undo incremental growth and expansion of repo

grok-ability

Externalize non-essential modules

widgets

“builtins”

tools

git-style subcommands

Add arbitrary commands that can make use of Alloy configuration data

Extensibility allowing for out-of-band contributions

module API

!

Use Alloy as a node.js module, not just a CLI

No more expensive, unreliable sub-processing

natural progression with git-style subcommands

get on board migrating to the awesomeness

“If you want to make enemies, try to change something.”

— Woodrow Wilson

1.X -> 2.0Migration will be a driving force behind the new features, not an afterthought.

Old formats will be deprecated, but most will still work

New controllers, views, models, styles, widgets, and even builtins will be able to be migrated through an automation script.

You could very well be porting to 2.0 with no manual intervention

wrap-up

try to keep up

http://bit.ly/alloy_2

Special Thanks

Fokke Zandbergen Mads Moller Aaron Saunders

Paul Egli David Bankier Tim Poulsen