A discussion around the client side stack, the current approaches taken and possible value of new technologies and standards. How broadly applicable is our stack and approach to others and the pros and cons of maintaining it. If it's even feasible to ever replace parts of it, or worth it. Also theorize on what choices a competitor would make.
The reason for this meeting was Paul Caplin wanting to understand where BR fits into an average, current front end tooling stack. The value of BR and the other open sourced projects, for average web app developers, has been questioned by some of the JS devs, including myself. Most of these points have already been covered in the emails I've sent out, so apologies for the repetition.
To help explain the doubts we can list the features and properties of BR and analyze them from the perspective of a non Caplin developer.
Currently the FxMotif still hasn't moved over to the newest BR so this analysis maybe dated.
BR's claim is that it helps you build front end apps that scale. These are some of the features it provides to accomplish that.
What BR provides
BR has many abstractions such as Aspects, Bladesets, Blades, Libs, BR Libs, Thirdparty libs etc that are claimed to be generic ideas for how to structure an application. In practice that has not turned out to be case and the BR team is working on trying to hide these abstractions from users.
Simplified application directory structure ( BladeRunnerJS/brjs#19 ) Quote from a recent email.
However, we have a few things getting in the way of adoption right now
...
b. Initial complexity (directory structure and bladesets)
...
Phil L.
This is not a new concern. Over a year ago I explained that these concepts were partly reverse engineered from our old CT2/1 codebase and not clean room abstractions. They were not driven by proven need or design they were retrofitted onto an existing, somewhat haphazard, codebase. We looked at our namespaced codebase and created abstractions around the namespacing.
The average solution
About the only generally shared concepts are a feature packages (a Blade for BR) and dependency managed packages. It seems BR is simplifying toward this structure?
Is what BR provides a killer feature for an average web app developer?
The concept of a feature package, Blade, would provide value. It's not likely to be enough to entice someone to use BR.
You don't need BR to have folders where feature functionality is centralised in feature packages. The most popular frameworks like Ember already have tools that support this structure (ember-cli), which provide better support for their framework.
The level of application structure that these tools and these frameworks allow is one level better then BR. They separate code into Controllers, Routes, Models, Services etc while BR has nothing to say about the structure of the source code within a blade.
You cannot use a Blade from another blade. If you are composing Web Components, React components, Ember components, KO components, Angular directives with each other BR will stop you.
What BR provides
BR can load JS, CSS, HTML templates and provide XML configuration bundles.
The average solution
Either Browserify or WebPack. RequireJS/AMD usage seems to be on a downward slope compared to them. Both Browseify and WebPack can do all that BR does with regards loading assets, file watching and incremental builds. I don't know about their performance for incremental builds but I've not heard anything negative.
Is what BR provides a killer feature for an average web app developer?
Loading assets is fairly low value and I see no reason to chose a niche module loader over the established and popular module loaders. BR also imposes more restrictions then the other solutions regarding namespacing and structure of code which is not an attractive feature. It's also lacking all the plugins that these other loaders have. Namespacing, to an extent, is a workaround we need due to writing non modular code. When resources aren't loaded inside a shared global context you don't need namespacing to prevent clashes.
From (one of the SPA talk repos)[https://github.com/briandipalma/spa-2014-contacts-list/blob/master/src/ContactsListElement.js]
import contactsListTemplate from '../template/contactsList.text!';
export class ContactsListElement extends HTMLElement {
// Fires when an instance of the ContactsListElement is created
createdCallback() {
...
this.innerHTML = contactsListTemplate;
...
}The above code loads an element's template within the element's module, meaning there is no need to namespace the template. The template is separate from all other templates. This is simple, transparent and more flexible compared to the namespacing BR approach.
What BR provides
This is DI (Dependency Injection). Aliases area different concept and we named it incorrectly. BR will map a token to different values given a specific loading context or configuration. Useful when creating large applications and frameworks.
The average solution
Angular and Ember have their own DI.
Is what BR provides a killer feature for an average web app developer?
If you are building a bespoke application it's not clear what use the Service Registry is to you. JS is highly dynamic so easy to replace classes for tests, a bespoke application would have one service of each type. Useful for framework creators. Angular 2.0 DI library stand alone and more powerful.
We are studying alternatives to both these libraries with a view to ceasing active development using Presenter/Verifier (?).
What BR provides
A webpage with a single component loaded in for isolated development. Can only be used in certain special BR abstractions.
The average solution
A webpage with a single component loaded in for isolated development. Can be used in any package.
Is what BR provides a killer feature for an average web app developer?
The concept of a workbench is well understood and is very simple to implement so it's not clear why a developer would use BR for that feature.
What BR provides
CommonJS modules, global code.
The average solution
CommonJS modules, global code, AMD modules.
Is what BR provides a killer feature for an average web app developer?
This is another low value feature, which will be worth even less once ES6 becomes more widely used. Ember and Angular are both integrating ES6 and there already shims for ES6 module loaders which can load CommonJS, AMD, ES6 and global code all the way back to IE8; (SystemJS)[https://github.com/systemjs/systemjs/]. I write in ES6 for almost all my free time code and it's worked fine.
-
BR lacks a dependency management story. Web is moving toward micro libraries, modules and components so downloading and updating by hand will be more painful and error prone.
-
If you are building a full Angular or Ember app it's doubtful you'd use BR, Ember has it's own tooling and Angular has a generally recommened structure for large apps. Most people building large apps will use one or the other. The people who won't are either clueless (aren't aware of these frameworks, they will contribute little of value to BR), experts (they won't use BR, they won't use frameworks like Angular or BR) people who create their own frameworks (Caplin, those people build their own tools).
-
Thought leadership, expensive and for what audience? JS web app devs will not/do not find BR attractive.
-
BR bundles a lot of libraries and many devs might not want them.
-
BR isn't a valuable skill to have on your C.V. for outside devs. Valuables skills are knowledge of popular MVC libraries and off the shelf popular node tooling.
-
We are not a special snowflake. A lot of the problems that we are trying to solve are similar to many other companies, few feel the need to build their own tooling.
An example of the error prone nature of doing manual dependency management. The SDK in FxMotif has jQuery as a thirdparty library and within it we also pasted another thirdparty library, jQueryUI. We also included that projects CSS. Here is our handwritten library.manifest (a poor version of a package manifest).
- js : jquery-1.10.2.min.js, jquery-ui-1.10.3.custom.js
- css: resources/css/jquery-ui-1.8.23.custom.css
Apart from the versions between the CSS and JS being different we are also bundling two different libraries together regardless of if you need both (ask for jQuery from BR and you now also get jQueryUI).
Also the valueable skill aspect is referenced in this JSJ podcast. It's a bit meandering so I wouldn't recommend listening to it if you are short of time.
http://javascriptjabber.com/118-jsj-web-developer-skills/
At one point though the question is asked "What skill would raise your eyebrow if it's not on the C.V. of a senior web dev?".
-
One skill was use of frameworks like Angular/Ember/React ("Angular is the new jQuery and React is the new Angular.").
-
A participant said that not yet but sometime soon he would consider node.js to be one. Specifically node.js tooling knowledge as it's the runtime of choice for building web dev tooling. He mentions his Ruby shop have started replacing the built in Ruby on Rails tooling with node.js/gulp. This is a trend I've read of in blogs which is also happening in MS/Java shops.
Most web devs are probably aware of these trends. I see no reason for that to change. The problem is a-web-dev-stack-that-won't-help-me-in-my-job.
One of the most important measures of success for an OSS project is it's community. We need to identify BR's community and explain why it doesn't seem making use of BR. While this is subjective I feel that at best the BR community would be niche.
Without a community what is the point of developing BR as a normal OSS project? What advantage would that cost provide?
Daily downloads during work week (weekends are much lower indicating these are used for commercial development).
- Broccoli (still Beta) : 250 - 550
- Webpack: 300 - 1000
- gulp: 7500 - 12000
- browserify: 12500 - 23000
- bower: 20000 - 33000
- grunt: 24000 - 36000
These figures mask a general increase in those numbers. Even something as low use as Yeoman generators are getting good monthly downloads.
Most downloaded Yeoman generators in July
- generator-angular 32.7k
- generator-webapp 14.1k
- generator-angular-fullstack 6.9k
- generator-jhipster 2.7k
- generator-backbone 2.7k
- generator-polymer 1.7k
- generator-ionic 1.7k
- generator-gulp-webapp 1.5k
- generator-wordpress 1.2k
The cost and risk would be high for a big bang style project. A more sensible approach would be a gradual move to a less homemade stack and deprecate parts of our stack as we do so. We may never be able to move from BR in our current codebase.
For newer, future projects (CT5, future mobile projects) we should investigate using off the shelf projects as opposed to defaulting to our own.
Some possible experiments include:
- Spike converting our current codebase to modules (hopefully soon underway?).
- Spike alternatives to Presenter/Verifier (underway?).
- Spike moving builds from gradle to gulp.
- Spike using test runners without BR plugins.
- Spike using package managers to provide thirdparty dependencies in our projects.
- Spike using package managers for our own SDK libraries if that works.
- Instead of creating plugins or wrappers lets try and use tools directly.
- Spike loading a workbench with Webpack or Browserify, with BR providing a REST API to return aliases data
- If BR could return the data other loaders require via REST endpoints it might allow us to quickly test them.
Soruban has spiked a Browserify build of the mobile project but it requires work.
I think it's difficult for us to make claims about the value of our toolchain if we don't invest time and resources in understanding and using alternatives. We aren't grounding our claims in experience but on our personal opinions and feelings. This is not a robust approach.