
BladeRunnerJS: Divide and conquer complex web apps - porker
http://bladerunnerjs.org/
======
sivers
"There are only two hard things in Computer Science: cache invalidation and
naming things." \-- Phil Karlton

Congrats on conquering half of that. BladeRunnerJS is a _GREAT_ name for this
project/service. :-)

~~~
camus2
> BladeRunnerJS is a GREAT name for this project/service. :-)

no it's not. Doesnt sound professional,and some people might hate the Movie.

most js libs have stupid names anyway,not sure why.

As for the project itself,i'm sure it's an excellent lib,but i hate these DSLs
that dont make sense. Why call something a "blade" when you could call it a
component or module for instance?it's just confusing and dont help understand
what the framework is about. Naming things the right way is important.It means
you got your domain logic right.

~~~
leggetter
> Why call something a "blade" when you could call it a component or module
> for instance?it's just confusing and dont help understand what the framework
> is about. Naming things the right way is important.It means you got your
> domain logic right.

"component" and "module" are vastly over used in software development so we
went with something that was unique and works well with the unique concept
we'd developed (~3 years old now). "framework" suffers the same over-use
problem so we're probably going to remove that from the intro paragraph.

We specifically went for "Blade" as it works well. Blades represent a vertical
_slice_ of application functionality, from UI to interaction with a service
layer. Blades contain all the assets (JS, CSS, HTML, config, images) for a
single feature grouped together on disk.

BRJS is much more about structuring your application and enabling a workflow
that ensures a large and complex JavaScript application is maintainable. It's
primarily an extensible toolkit with some core conventions e.g. scaffolding,
Blades, Workbenches, Aspects, code dependency analysis for bundling for all
asset types etc.

Right now we support writing code in a Node.js-style similar to that which
Browserify enables (CommonJS + addition export support) but in the future the
toolkit will allow us to move to something like ES6 or maybe TypeScript. We
presently have Knockout as default in the Blade templates but we plan to add
support for other template types such as Angular, Ember and Web Components
(with Polymer). Until we add custom template support it's a small manual step
to use these instead of Knockout.

We're only at v0.5 so many things are still evolving, including refining how
we describe what it does and the benefits.

This is all useful feedback. So, thanks.

~~~
syntern
> a large and complex JavaScript application is maintainable

Can you describe the size and complexity of the apps that you have done with
this framework?

~~~
CWIZO
[http://bladerunnerjs.org/blog/large-scale-complex-
javascript...](http://bladerunnerjs.org/blog/large-scale-complex-javascript-
apps/)

------
sideproject
I could say "oh man, another framework/library/tool for building JS
applications" \- how do I keep up?

But I guess I'd better ask a more constructive question.

Is this similar to "Reactjs" from Facebook?

On a higher level, is this a more 'trending' approach to build large JS apps?
(e.g. there is also a google Polymer project right?).

Seems like we are moving away from the BackboneJS, EmberJS, AngularJS type of
approach to a 'compartmentalized' or a component-based approach?

~~~
CWIZO
BRJS isn't a JS framework as such. It's a development environment that helps
you organise your code and generally makes the development of large (really
large) JS apps easier for teams. Plus other goodies :)

You can use whatever JS framework you want. It does however come bundeled with
Knockout and Presenter (which is based on knockout).

Disclamer: I work for Caplin which is the author of BladeRunnerJS

~~~
antihero
So do you use it _with_ other frameworks, for instance ReactJS?

Which part of the "stack" does it replace - the build toolchain? Organisation
methodologies? Or "frameworky" stuff like the design pattern?

It's just I vastly prefer the current ReactJS way of doing stuff to simple
data-binding, so I'm rather sceptical of switching away from it.

~~~
CWIZO
Internally we use it with Knockout/Presenter, but you could use any other
framework.

BRJS is "just" about organising things, build toolchain (to an extent) and it
also provides some libraries like emitter, service/alias registry, etc. But
you don't have to use any of that. We are working on putting JsDocs on the
website (they are there if you download it), that will hopefully make it more
clear on what's included.

If you are interested we do have som edocuments on the page explaining all the
concepts in BRJS.

------
al2o3cr
If you hit Reload on a page that uses it, does it give you a soliloquy about
tears in rain? ;)

~~~
at-fates-hands
This gave me a good laugh this morning. Thank you.

------
wlievens
Strongly reminds me of Martin Fowler's articles on Microservices.

~~~
ollieglass
[http://martinfowler.com/articles/microservices.html](http://martinfowler.com/articles/microservices.html)

------
syntern
Everything inside a huge data-bind="" attribute? Man, that becomes crowded
pretty soon (e.g. binding the label and the onclick with just a "," separation
is just the simple case, 4-6 binding is not unusual on a single component).

~~~
leggetter
Right now we use KnockoutJS in the Blade templates. the `data-bind=` syntax is
from that. There's not reason you can't use another front-end UI binding
library with a syntax that you prefer.

This response provides more about why the front-end library isn't core to what
BRJS offers:
[https://news.ycombinator.com/item?id=7429659](https://news.ycombinator.com/item?id=7429659)

------
marcosscriven
I used Caplin tools a couple of times years ago - they used the same 'blade'
terminology then - looks like they've just open sourced the UI stuff, to make
it easier to sell their data distribution tech.

~~~
leggetter
It's mainly a re-write of the older toolkit. Open sourcing has many benefits.

As lead of the open sourcing initiative (not lead-dev) it's been an
opportunity to re-evaluate what we're doing and a way to identify things that
may change in the future e.g. we used to write JS in along namespaced style.
This was - to be honest - nasty. We now use a node.js style, but because we've
identified that as something that could change, we have a plugin for that area
which means we can move to ES6 or TypeScript if we want to in the future.

It's also been a great way to look at what else is out there, can it address
our needs and how can we incorporate it. The obvious thing here is Node.js v
Java. We originally chose to write our toolkit in Java as Node.js wasn't
around and later on because Node.js wasn't an option for our customers. That's
changing so we're looking at Node.js integration. We obviously want our own
developers and those of our customers to be able to take advantage of the
amazing tools available in Node.js. Java 8 is making things look very good in
this respect.

From the point of view of the company there's no doubting that we hope open
sourcing will have a positive business impact. The toolkit does enable a very
productive workflow when multiple teams are building large JavaScript apps. We
built this to solve problems that we were having and that our target customers
are likely to have. It's also going to be continually maintained as both our
own dev teams and those of our customers will use it.

The UI stuff (Presenter) has been open sourced but we've actually decided to
go with KnockoutJS by default as it simplifies the onboarding process. As per
this comment
([https://news.ycombinator.com/item?id=7429659](https://news.ycombinator.com/item?id=7429659))
BRJS is much more about the toolkit supporting an application structure.

------
amix
I like the general idea of this project. I think tho' it smells like a
enterprisey Java project that's coded in JavaScript (at least by looking at
the code and how things are structured).

~~~
mattgreenrocks
> it smells like a enterprisey Java project

I'd hope you'd have something more constructive to say.

I'm not saying enterprisey is good, but, damn, evaluate it based on the actual
design, rather than running away screaming because it uses IoC and
publish/subscribe.

~~~
amix
I am evaluating it on design and I think the design looks more like a Java
codebase than a JavaScript one. I don't think this is a positive thing since
you should not try to emulate Java idioms in JavaScript (or vice-versa).

A small example is usage of XML files for configuration of aliases. Very few
people use XML files in the JavaScript world - - while it's almost a standard
for Java projects.

In general, the more I look at the codebase the more messy it looks like. They
could have built something much simpler that solves the same problem.

~~~
Offler
It was basically create by people who didn't have much JS experience so that's
why it looks like Java more then JS, in fact that's why it's Java and not
node. You're right it could have been much simpler. It used to be much worse.

~~~
andyberry88
It was created _for_ people without JS experience, specifically Java devs that
moved from back end to front end teams to write webapps. Things have since
moved on and we're bringing the coding style, among other things, more inline
with new practices.

The tooling itself is Java since a lot of Caplin's customers still have't
adopted Node, in fact some of their ops departments are completely opposed to
it, and just because it isn't written in the same language as your front end
code does't mean the tooling and principles are any less valid or useful.

------
caseydurfee
How does this project fit in with the web components standard? Seems like you
would want your nomenclature/long term direction to be in line with that. This
is an interesting project, but as far as the battle for mindshare goes, I'd be
betting on Mozilla/Google...

------
otikik
> open source development toolkit and framework

It looks like a framework to me, not a toolkit.

[http://i.imgur.com/94pUoco.jpg](http://i.imgur.com/94pUoco.jpg)

------
smrtinsert
Just a quick glance at this - are they essentially js portlets?

~~~
syntern
This was my quick conclusion too. The app they have built is is very portlet-
like, anyway. Nothing wrong with that, but I don't think it suits every need.

~~~
leggetter
yeah, we have focused on building dashboard like solutions. However, we're
undergoing a number of mobile projects right now and we're hoping that part of
open sourcing will result in trying to build other types of apps. Hopefully
it'll be a learning experience; what works and what doesn't.

I'm hopeful that BRJS will have wider applicability since Blades are
conceptually similar to Web Components and I'm sure the hope is that they are
widely usable.

We'll see!

~~~
syntern
Why not just use web components?

~~~
leggetter
We started doing this around 3 years ago. It's likely we'll change our default
coding style from Node.js style to ES6 and our front-end components to Web
Components - browser support pending.

However, Web Components won't remove the need for a service layer which is
also provided by the default BRJS runtime or the encapsulation of tests, i18n,
config and other resources within a Blade.

Demonstrating how to use BRJS with Web Components (Polymer) is most definitely
on our TODO list.

