BladeRunnerJS: Divide and conquer complex web apps
bladerunnerjs.org
bladerunnerjs.org
Congrats on conquering half of that. 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.
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...)
"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.
Can you describe the size and complexity of the apps that you have done with this framework?
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?
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
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.
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.
Is this "emacs" thing similar to django?
This response provides more about why the front-end library isn't core to what BRJS offers: https://news.ycombinator.com/item?id=7429659
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) BRJS is much more about the toolkit supporting an application structure.
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.
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.
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.
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.
It looks like a framework to me, not a toolkit.
I think this comment best describes the focus: https://news.ycombinator.com/item?id=7429659
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!
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.