Web Beans vs. .NET vs. RoR

[gonorrhea]

How does Web Beans RI compare to productivity in .NET and/or RoR?  Seam was supposed to be RAD-style but there is very little traction/adoption in the EE community/corporations...

[gavin.king]

The Web Beans RI is 27.23% more productive than .NET.

Seriously, what kind of answer were you looking for?

Which is better, America or Australia?

[cpopetz]

The Web Beans RI is 27.23% more productive than .NET.

With what standard deviation?

Which is better, America or Australia?

Italy, obviously.

[gonorrhea]

Obviously not a smart ass remark like that.  No wonder people find you difficult to work with.  ;)

I would say America (USA specifically) is not as productive as it used to be as evidenced by the recent financial tsunami/turmoil, etc. that has cascaded into remote nether-regions like Australia.  Maybe it won't even matter by 2012, who knows...

I guess your point is that it's difficult (if not impossible?) to measure productivity gains using one enterprise framework vs. another (and even IDE vs. IDE).  So just say that and my question is rendered absurd and/or ignorant, no big deal.

But I'm glad to hear from PMuir's recent Seam3/WebBeans podcast on DZone that the WebBeans RI and Seam 3 will be much more performant than Seam 2.  IIRC he didn't mention any specifics as to how the performance will be improved...

[luxspes]

Arbi Sookazian wrote on May 27, 2009 00:10:


I guess your point is that it's difficult (if not impossible?) to measure productivity gains using one enterprise framework vs. another (and even IDE vs. IDE).

It is certainly difficult, but not impossible, look, for example, at the comparison between AribaWeb and RoR here. They easily show that AribaWeb can (sometimes) create an application very similar to a RoR one with 100X less code. I know this comparisions are only applicable for the particular kind of application compared, but they can give you a good feel about the framework.

I would love to see more comparisions between Seam and other frameworks, if only because that helps keep everyone in perspective (it is so easy to think you have built the greatest framework if you never compare it with anything else).

I feel like Seam had a good start, greatly simplifying the JPA/JSF/EJB/JEE mixture, but after that, when compared with solutions that do not need to deal with the burden of those standards, its capacity to reduce development effort is not evolving as fast as it should be.

  So just say that and my question is rendered absurd and/or ignorant, no big deal.

Your question should have been more specific, but Gavin's answer was not that great either ;)

[nickarls]

I think Pete can do that presentation in his sleep by now ;-)

Most performance gains will probably come from the lack of the bijection interceptors and its relatives. Bear in mind, though that the performance of Seam 3 will probably not be quite as good as a plain numberguess in Web Beans due to interceptors that will have to be included in most cases. But I guess those will dynamically be kept to a minimum

[luxspes]

Nicklas Karlsson wrote on May 28, 2009 12:20:


I think Pete can do that presentation in his sleep by now ;-)

Most performance gains will probably come from the lack of the bijection interceptors and its relatives.

That sound great, but I worry more about functionality, about the effort required from the developer (me) to build a performant application, for example, will Seam 3 have programmatic (in Java) page navigation? will it be a priority to have a nice API for everything that can be done with XML descriptors or declaratively with Annotations? I mean, XML and annotations are nice, but more often than not one needs to customize the behavior of things to make them work for the particular solution being built, and that, with Seam 2, is really hard, and very often it can only be done by patching Seam internal code. Will Seam 3 be more modular so that I can plug my own conversation manager, navigation manager, remoting manager, validation manager, or  whatever other manager I like? I know extensibility points need to be defined (you can not make it possible to replace anything but I really hope Seam 3 is a lot more flexible than Seam 2

Bear in mind, though that the performance of Seam 3 will probably not be quite as good as a plain numberguess in Web Beans due to interceptors that will have to be included in most cases. But I guess those will dynamically be kept to a minimum

I as long as they can be statically kept to a minimum, programmatically (if it can be done declaratively, that is nice, but not a requirement) that is using Java, without having to write a single line of XML, I will be happy.

[nickarls]

I would find it surprising if those managers (or whatever they will be called) would not be pluggable. I my opionion, there would have to be a specific reason why not to allow for it...

[pmuir]

Much of this stuff is pluggable in Seam2, by simply creating your own component that does the work, and putting it in at higher precedence. I think what you saying though, is that you want a more clearly defined API, where what is pluggable and what isn't is more clearly separated. This is the case in WB.

Nik is right about why 299 performs better, but also because we learned our lessons (design and impl) from Seam, and applied those.

[gonorrhea]

Nicklas Karlsson wrote on May 28, 2009 12:20:


I think Pete can do that presentation in his sleep by now ;-)

Most performance gains will probably come from the lack of the bijection interceptors and its relatives. Bear in mind, though that the performance of Seam 3 will probably not be quite as good as a plain numberguess in Web Beans due to interceptors that will have to be included in most cases. But I guess those will dynamically be kept to a minimum

So if your project does not need Seam added functionality/services like PDF, Excel, email, remoting, seam-gen, seam UI tags, etc. and performance is a very critical NFR (non-functional requirement), then is it advisable to use the Web Beans RI or other implementation for EE 6 app rather than Seam 2 or Seam 3?

Or will Seam 3 have the performance enhancements and no bijection (outjection anyways)?

And I watched Pete's recent demo and he didn't get into specifics on the performance optimizations other than the interceptors IIRC.

What specifically in Seam 2.x in terms of design and implementation are the performance bottlenecks and how have those been addressed in Web Beans and/or Seam 3?

[luxspes]

Pete Muir wrote on Jun 01, 2009 16:47:


Much of this stuff is pluggable in Seam2, by simply creating your own component that does the work, and putting it in at higher precedence.

Well, yes, but sometimes the methods you want to override are private... and there is no a lot (or at all) HOW-TO documentation on creating you own managers, or a detailed description on how they interact and why things are done the way they are...  (I guess I would like something like a book with the title Hacking Seam without messing with its internal code with examples like for example,a new custom ScopeType, or all pages.xml configuration being read from a database instead of XML files, or 100% programmatic navigation).

I think what you saying though, is that you want a more clearly defined API, where what is pluggable and what isn't is more clearly separated. This is the case in WB.

Exactly, and it would be great if it included modular plugin-like examples, that,  even if they do not do much, alter Seam internal behavior but at the same time are in independent jars, completely separated from the core.

Nik is right about why 299 performs better, but also because we learned our lessons (design and impl) from Seam, and applied those.

What worried me a little about this is backwards compatibility...I hope it is not extremely hard to port an application from Seam 2 to Seam 3.

[gonorrhea]

Francisco Peredo wrote on Jun 01, 2009 21:46:


What worried me a little about this is backwards compatibility...I hope it is not extremely hard to port an application from Seam 2 to Seam 3.

I'm worried about this as well.  For example, would you use @In in an existing component and @Current in a new Seam 3 component in the same project?

Deprecation, etc.?

[nickarls]

I think that most stuff that can be broken out into components will be as usecases are presented (since bean wiring is cheap in 299)

Depending on how your application is built, I predict YMMV from trivial to non-trivial ;-) For stuff that has changed (entities not Beans, no outjection, no direct context manipulation etc) I'm sure there will be documentation for mapping from oldskool concepts to 299 (producer fields etc)

[nickarls]

Well, most modules will automagically work if they are dropped in and are disabled if not present. So if you are disabling all Seam 3 features because of performance concerns, you will be left with the 299 core so yes, in that case you can just use WB and save yourself the 100Mb download and stripping process.

But I suspect most real application will use at least some of the Seam 3 modules, such as JCDI4EEMPC

[pmuir]

Francisco Peredo wrote on Jun 01, 2009 21:46:

Pete Muir wrote on Jun 01, 2009 16:47:


Much of this stuff is pluggable in Seam2, by simply creating your own component that does the work, and putting it in at higher precedence.

Well, yes, but sometimes the methods you want to override are private... and there is no a lot (or at all) HOW-TO documentation on creating you own managers, or a detailed description on how they interact and why things are done the way they are...  (I guess I would like something like a book with the title Hacking Seam without messing with its internal code with examples like for example,a new custom ScopeType, or all pages.xml configuration being read from a database instead of XML files, or 100% programmatic navigation).

Well none of these things are actually supported in Seam2, hence why you can't do it. But simply dropping comments into forum threads doesn't work. Create a JIRA, clearly explain what you want, and what the use cases are, then see if it's a popular idea. If it is, then implement it, and if we like it, we will apply.

But for these specific feature requests, custom contexts are possible in Seam3, a programatic navigation API for JSF isn't planned (maybe for JSF 2.1), but we could look at doing this as a Seam extension. File a RFE in JIRA.

What worried me a little about this is backwards compatibility...I hope it is not extremely hard to port an application from Seam 2 to Seam 3.

We will provide both a bridge (inject your Seam2 components in WB) and a emulation layer (run your Seam2 app on WB - this should require minimal changes to your app, though if you are using odd APIs, it may require some fiddling).