7 ms·

BladeRunnerJS: Divide and conquer complex web apps

70 points by porker 13y ago

wlievens 13y ago
Strongly reminds me of Martin Fowler's articles on Microservices.
- ollieglass 13y ago
  http://martinfowler.com/articles/microservices.html http://martinfowler.com/articles/microservices.html
sivers 13y ago
"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. :-)
- shultays 13y ago
  It is not trademarked or something?
- camus2 13y ago
  > 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.
  - mbesto 13y ago
    > Doesnt sound professional,and some people might hate the Movie. Glad you brought this up...this is a great discussion point! The most important aspect in naming a language/framework/library is the ability to Google it. The second one is being able to remember it. I think BladeRunner does both of those really well (regardless of your personal convictions about "professionalism" and distaste for the movie...)
    - leggetter 13y ago
      It was initially called "BladeRunner" and one of the main reasons we decided to rename it "BladeRunnerJS" was for Google. As with other JS-based solutions adding "JS" to the end clarifies it's for building JavaScript apps. We've had a lot of positive feedback about the name so all-in-all I think it was a good choice.
  - leggetter 13y ago
    > 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 13y ago
      > 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 13y ago
        http://bladerunnerjs.org/blog/large-scale-complex-javascript-apps/ http://bladerunnerjs.org/blog/large-scale-complex-javascript...
- DanHulton 13y ago
  "...and off-by-one errors."
sideproject 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
  - hmsimha 13y ago
otikik 13y ago
> 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
amix 13y ago
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 13y ago
  > 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 13y ago
    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.
    - leggetter 13y ago
      It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support. However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that. So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes. For example: - encapsulation - separation of concerns - interfaces (In JavaScript: arrgghhhh!) - think contracts (function names and signatures). We've had lots of discussions about this but them continue to delivery value when building a maintainable app - services via an IoC/Dynamic Service Locator (see Angular) - PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful All these ring of enterprise. But they're actually just good and simple software engineering practices. When building large JavaScript apps it's about getting the balance right and we're hoping that as part of this open sourcing project we can do that. One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.
marcosscriven 13y ago
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 13y ago
  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.
al2o3cr 13y ago
If you hit Reload on a page that uses it, does it give you a soliloquy about tears in rain? ;)
- at-fates-hands 13y ago
  This gave me a good laugh this morning. Thank you.
syntern 13y ago
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 13y ago
  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
smrtinsert 13y ago
Just a quick glance at this - are they essentially js portlets?
- leggetter 13y ago
  You could look at it that way. But I'd like it to align much more with Web Components and a defined architecture for inter-component (Blade) and service (shared resource e.g. back-end) communication. I think this comment best describes the focus: https://news.ycombinator.com/item?id=7429659 https://news.ycombinator.com/item?id=7429659
- syntern 13y ago
  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 13y ago
    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 13y ago
      Why not just use web components?
      - leggetter 13y ago
        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.
caseydurfee 13y ago
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...

70 points by porker 13y ago

wlievens 13y ago

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

ollieglass 13y ago
http://martinfowler.com/articles/microservices.html http://martinfowler.com/articles/microservices.html

sivers 13y ago

"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. :-)

shultays 13y ago
It is not trademarked or something?
camus2 13y ago
> 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.
- mbesto 13y ago
  > Doesnt sound professional,and some people might hate the Movie. Glad you brought this up...this is a great discussion point! The most important aspect in naming a language/framework/library is the ability to Google it. The second one is being able to remember it. I think BladeRunner does both of those really well (regardless of your personal convictions about "professionalism" and distaste for the movie...)
  - leggetter 13y ago
    It was initially called "BladeRunner" and one of the main reasons we decided to rename it "BladeRunnerJS" was for Google. As with other JS-based solutions adding "JS" to the end clarifies it's for building JavaScript apps. We've had a lot of positive feedback about the name so all-in-all I think it was a good choice.
- leggetter 13y ago
  > 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 13y ago
    > 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 13y ago
      http://bladerunnerjs.org/blog/large-scale-complex-javascript-apps/ http://bladerunnerjs.org/blog/large-scale-complex-javascript...
DanHulton 13y ago
"...and off-by-one errors."

sideproject 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.
- hmsimha 13y ago

otikik 13y ago

> 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

amix 13y ago

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 13y ago
> 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 13y ago
  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.
  - leggetter 13y ago
    It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support. However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that. So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes. For example: - encapsulation - separation of concerns - interfaces (In JavaScript: arrgghhhh!) - think contracts (function names and signatures). We've had lots of discussions about this but them continue to delivery value when building a maintainable app - services via an IoC/Dynamic Service Locator (see Angular) - PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful All these ring of enterprise. But they're actually just good and simple software engineering practices. When building large JavaScript apps it's about getting the balance right and we're hoping that as part of this open sourcing project we can do that. One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.

marcosscriven 13y ago

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 13y ago
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.

al2o3cr 13y ago

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

at-fates-hands 13y ago
This gave me a good laugh this morning. Thank you.

syntern 13y ago

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 13y ago
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

smrtinsert 13y ago

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

leggetter 13y ago
You could look at it that way. But I'd like it to align much more with Web Components and a defined architecture for inter-component (Blade) and service (shared resource e.g. back-end) communication. I think this comment best describes the focus: https://news.ycombinator.com/item?id=7429659 https://news.ycombinator.com/item?id=7429659
syntern 13y ago
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 13y ago
  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 13y ago
    Why not just use web components?
    - leggetter 13y ago
      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.

caseydurfee 13y ago

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...