4 ms·

"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton Congrats on conquering half of that. BladeRunnerJS

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

by sivers 13y ago

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