Re:holy random comparison batman
on
JSF vs ASP.net
·
· Score: 1
Because both of them have ides in front of them which provide a visual paradigm. The article in my opinion was less a comparison of technologies and more a comparison of what you can do with a decent IDE quickly (In case of.Net it was Visual Studio.Net and in case of JSF it was the Studio Creator EA2!)
with some explanations about the underlying techs.
The funny thing is the control comparison, because many of the controls shown are not part of the JSF core spec but are provided by the Studio Creator (but almost any component pack which nowadays is used has similar controls)
Re:Have you considered WebObjects?
on
JSF vs ASP.net
·
· Score: 1
If you mean with alternatives EJB2 and pure then yes, if you mean with alternatives something like Seam+Facelets+JSF+Extensive component lib, or s/seam/ejb3
or s/seam/spring/hibernate then definitely no!
Or if you subsitute xcode with something like Studio Creator 2 EA2 then definitely no. Do not get me wrong, WebObjects was groundbreaking, but it is mostly Apple to blame for that we now all code with other technologies not WebObjects.
All the web stuff now is there where Webobjects has been around 2000 but the problem is, WebObjects mostly still is there where it was 2000 with small additional fixes and enhancements, while the rest of the bunch slowly but surely bypasses Webobjects, and XCode by miles!
Re:More than two options...
on
JSF vs ASP.net
·
· Score: 1
Good luck getting clustered transactions and other important things like maintainability over dozends of coders code with php or rails in any way...
Sorry to say that but both php and rails are great frameworks but there are areas where you cannot choose both of them!
JSTL...
well, the issues are being adressed in JSF 1.2, to my knowledge only one issue really exists, which is JSF foreach, a construct which in 99.999% of all cases can be replaced with a tighter dataTable or dataList
c:if normally works fine, but is not needed because every component has its own render attribute which can be combined with the jsf el.
The rest is less verbose than struts, formatting there is an h:outputFormat component for formatting, validation is done within the form not from an xml file, the component libs already are very extensive, so programming a page with an html editor several date pickers and a scrollable data table with various links and actions is just a few lines of code.
And the xml also makes way more sense than in struts.
Sorry to say, that struts really shows its age, and almost anyone I know who knew newer frameworks and then had to move to Struts jobwise, cursed left and right for weeks.
I have been through 5 jsf projects, and I do not want to miss it anymore (although I agree the first project was rough)
Actually the exception stuff is dependent on the implementation
the post centricness is not really that true, yes there is lots of http post, due to the fact that post scales better than get, but you can do links with normal links (there is a h:link or something even in the standard codebase)
as for post problems, like back button, the back button issue is solved in MyFaces and the ri, by simply restoring the state on a back.
javascript is not mandatory for form posting, only command links use it due to the fact that it has multi action per form out of the box and doing such a thing without javascript is close to impossible, due to the limitations of html.
If you need an alternative to this mechanism use a command button.
The benefits you get however are huge, rich component sets, very tight markup template code, scoping (via extension frameworks and extension components), etc...
I think in the end the benefits of JSF outweight the few disadvantages (after all we are still at the second revision of the standard) it currently has by miles.
As for the post generally, it is nothing in the standard which would prevent the implementation of a getter form and getter command link, but the mere fact that hundreds of components even the most obscure existe and nobody has done such a thing shows that such a thing is not really needed that much.
Not really, unlike ASF.Net JSF is just a specification, you get stuff like date controls file upload controls etc usually from component packs.
If you want a good out of the mill solution in JSF with most components you need, start with MyFaces.
The usual mistake many people do with JSF is that they just look at the RI and then dismiss it as all there is, while literally hundreds of components linger around on the net for free and about the same amount in commercial solutions.
You do not need to be an uber organization to have needs for something like transaction and thread safety and having scalability on your hands.
The money also is a non issue since you can get excellent app servers for free nowadays, the tools also do not cost a fortune.
No need for xaml there are others already which basically do the same, after all xaml is just copied and derived from xul, but besides xul there are java applets and have been for years, and there are several flash based rich client frameworks.
Well, Frameworks like tapestry are pretty server agnostic as well all they need is a valid servlet/jsp runner.
The reason for this simply is that servlets/jsps have become the base technology for such frameworks, there is no use in providing your own servlet clone, the technology is mature and stable and dozends of implementations many of them free can be downloaded from the net.
The last framework I have seen not doing this was around 2000 (and that one was utter cr***).
Everything except Struts in the framework space has been derived from Webobjects (and thus Struts is such an utter.... )
Webobjects is one of the things were things have been done right from day 1.
Having business facades which can be used locally and remotely, having a web ui framework which allows heavy componentization, having a decent orm mapper to bridge the gap between an oo language and the db and having tools in place to gap the bridge between programming and visualisation.
I agree you have to give WO the credits it deserves, it has been and still is the most influental of all frameworks in this area and the first one as well.
Without WO we would not have Tapestry, no JSF, no EJBs etc...
The main problem with WO is that its main problem always was and is apple, while the other competing derived technologies have moved on both frameworkwise and toolwise, Apples role always was problematic, it was held back by licensing for a long time, the tools have been surpassed by EJB based tools for years now and the framework has been stagnante for a while as well.
In the open java world things are moving now towards EJB3 the first EJB incarnation now totally surpassing the backend and middleware side of Webobjects technologywise. And in the frontend side things are moving towards JSF a technology also superior to webobjects.
And Frameworks like Tapestry which are clearly derived out of WO nowadays are leaps ahead of it.
Typical case of having Apple (in this case NeXT) developing something superior and leaps ahead of everyone else for years and giving it the slow death due to licensing and lazyness issues.
I agree the whole web development paradigm is utterly broken and giving this idiocy entirely the boots and unlearning the people who learned this dreck will take another 10 years.
Fortunatly there are at least some frameworks which try to brigde the gap between having a decent ui programming model on top of the broken paradigm.
Tapestry is one of them html.net is the other JSF being the third.
But most frameworks try to go along the route of plain actions and boilerplate mvc on top of it without any event mechanism and componentization that is one thing which I really call idiotic.
HTML webapp programming has pushed back application programming at least 20 years, alternate technologies are there which could be used (applets, xul,...) but they are mostly ignored and now we get the next boilerplate idiocy instead of fixing the system (ajax) and then Microsoft will wipe the W3Cs backside with their xaml system which was derived out of xul and will fix the probelm and everybody will be wailing and in the end we will end up with 3 incompatible next gen html replacements and have to bridge them again with frameworks.
The whole thing reminds me on the early eighties when people moved over from plain vt220 rendering to rich client uis and everybody had its different technology and you had to bridge the gaps again with frameworks.
J2EE Servers:
You can get following without any costs:
JBoss, Jonas, IBM Websphere Community Edition, Sun Glassfish, Apache Geronimo
Buggyness, not very buggy at all, most of them are very mature.
Complexity: Unfortunately yes it is there, but they cover a lot of domains, some of them have even integrated databases, security, clustering, messaging, remoting, webservices etc... you get this all out of the box
JSPs only are a small subdomain of J2EE JSP in fact ist the only thing very close to PHP and nowadays normally only used as a rendering technology for more extended stuff. Using plain JSP basically has been a no go for years now.
Check out stuff like Tapestry, JSF etc... this is stuff people nowadays work with.
Depends on the domain, first the "will it" it has and has for a long period of time. The domain of those applications usually is in the areas which is bigger than the usual hackish php app. Java is very common in banking insurance company, fortune 500 etc... domains, you knoa what I mean.
But for the average I need a quickly hacked page in two days page you wont find it that often.
Also with those languages probably nmost I learned php in 20 days and stuck with it people will get huge problems, you run into things you have not dreamed off probably. You will face the same problems all visual basic guys had when they suddenly had to move towards VB.net, you will have to learn the basics of algorithms and software engineering.
To make it short, PHP is good for small apps which you need to hack quick, where java frameworks usually due to the setup problems is dreadful, but once things become bigger java scales quite nicely both from a development point of view and from a speed point of view. Therefore it has become the choice for many bigger applications and companies where the I need something within a day problem does not apply to usually.
Sorry to jump the gun here, but I had a quick check on seaside, and I must say, a controller->ui on the code level scripting framework does not make it.
I have been programming with such a thin in java for a while now (being forced too), while it is excellent in the areas of having one standardized domain of problems, mainly backend applications which do not require excessive ui layout and excessive ui changing, it simply does not make it in normal day to day situations, where usually a layout comes from somewhere else and you have to make it dynamic. There is a reason why almost any controller only based framework has died out and the reason is they simply do not make it, templating nowadays is a must, sorry to say that.
Depends, some frameworks just solve general problems but do not bring anything to ease the html pain, in fact they make things even worse, Struts is the perfect example.
Some frameworks allow to ease the most general things Turbine is the perfect example for that.
And some frameworks bring componentization and general patterns and really ease things as soon as you have broken out of the html context thinking, which are for instance JSF and Tapestry but also Wicket comes to my mind.
The main problem is, that almost everybody seems to think he has to program his own framework and then utterly fails in simplification or other areas instead of trying to improve the existing ones. Now we have the situation of around 100 frameworks or more, most of then do not bring anything new to the table but also most of them being only half baked. Only a handful really shine,
that probably on the java side being
Wicket
Tapestry
and JSF
Struts, forget it it is a major pain in the lower backside and almost every line of code you save on the java side ends up in two lines of code on the xml side.
Actually it is better and worse. First of all Java is quite nice to use on those phones, but you run into myriads of small issues.
First there is speed, like Carmac said you have such a huge diversity in speed that you have a range of 1-20x speedwise over various phones.
Secondly there is the jvm version problem. While most mobile phones should be on newer midp levels which have standardized interfaces for networking, sprites and sound (the most important stuff for 2d gaming)
you have still phones which are on early midp levels which means you have to revert to self written sprite routines, vendor level networking apis etc...
Isolating this stuff into a common api is useless because on the older phones you have so many constraints memorywise, that the whole thing feels like programming for a C64 but in a more decent language.
The 3d part also was mentioned by Carmac which still is an issue, 3d chips for cellphones are widespreadidly used at least 2-3 years away.
To comment on this even more, most of the java needs so much ram situations I have seen the last few years came from the typical we allocate as much as we need without a second though patterns, and then everything was blamed on Java.
Reading a 500 meg data file into ram before dumping it into the DB and then blaming it on java was such a typical situation!
Those patterns often are very similar, and often are caused by some whiz guy who thinks he knows everything better than the rest of the world!
Sheesh...
xMx 1563 for your portal, you guys should seriously check your code, I have been running a portal server on plain 128m for years with no downtime at all.
Depends if you run into a C fallback or not, most of the times you do not.
Here is an example, PHP is the perfect example of what you mentioned, now the Caucho guys have moved PHP onto resin into a JVM it got a speed boost of 6x over a plain lamp configuration on the code level.
(Most of the performance of the typical webapp goes down the drain during db access)
Sorry to say that but I once did a project with TCL and it was a joke of a lanugage, on OO, no possibility for namespaces etc...
the only merit of it was back then the TK library which made X-Windows interfaces easy to program (but only small ones, as soon as things became more complicated you ran into hell)
Given the fact, that it has been some time, and things might have improved enormously, but even back then with Lisp, Smalltalk, Perl, Python and others already in existence, TCL was a joke of a language.
Marketing mumbo jumbo,.net has forced some changes in C++ and other lanuages which sit on top of it, the JavaVM even has more languages
running on top of it than.Net has, after all a VM is just a VM a virtual processor emulation layer, the rest is marketing.
Slashdot Mirror
Because both of them have ides in front of them which provide a visual paradigm. The article in my opinion was less a comparison of technologies and more a comparison of what you can do with a decent IDE quickly (In case of .Net it was Visual Studio .Net and in case of JSF it was the Studio Creator EA2!)
with some explanations about the underlying techs.
The funny thing is the control comparison, because many of the controls shown are not part of the JSF core spec but are provided by the Studio Creator (but almost any component pack which nowadays is used has similar controls)
If you mean with alternatives EJB2 and pure then yes, if you mean with alternatives something like Seam+Facelets+JSF+Extensive component lib, or s/seam/ejb3 or s/seam/spring/hibernate then definitely no! Or if you subsitute xcode with something like Studio Creator 2 EA2 then definitely no. Do not get me wrong, WebObjects was groundbreaking, but it is mostly Apple to blame for that we now all code with other technologies not WebObjects. All the web stuff now is there where Webobjects has been around 2000 but the problem is, WebObjects mostly still is there where it was 2000 with small additional fixes and enhancements, while the rest of the bunch slowly but surely bypasses Webobjects, and XCode by miles!
Good luck getting clustered transactions and other important things like maintainability over dozends of coders code with php or rails in any way... Sorry to say that but both php and rails are great frameworks but there are areas where you cannot choose both of them!
JSTL... well, the issues are being adressed in JSF 1.2, to my knowledge only one issue really exists, which is JSF foreach, a construct which in 99.999% of all cases can be replaced with a tighter dataTable or dataList c:if normally works fine, but is not needed because every component has its own render attribute which can be combined with the jsf el. The rest is less verbose than struts, formatting there is an h:outputFormat component for formatting, validation is done within the form not from an xml file, the component libs already are very extensive, so programming a page with an html editor several date pickers and a scrollable data table with various links and actions is just a few lines of code. And the xml also makes way more sense than in struts. Sorry to say, that struts really shows its age, and almost anyone I know who knew newer frameworks and then had to move to Struts jobwise, cursed left and right for weeks.
I have been through 5 jsf projects, and I do not want to miss it anymore (although I agree the first project was rough) Actually the exception stuff is dependent on the implementation the post centricness is not really that true, yes there is lots of http post, due to the fact that post scales better than get, but you can do links with normal links (there is a h:link or something even in the standard codebase) as for post problems, like back button, the back button issue is solved in MyFaces and the ri, by simply restoring the state on a back. javascript is not mandatory for form posting, only command links use it due to the fact that it has multi action per form out of the box and doing such a thing without javascript is close to impossible, due to the limitations of html. If you need an alternative to this mechanism use a command button. The benefits you get however are huge, rich component sets, very tight markup template code, scoping (via extension frameworks and extension components), etc... I think in the end the benefits of JSF outweight the few disadvantages (after all we are still at the second revision of the standard) it currently has by miles. As for the post generally, it is nothing in the standard which would prevent the implementation of a getter form and getter command link, but the mere fact that hundreds of components even the most obscure existe and nobody has done such a thing shows that such a thing is not really needed that much.
Not really, unlike ASF.Net JSF is just a specification, you get stuff like date controls file upload controls etc usually from component packs. If you want a good out of the mill solution in JSF with most components you need, start with MyFaces.
The usual mistake many people do with JSF is that they just look at the RI and then dismiss it as all there is, while literally hundreds of components linger around on the net for free and about the same amount in commercial solutions.
You obviously have never read the MySQL license agreement, my friend.
While she is playing Nethack, at least she cannot go shopping, or bug you for making a baby...
You do not need to be an uber organization to have needs for something like transaction and thread safety and having scalability on your hands. The money also is a non issue since you can get excellent app servers for free nowadays, the tools also do not cost a fortune.
No need for xaml there are others already which basically do the same, after all xaml is just copied and derived from xul, but besides xul there are java applets and have been for years, and there are several flash based rich client frameworks.
Well, Frameworks like tapestry are pretty server agnostic as well all they need is a valid servlet/jsp runner. The reason for this simply is that servlets/jsps have become the base technology for such frameworks, there is no use in providing your own servlet clone, the technology is mature and stable and dozends of implementations many of them free can be downloaded from the net. The last framework I have seen not doing this was around 2000 (and that one was utter cr***).
Everything except Struts in the framework space has been derived from Webobjects (and thus Struts is such an utter.... ) Webobjects is one of the things were things have been done right from day 1. Having business facades which can be used locally and remotely, having a web ui framework which allows heavy componentization, having a decent orm mapper to bridge the gap between an oo language and the db and having tools in place to gap the bridge between programming and visualisation.
I agree you have to give WO the credits it deserves, it has been and still is the most influental of all frameworks in this area and the first one as well. Without WO we would not have Tapestry, no JSF, no EJBs etc...
The main problem with WO is that its main problem always was and is apple, while the other competing derived technologies have moved on both frameworkwise and toolwise, Apples role always was problematic, it was held back by licensing for a long time, the tools have been surpassed by EJB based tools for years now and the framework has been stagnante for a while as well.
In the open java world things are moving now towards EJB3 the first EJB incarnation now totally surpassing the backend and middleware side of Webobjects technologywise. And in the frontend side things are moving towards JSF a technology also superior to webobjects. And Frameworks like Tapestry which are clearly derived out of WO nowadays are leaps ahead of it. Typical case of having Apple (in this case NeXT) developing something superior and leaps ahead of everyone else for years and giving it the slow death due to licensing and lazyness issues.
I agree the whole web development paradigm is utterly broken and giving this idiocy entirely the boots and unlearning the people who learned this dreck will take another 10 years. Fortunatly there are at least some frameworks which try to brigde the gap between having a decent ui programming model on top of the broken paradigm. Tapestry is one of them html.net is the other JSF being the third. ...) but they are mostly ignored and now we get the next boilerplate idiocy instead of fixing the system (ajax) and then Microsoft will wipe the W3Cs backside with their xaml system which was derived out of xul and will fix the probelm and everybody will be wailing and in the end we will end up with 3 incompatible next gen html replacements and have to bridge them again with frameworks.
But most frameworks try to go along the route of plain actions and boilerplate mvc on top of it without any event mechanism and componentization that is one thing which I really call idiotic.
HTML webapp programming has pushed back application programming at least 20 years, alternate technologies are there which could be used (applets, xul,
The whole thing reminds me on the early eighties when people moved over from plain vt220 rendering to rich client uis and everybody had its different technology and you had to bridge the gaps again with frameworks.
J2EE Servers: You can get following without any costs: JBoss, Jonas, IBM Websphere Community Edition, Sun Glassfish, Apache Geronimo
Buggyness, not very buggy at all, most of them are very mature.
Complexity: Unfortunately yes it is there, but they cover a lot of domains, some of them have even integrated databases, security, clustering, messaging, remoting, webservices etc... you get this all out of the box
JSPs only are a small subdomain of J2EE JSP in fact ist the only thing very close to PHP and nowadays normally only used as a rendering technology for more extended stuff. Using plain JSP basically has been a no go for years now. Check out stuff like Tapestry, JSF etc... this is stuff people nowadays work with.
Depends on the domain, first the "will it" it has and has for a long period of time. The domain of those applications usually is in the areas which is bigger than the usual hackish php app. Java is very common in banking insurance company, fortune 500 etc... domains, you knoa what I mean. But for the average I need a quickly hacked page in two days page you wont find it that often.
Also with those languages probably nmost I learned php in 20 days and stuck with it people will get huge problems, you run into things you have not dreamed off probably. You will face the same problems all visual basic guys had when they suddenly had to move towards VB.net, you will have to learn the basics of algorithms and software engineering.
To make it short, PHP is good for small apps which you need to hack quick, where java frameworks usually due to the setup problems is dreadful, but once things become bigger java scales quite nicely both from a development point of view and from a speed point of view. Therefore it has become the choice for many bigger applications and companies where the I need something within a day problem does not apply to usually.
Sorry to jump the gun here, but I had a quick check on seaside, and I must say, a controller->ui on the code level scripting framework does not make it. I have been programming with such a thin in java for a while now (being forced too), while it is excellent in the areas of having one standardized domain of problems, mainly backend applications which do not require excessive ui layout and excessive ui changing, it simply does not make it in normal day to day situations, where usually a layout comes from somewhere else and you have to make it dynamic. There is a reason why almost any controller only based framework has died out and the reason is they simply do not make it, templating nowadays is a must, sorry to say that.
The main problem is, that almost everybody seems to think he has to program his own framework and then utterly fails in simplification or other areas instead of trying to improve the existing ones. Now we have the situation of around 100 frameworks or more, most of then do not bring anything new to the table but also most of them being only half baked. Only a handful really shine, that probably on the java side being
Wicket
Tapestry
and JSF
Struts, forget it it is a major pain in the lower backside and almost every line of code you save on the java side ends up in two lines of code on the xml side.
Actually it is better and worse. First of all Java is quite nice to use on those phones, but you run into myriads of small issues. First there is speed, like Carmac said you have such a huge diversity in speed that you have a range of 1-20x speedwise over various phones. Secondly there is the jvm version problem. While most mobile phones should be on newer midp levels which have standardized interfaces for networking, sprites and sound (the most important stuff for 2d gaming) you have still phones which are on early midp levels which means you have to revert to self written sprite routines, vendor level networking apis etc... Isolating this stuff into a common api is useless because on the older phones you have so many constraints memorywise, that the whole thing feels like programming for a C64 but in a more decent language. The 3d part also was mentioned by Carmac which still is an issue, 3d chips for cellphones are widespreadidly used at least 2-3 years away.
You just gave the perfect explanation for a JIT compiler
To comment on this even more, most of the java needs so much ram situations I have seen the last few years came from the typical we allocate as much as we need without a second though patterns, and then everything was blamed on Java. Reading a 500 meg data file into ram before dumping it into the DB and then blaming it on java was such a typical situation! Those patterns often are very similar, and often are caused by some whiz guy who thinks he knows everything better than the rest of the world!
Sheesh... xMx 1563 for your portal, you guys should seriously check your code, I have been running a portal server on plain 128m for years with no downtime at all.
Depends if you run into a C fallback or not, most of the times you do not. Here is an example, PHP is the perfect example of what you mentioned, now the Caucho guys have moved PHP onto resin into a JVM it got a speed boost of 6x over a plain lamp configuration on the code level. (Most of the performance of the typical webapp goes down the drain during db access)
Sorry to say that but I once did a project with TCL and it was a joke of a lanugage, on OO, no possibility for namespaces etc... the only merit of it was back then the TK library which made X-Windows interfaces easy to program (but only small ones, as soon as things became more complicated you ran into hell) Given the fact, that it has been some time, and things might have improved enormously, but even back then with Lisp, Smalltalk, Perl, Python and others already in existence, TCL was a joke of a language.
Marketing mumbo jumbo, .net has forced some changes in C++ and other lanuages which sit on top of it, the JavaVM even has more languages
running on top of it than .Net has, after all a VM is just a VM a virtual processor emulation layer, the rest is marketing.
Learn the concepts, a language is pure syntax, a concept is vivid longer than the usualy 10 years language cycle.