5 ms·

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

by 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.
  - Offler 13y ago
    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 13y ago
      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.
- michaelmior 13y ago
  Don't forget the XML :) Seriously though, the project does look pretty cool.

by 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.
- Offler 13y ago
  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 13y ago
    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.
michaelmior 13y ago
Don't forget the XML :) Seriously though, the project does look pretty cool.