Clientside Framework Selection Criteria for Progressive Decoupling
Total Page:16
File Type:pdf, Size:1020Kb
Clientside framework selection criteria for progressive decoupling This document’s goal is to aid the Drupal community in choosing a JavaScript framework bestsuited for progressive decoupling, where Importance legend only parts of the page are rendered through the framework while key integration capabilities with Drupal configuration, modules, and themes are maintained. In short, Drupalrendered components ought to coexist gracefully with frameworkrendered components. M (must have) S (should have) Further reading: “Selecting a clientside framework for Drupal” — “Should we decouple Drupal?” — “The future of decoupled Drupal” N (nice to have) Criteria Most promising Promising Least promising Criterion Why it matters Angular 2 Ember React (V, Elm (lang, Backbone Angular 1 Knockout (importance) (MVC, (MVC, 2.2.0) 0.14.3) compiletoJS (MV, 1.2.3; in (MVC, 1.4.8) (MVVM, 2.0.0beta.0) ) core) 3.4.0) Serverside Serverside rendering of framework Builtin Add fastboot Builtin DIY with Add rendr Add server Add rendering of templates is important for SEO and Nashorn, prerendered templates (M) performance. Over time, it allows us to Rhino, or migrate to unified templates across Node.js client and server and a serverside JavaScriptbased render, whether via inPHP JS execution or via a thin layer of Node.js. Rehydration / Does the clientside code discover and Planned In progress Yes (add No (DIY) No (DIY) In progress Yes (add seamless state reuse HTML rendered during fluxible) prerendered) transfer (M) serverside framework execution without incurring an additional rerender? Serverside Can an app written to run in the client Yes (builtin) Yes (add No (add Flux DIY with Yes (add Yes (add Yes (add rendering of app be rendered in the server without code fastboot) impl and DI Nashorn, rendr) server) prerendered) itself (M) changes? Doing this requires tool) Rhino, or ecosystemwide coordination around Node.js e.g. datafetching and build tools. Small payload Large frameworks incur an initialization 168KB 217KB No data 37KB 45KB 49KB 25KB size: TodoMVC cost and deplete mobile batteries (min+gzip@le (min+gzip@le (React needs (min+gzip@le (min+gzip@le (min+gzip@le (min+gzip@l JS as of 12/29 faster. Smaller file sizes mean less JS vel=9); code vel=9) addons) vel=9) vel9) vel=9) evel=9) (M) to download, interpret and execute, size is p1 whether on the client or the server. All before end of frameworks are deeply concerned with beta this (esp. globallyfocused Google and Facebook), so this may be a nonissue in the medium term. Execution An ideal framework should execute No data 780ms 308ms 266ms 204ms 344ms 131ms performance: common application tasks (such as (1.4.0 with (0.10.0) (0.16.0) (1.1.2) (1.2.14) (3.1.0) TodoMVC (M) those found in TodoMVC) quickly. Leo Handlebars Horie (Mithril) benchmarked some of 1.3.0) these against a single TodoMVC app, but this relies on outdated releases. Read more about benchmark reliability. Interoperability Frameworks that encompass the entire Entire page Entire page Entire page Entire page Entire page or Entire page Entire page (M) page rather than only encompassing or parts of or parts of or parts of or parts of parts of page or parts of or parts of portions of the page are less page page page page page page wellsuited to a progressively decoupled approach, as Drupal would need to cede all control over renders and would be unable to render parts of the page in PHP/Twig. Template A declarative approach could be Declarative Declarative JSX (string Declarative Choose your Declarative Declarative engine beneficial to progressively decouple within DOM within DOM templates); syntax own (string within DOM within DOM friendliness for UIs that are still migrating, while (ng) and (data JSX is through templates) (ng in flat or string Drupal themers stringbased templates are ideal for string ember) and optional but elmhtml HTML) templates (M) larger page components. How friendly templates Handlebars strongly rec’d is the templating system for Drupal (string themers? Does it work well for templates) interpolation into existing Twig files? Code structure A framework’s opinionatedness about More Most Less Not Less More Less unopinionated application structure means easy opinionated opinionated opinionated opinionated opinionated opinionated opinionated ness (M) optimization, but it may be overly (framework (framework (library (language). (library (framework (library restrictive for an approach that favors approach) approach) approach) Suggested approach) approach) approach) “pick and choose” (library) over “the project whole nine yards” (framework). structure. Software Drupal is free software using a GPLv2+ Apache 2.0 MIT BSD (free BSD3 (free MIT MIT MIT licensing (M) license. An ideal framework would be (compatible forks not forks not compatible with this licensing, insofar w/ GPLv3+) required) required) as it can be distributed singly with Drupal. Patent rights An ideal framework should lack a None None Restrictive None None None None (M) restrictive patent clause that prevents its use under unrelated conditions. Clientside Clientside routing provides full URL Builtin Builtin reactrouter elmrouterha Builtin Builtin DIY routing (M) support for SEO, back button (3rdparty sh (various functionality, and bookmarking. The library) 3rdparty lack of this makes navigation less elmroutepar libraries) easily introspected and breaks a ser fundamental aspect of the web. Nestable Nestable components are important for Yes Yes Yes Yes No Yes Yes components (M) elegant decomposition of complex UIs (marionette) (.component into manageable hierarchies of smaller method) portable, encapsulated pieces. Also see “Future readiness” below for discussion of Web Components support. Robust state The framework’s state system should Model diffing Value diffing DOM diffing DOM diffing Manual Model diffing View model management not trigger a full DOM rerender, which (with JIT (Handle (Virtual DOM) (virtualdom) rerendering diffing (with (M) is bad for performance. Instead, it compilation) bars) observables) should perform partial rerenders (only those components that have changed). Using DOM diffs off the page instead of model diffs may be a performance bottleneck. Robust REST Frameworks either have builtin syntax Builtin (in Builtin Add fetch or Through Builtin but Builtin ($http Manual AJAX support (M) for REST calls or enforce the use of progress, isomorphic elmhttp syncs with for broad (knockout. jQuery (dependency) to fetch data from better after fetch (maintained server (no AJAX, mapping or a service. Some eschew optimistic beta) by author of optimistic $resource for $.ajax) feedback by saving clientside data Elm). feedback; no RESTful only once the server request is sent, offline; APIs) not ideal for apps in disconnected overridable) environments (mobile or offlinefirst). Testability (M) Can we test our code using small, fast Good Good Good (also Good Poor (DIY) Good Poor (DIY) unit tests, using standard offtheshelf unexpectedr tools, without excessive mocking? How eact) well does it work with Drupal testing? Data binding Twoway data binding allows for data Oneway data Twoway Oneway Oneway None (getters Declarative Twoway (M) updated from either the view or the binding data binding data binding and setters; twoway data data binding model to be reflected in the view, but it (oneway (ReactLink DIY) binding often has a detrimental impact on data binding for twoway) performance. Oneway data binding will be default allows for a solely unidirectional flow in 2.6) and is usually adequate for most apps. Large Corporate sponsorship or a large Large Large Large Small Medium Large Medium community, backing community help maintain a (Google) (Facebook) (Google) ecosystem (S) robust framework. A large ecosystem entails extensions, plugins, and other incidental projects that aid developers. Maturity (S) Has the framework seen substantial Least mature Mature Most mature Least mature Most mature Most mature Mature adoption from many large enterprises? Also, does it have a long history of effective use in production? API docs and Not only does the framework need to Average Good Good Good Good Good Good learnability (S) have an accessible learning curve for (better by end Drupal developers; frontend of Q1 2016) developers need to be able to use the framework efficiently and to integrate easily into the Drupal community. Debugging Developers desire a pleasant batarangle Ember devtools Timetravel Debugger batarang chromeexten experience (S) debugging experience such as a tool Inspector debugger sionsknocko that aids not only in isolating errors and utjs (low warnings but also a comprehensive usage) inspector for the structure and execution of the application. Error handling Developers require robust error TypeScript Builtin DIY Strongly and DIY (no error Builtin error Builtin and reporting reporting (e.g. compiler errors, runtime (statically .onerror (3rdparty statically handling handling .onError (S) errors) to aid their debugging process. typed): both method (also libraries) typed, OOTB) method An ideal framework would provide compiletime clihoneybad excellent exhaustive and helpful error reporting and runtime ger) compiletime that minimizes blocked tasks. errors errors, practically no runtime errors Native app Frameworks increasingly have as part NativeScript clicordova React Native In progress None (DIY) Ionic None (DIY) support (N) of their ecosystem the capability of Ionic 2 (HTML5 to compiling singlepage JavaScript React Native native) applications into native mobile applications written in Java and ObjectiveC. While this does not affect progressive decoupling (unless there is serverside JS), it is useful for full decoupling. Future An ideal framework should have a plan Excellent Excellent Average Excellent Poor Poor Good readiness (N) in place to either provide a polyfill for or (ES6 support, (ES6 support, (Maple.js for (WClike directly support Web Components, WClike WClike WC) syntax) Shadow DOM, and upcoming versions syntax) syntax) of JavaScript (ES6, ES7).