Dart Developer Summit Highlights – Day 2

Hi again Dartisans. Here’s the second post I promised you. For those of you who haven’t seen the first post, I made a summary of the Dart Developer Summit 2015.

• Keynote: Ads
• Instill.io
• Building Production Dart Apps with an Open Source Workflow
• Panel with Dart Engineers
• Google Fiber and Dart
• Dart for the Internet of Things
• Moving from Node.js to Dart
• Dart for Mobile
• Sky: An Experiment Writing for Android with Dart

Keynote: Ads

Ferhat Buyukkokten and Ted Sander highlight how Google’s Ads team uses Dart to build their web applications. This is a good demonstration of how Dart can interoperate with other existing systems. It’s also a nice confirmation that Google is dedicated to Dart for its new projects.

• Updating a CRM system
  • Change the back-end in flight
• Before Dart, there was frustration
  • Changes were slow and hard to implement
• They really didn’t want to try languages without types at Google
• Fast, even as JS
  • Dart is just as fast as handwritten js for several benchmarks
  • Sometimes faster and sometimes slower, but not by a lot
• Batteries included
  • Great tooling
  • Package manager
• Internal/External libraries were easy to use
• dart-mockito is their mocking library – it just works
• Large-scale applications with good performances
  • observatory helped diagnosing where the pain points were
  • low and stable memory usage
• Communicate through different apps using a JavaScript event bus
  • AdWords is built with multiple apps – GWT, Dart, etc. and they talk to each other
• Divide and conquer
  • Even if you could start of scratch, it’s still a good idea to keep your application in modules
• Google Ads are committed to Dart

Instill.io

Mathieu Lorber and François Saulnier from Instill.io explain how they managed to build their video creation web application with Dart as their front-end technology. Yet another good example of how Dart can be used with other technologies (in this case Java) for the back-end. They also explain in details how they transitioned from Angular.Dart to Polymer during their development. It’s interesting to see how they did it, because I personally did the opposite (moving from Polymer to Angular).

• Why Dart?
  • All about productivity. They had a debate on whether they should start with technologies they know, after a long discussion they agreed that Dart presented all the advantages of the technologies they knew, and they decided to start with Dart.
• Architecture
  • Dart front-end
  • Java back-end
    • CQRS + event-sourcing
  • Movie rendering layer
  • Publishing layer
  • Message queue
• The Java back-end can be painful when coming back from Dart
• They use Angular.Dart for their application framework
  • It was hard in Angular.Dart 1.0 to create small isolated components
  • It was hard to programmatically add a component
• They now use Polymer for their components instead of Angular
  • They can now reuse small components
  • They now use Polymer elements as DOM elements in their Angular application
  • Angular controllers are now stateful Polymer components
  • Routing is now a Polymer component too
• What they miss from Angular.Dart
  • Injection and services
    • Dependency injection can be reused independently. They created an @Inject() annotation
  • The Scope
    • Communication between components
    • Internal change tracking
      • Polymer data-binding
    • Communication between non-related components
      • They use the package event_bus
  • Routing
    • They didn’t really miss it, they introduced a notion of Places. However you can still use Angular.dart routing package independently.

Building Production Dart Apps with an Open Source Workflow

Devon Carew and Luke Church built DartPad, an IDE for Dart in the browser, as open source and with open source. In this session, they show you how to unit test, measure code coverage, trigger Continuous Integration, and deploy to the cloud, all with open-source tools and libraries. The most interesting part about the tools they presented here, is how they leverage the power of Google Cloud Platform with AppEngine, the Managed VMs and the Memcache.

• How they built DartPad
  • They used dart-services on the back-end and made UI in Dart
• Continuous integration for unit tests
  • Travis CI
  • Drone.io
  • AppVeyor (windows)
• Functional Testing
  • Sauce Labs
  • test/web_integration.dart with WebDriver
• Code coverage
  • Package dart_coveralls and coveralls service
    • Get notifications on specific threshold
• Web hosting and scaling
  • They use AppEngine
  • UI Server serves static files & redirect
  • dart-services in AppEngine
• Dart on AppEngine
  • The Dart app deployed on AppEngine routes to a Dart process in a Managed VM
  • The process in the ManagedVM uses the rpc package
  • Making it fast
    • Memcache
    • Keeping the VM warm
      • Reusing Dart VM
      • Uptime monitoring
• Hosted metrics
  • Librato – hosted metrics and logging service
• Uptime monitoring
  • Pingdom – update reports services
• DartPad is now 1.0!

Panel with Dart Engineers

I decided not to put all questions and answers because some of them were a bit too specific, but here are my favorite ones, which I think will be of interest to more people.

• Q: How does type annotation impact performances?
• A: On the VM specifically, it doesn’t matter at all whether you type your variables or not. When the code is parsed (unless in checked mode), we throw the types away. The optimizations are based on collected types that you see at runtime, and it works well; they know exactly what are the potential subclasses that can be used.

• Q: Is there any plans on doing code hot-swapping in Dart?
• A: It would probably work well already in the VM, but there are plans to find good solutions to that in the following months.

• Q: DartEditor vs Webstorm?
• A: We’re moving away from DartEditor, and going with WebStorm. The other goal is to provide a good UX to people who are already familiar with other tools via plugins (Eclipse, Sublime, etc). For the “try-dart” experience that DartEditor was giving, we suggest going with DartPad now, where you can try things with low friction, share snippets and make things run. WebStorm is the primary focus.

• Q: What’s the roadmap with Polymer.Dart?
• A: We’re waiting for the Polymer team to stabilize. It’s coming pretty soon. When they reach Polymer 1.0, we’re going to provide Polymer.Dart 1.0. Second thing is with dev_compiler and jsinterop, you will be able to share your components/libraries with other developers (dart/js).

• Q: What will happen if Fletch gets out of experimental?
• A: We will ship it this year.

• Q: Dart vs ES6? Does ES6 provide all what Dart does?
• A: Dart still has an advantage. ES6 is still JavaScript, and you don’t fix all problems by adding classes. The types in Dart still make programs easier to read and easier to maintain.

Google Fiber and Dart

Jason Daly shows how they created the UI of Google Fiber with Dart, and how it integrates with other languages in their infrastructure. With all the other alternatives to Dart, he also explains why they still picked it, and what they got out of it. It’s a good example of how Dart can be used on embedded devices, not without good challenges.

• How they created the UI with HTML5/CSS3 and Dart
• They have Dart-VM-based services interacting with native code
• Their new solution
  • They wanted to move lots of data on the cloud instead of on the boxes in households
• Why Dart?
  • Looks and feels like many other languages
    • Classes, generics, strict type checking (when you want it), libraries and imports
  • Still has the dynamic and asynchronous features that web apps need
  • Not limited to browser and web apps
  • Development wins
    • Easier to pick up than JavaScript
    • Dartium makes prototyping easy
    • Allows on-the fly rendering of UI tweaks
• Deployment wins
  • Deploy to a url for the UI
  • Server-side can be updated without deploying a new firmware image
• Challenges
  • No pointing device (no mouse) — had to develop their own widgets
  • Limited physical resources
  • Dynamic fetching
  • Interfacing with the hardware
• The browser cannot do everything
  • Interactions with the disk
• DVR Service
  • Runs in the Dart VM on the Google Fiber Storage Box
  • Interacts with the TV UI running in Chromium on the TV Box
• Dart works well on embedded hardware

Dart for the Internet of Things

Dennis Khvostionov of DGLogik shows their new IoT platform called DSA, and how they implemented it end-to-end with Dart. We can see their WYSIWYG IoC application editor (DGLux) built on top of their Open Source platform (DSA).

• DGLogik
• DGLux – Drag and drop WYSIWYG Visual Application Development
  • > 200k Dart LOC
  • > 1k deployments globally
• Why Dart
  • Rapid developement
  • Rapid testing
  • Rapid fixing
• dart2js has never been problem for them
• DSA – Open Source Platform & Toolkit for IoT
• A bunch of demos, should watch them.
• He shows us a game called “performanceTest” that allows us to see the whole thing in action, it runs pretty smoothly!

Moving from Node.js to Dart

Faisal Abid tells how he ported the API of his native Android stock simulator game Market Wolf from Node.js to Dart. Since Node.js is so popular, many people probably asked themselves whether Dart or Node.js would be the best choice. Here Faisal explains why he went to Dart, and what’s been beneficial for him since then.

• Why?
  • Tooling & debugging support for node.js is a pain
  • Node.js didn’t seem to be the right answer
  • Node and Dart are pretty similar
• Differences
  • Different paradigm
  • Multiple cores
  • Node – multiple VMs needed
  • Dart – Isolates
• Pros and cons to moving to Dart
  • Pros
    • Better profiling and debugging with Observatory
    • Syntax and language features
    • Organization of code is better and enforced
    • Support for major databases on pub.dartlang.org
  • Pro/Con
    • Shift in thinking
  • Con
    • Missing support for esoteric and very new database. But most protocols are JSON based, so it’s easy to port it
• Finding alternatives to what he was using in Node.js
  • Express
    • Redstone
      • Actively developed by community
      • Very express-y
      • Good support for plugins/middlewares
    • Shelf
      • Written by Google
      • The base for Redstone
      • Minimal
      • Use middleware for routing
      • Redstone’s middlewares come from Shelf
      • Simple API
    • RPC
      • The newest
      • Enables you to write RPC style Dart API’s easily
      • Self documenting API
      • Uses annotations
      • Bit more verbose
      • Very clear API
      • Can generate client side libraries in Java, Python and others
  • Socket.io
    • Dart comes natively with WebSockets
• Thinking in Dart
  • It’s easy to replicate Node.js, but you must think in Dart
  • Simplify architecture by using Isolates
• Isolates are very low on memory footprint
  • He used to have 3 node.js VMs + 1 message broker, now he has 3 isolates @ 1.5MB of memory each
• Deployment
  • Anything that supports Docker supports Dart
  • Codeship + AWS Beanstalk
• Worth it?
  • Yes. No question about it
  • Dart language, language features, observatory, etc.
• Missing anything from Node.js?
  • Absolutely not.
• Amount of lines of code shrunk dramatically. Easier to debug, deploy, less dependencies to worry about.

Dart for Mobile

Kasper Lund presents a demo of Fletch, an experimental runtime for Dart that makes it possible to implement highly concurrent programs in the Dart programming language. He shows how it can make native applications run on Android and iOS.

• Why do people want to use Dart on mobile?
  • Modern and light stack
  • Developer productivity
  • Code sharing across multiple client apps
    • Use same model but different UIs
• Fletch — Dart runtime for mobile
  • Still early stage
  • Small and elegant runtime system
  • Supports on-the-fly program changes
  • Runs on iOS through interpretation
  • Light
    • Extremely fast startup (~2ms)
    • Low memory overhead (~200K binary size)
  • Interactive
    • Atomic program changes over wire protocol
  • Concurrent
    • Blocking an isolate is simple and cheap
    • Easily scales to 100k concurrent isolates
• Fletch SDK
  • Command line
  • Breakpoints
  • Live code editing in your editor and apply changes with the command line
• Roadmap
  • Q3 – Fletch SDK Beta
  • Q4 – Fletch SDK 1.0
  • Q4 – Dart for mobile 1.0
    • Will contain the toolkit for Presentation, Services and Runtime
• Interop
  • Intermediate language declaring services in low level
  • Implement them in Dart
  • Fast messaging
    • Messages are transferred as binary
    • No expensive encoding/decoding
• It’s not the fastest thing ever as it’s interpreting code, but it’s most of the time way enough for real things.

Sky: An Experiment Writing for Android with Dart

Eric Seidel presents Sky. Sky is an experimental, high-performance UI framework for mobile apps. Sky helps you create apps with beautiful user interfaces and high-quality interactive design that run smoothly at 120 Hz. This presentation contains multiple demos, and gives us a little sneak peek of the a functional programming style inspired by React that Sky uses. It will be fun to see how in the future Sky and Fletch will interact (if they will).

• Sky Demo on Google Play
• Android app all written with Dart (even the UI) Native
• Best mobile experience
• Looking for performance
  • 120Hz or bust
• Platform agnostic
  • Android, iOS and more
• Full Access
  • Fully priviledged applications
• Fast development
  • Edit, Refresh, Profit
• Continuous deployment, it’s always up-to-date
• Rich & flexible layout & painting
• Still early stage
• Hello world live coding demo
• Sky Framework
  • Written in Dart
  • Big bag of widgets (Material Design)
  • Entirely non-blocking API
  • Functional reactive style (Stateless components)
  • Opinionated part of Sky that knows on what kind of device the application is running on
  • Integrated tools
    • Chrome tracing
    • Observatory in the device (can connect remotely)