Slashdot Mirror
JSF vs ASP.net
DuncanE asks: "We are looking at migrating an old legacy database application to a newer web
based framework for the front end. For me the two obvious choices are ASP.net vs
Java Server Faces. CodeGuru has
side by side look at both, but does anyone have any real world comparisons? ASP.net appears to be MS only, which is a concern, depending on how mature
mod_mono has become." Which framework would you prefer to use? Under what situations and conditions would you recommend the use of the other?
As soon as Microsoft decide that Mono is good enough to make enough people think of moving away from Windows, I think they'll try to change .Net to prevent it. .Net. It may still turn out to be a good choice, given that there are probably more .Net developers available, provided that you've taken into account aspects like security.
.Net (in New Zealand), and this is being written at home with Firefox on Linux.
AFAIK The only issue with Mono currently is that MS-specific security doesn't work under Mono, because it relies on Windows.
I suggest that if you want to be able to run on something other than Windows, be careful about choosing
BTW The only programming I do is
Borg:"Lawsuits are irrelevant. GPL3 is irrelevant. DRM is good. We understand security... Alert! MS are assimilating us!
why are these two technologies such obvious choices??
He's looking for support for a decision already made, so he's looking where he knows we will tell him what he wants to hear. He chose Java Server "Faces", whatever those are.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
I think Java would be a more 'safe' choice.
.net solutions are somewhat similar in the quality of their solutions, and that any marginal difference in quality, if they exist, would have no impact compared to the freedom of choice Java provides.
Java Server apps can run on multiple operating systems, multiple servers, and in the extreme case of Sun not supporting it anymore ( or not adding a feature you want) you've got tons of big companies pushing it, like IBM and others, in addition to open source implementations like GNU classpath. Not to mention that you can implement 100% of your solution without paying anything.
ASP.net, on the other hand, is a Microsoft solution, and you depend on the whims of MS for everything. It runs on little more than Windows/IIS, and the only serious IDE for it would be Visual Studio.net, and good luck trying to run it under mono if you favorite class or function is incomplete or has a bug in its mono implementation ( or the MS implementation for that matter).
I think that the Java and
My web apps must be crap, because I've never heard of "JavaServer Faces".
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
These kinds of decisions ought to be based on what you and your colleagues are most comfortable with. Java? C#? Perl/Python? You certainly wouldn't try to run a marathon in brand new shoes!
Both are a good choice if you want to properly engineer a new web-based tool. ASP.NET is probably quicker but if you want to do anything really serious you'll probably want to look at purchasing Visual Studio 2005 rather than just using the Visual Web Developer Express. Also the tool support for JSF isn't nearly as mature so it will probably take longer to implement in JSF than in ASP.NET.
.NET. If portability is a big issue and you'd really like to run this application on a small server running Jetty(for instance) then go for JSF.
Having said that JSF is still a good choice - particularly if licensing costs and portability are an issue. Apache MyFaces is an excellent framework whose only downside is the poor documentation. JSF can be slower to get started with but I found that it enforces best practices more strictly and once you get the hang of all the XML wiring it wasn't that bad. Another benefit of JSF is that you'll have trouble breaking the MVC pattern but you can pretty easily embed alot of code in ASP.NET unless you properly use code-behind and deliberately seperate out the DAL which isn't the default for the point and click wizards (the DAL separation).
In the end it comes down to a few things. If you have existing C#/VB skills and don't mind being stuck with IIS then go for
groklaw, wired and slashdot. The holy trinity of work based time wasting.
I'm not very experienced with either (know a bit of java, and used to work with ASP/VB on NT4), but for a project like you're describing, ASP and Java would be the last thing I consider.
Both have a reputation for being slow, insecure, and proprietary. As much as sun is trying to shed the image, Java is still their property.
Generally, it's a decent idea to separate the databse from the application/interface, and it looks like you've already done just that, so you should be pretty much able to pick whatever language you want. I'd be inclined to think that ASP.net supports the microsoft databases the best, and leaves a hazy future as to whether or not it will play nicely with your database. I also wouldn't like to rely on a Windows operating system as your server environment.
I'd shop around..... if this is really *just* a frontend, you could go as far as checking out one of the newer languages like python or php. If you want to possibly speed up development, and play around with a few new technologies, you could also check out ruby and see if it suits your needs.
Look at what other people are using. I'd tend to think that PHP and ASP.Net seem to be the two most popular. ASP.Net does have advantages, and from what I hear, it's leaps and bounds better than the original ASP I worked with on NT4. I personally wouldn't like to be locked down to windows OR mono (if it were to ever be shut down by microsoft for some sort of leagal trouble, you'd be in trouble)
But java....just makes me cringe. I've seen very few well-written java applications that were fast, stable, and functional. It can be done.... but very few are able to
-- If you try to fail and succeed, which have you done? - Uli's moose
Scrap those poses for a real upcomers, go with Rails! It is so much better than any MS stuff, and years ahead of Java...
Compared to ASP.NET, Java Server Faces is pretty immature, and missing certain controls like a file upload. Nobody seems to use it that much, so the user support community seems pretty small (as you can see by the responses to this story). Also, if you stick the state into the Session, the controls tend break if the user click the back-button. The navigation framework also seems pointless (just use links like a regular person)
I wouldn't make it a large deciding factor though -- in both cases the actual page code is going to be a pretty small part of your app.
Whenever I hear the word 'Innovation', I reach for my pistol.
It has been updated for ASP.NET 2.0, C# 2.0, and Visual Studio 2005.
I'm a .net developer, and while I'm sure it wouldn't be too dificult to transition to the Java language, I think I'd have the most problems adjusting to the tools. As I'm sure a Java dev would have issues transitioning to .net. I wouldn't know where to start, what IDE should I use? how is remoting/RPC implemented? What build tools, source control systems to use? and so on... .net and java are pretty much mutually exclusive techs, so most of your developers are going to be experts in one or the other. If you havent hired resources yet, then it may do good to see what the market is doing.
You mention portability as a big concern, IMO its pretty overrated, and very seldomly implemented. if you suddenly find yourself switching platforms, then someone screwed up somewhere down the line in planning. Just my 2 cents.
Top 10 Reasons To Procrastinate
10.
I would stick with Java - you can deploy on any platform without worry of premature implementations. At the company I work for we use BEA WebLogic with Java web applications and Struts - works quite well.
I'd choose Macromedia Coldfusion, but hey, it's just me :)
Per Aspera Ad Astra.
In terms of being able to create and serve a web page, either one would probably WORK, but I think Java is a much better platform. Let me share with you my reasons why, keeping in mind that I'm a professional developer with eight years of production experience. Also, I've developed on Apache (straight HTML and some CGI), JSP (on Red Hat servers with Apache Jakarta), ASP3 (IIS with COM+ middleware and Oracle backend), ASP.Net with web services AND some COM+ middleware and oracle backend, and now, Oracle 10G with Java everything (basically).
.Net-ish, and it's free, but I don't think Mono matches the sheer breadth of Java offerings you can acquire at zero to no cost. Java buys you almost complete freedom from vendor lock-in, if you play your cards right. .Net, in comparison, is vendor lock-in INCARNATE.
First of all, every platform in use supports Java, and you can download almost anything you might want to use for free. This is going to save you a bundle. YES, I know that technically Mono is sort of
Second, Java has an amazingly rich class library. If you can think of something you might want to do with a computer, there's a java library in there somewhere which will let you do it -- usually relatively easily, too. Although C# is approaching this level of functionality, I don't think it's exactly equal with Java yet. Close, maybe, but I think Java still has a little edge. Which makes sense, when you think about it -- Java's been around for several years longer.
Third, most major vendors are now completely behind Java. Sun, IBM, Novell, and Oracle, for instance, are all putting their collective might behind the platform. That's pretty significant. It means that new innovations from these companies are going to be available in Java FIRST. Also, when you're ready to ramp up to big iron, you're more likely to be able to do so with Java, because all the big players there are Java shops.
Fourth, you can download Oracle Express for free, and use it with Oracle's Java developer's tools to build a rather interesting type of system. Oracle's considering an interesting approach here; give away the low-end database so that as companies grow they think about going with Oracle first. That's pretty good business; be generous first, so you'll be thought of when it's time to purchase something big. And this can work for you.
Fifth, the same skill set your developers use to create Java-based apps on your web server can be used to program just about anything from a Microwave to a PDA to cars and trucks (believe it or not, yes Java's finding its way into some vehicle systems). Java's everywhere these days; the language is the same, only the API changes. That makes your Java skillset very portable.
Finally, I think JDBC is a little nicer than Microsoft's database approach. I've programmed both ways, and I like the Java approach better. It's easier, for one thing; I write less code working with Java (YES, I know, it's astounding, but nontheless true).
I could go on, but you see where I'm going. Java's the nicer of the two platforms, and you can't really go wrong choosing it.
If you go with Java, there are plenty of other choices than JSF. Struts, while a bit verbose and showing its age, is a very mature framework that scales well and has been used successfully in lots of projects. A lot of people recommend Tapestry or Cocoon. It all depends on the size of your project and what people are experienced with.
A good thing with Java, no matter which framework you choose, is that you have a huge number of open source tools and libs to help you (Eclipse, Netbeans, JUnit, Ant, Maven, CruiseControl, JMeter, PMD, Checkstyle, xdoclet, Hibernate, Spring, Tomcat, commons logging, jsch...) , and there are also plenty of books, online tutorials, and programmers around who know Java.
Being bitter is drinking poison and hoping someone else will die
Use Java if you can. Use .NET if someone pays you more.
Don't blame me, I get all my opinions from my Ouija board.
My money is on the JSF
I have found there are just two ways to go.
It all comes down to livin' fast or dyin' slow. -REK, Jr.
Java given you a lot more freedoms than closed MS environment, so stick to it if possible.
In Java space there are many frameworks to choose from. One should at least look into Millstone, Echo and Tapestry as well as JSF. My personal favourite is Millstone as it provides a really clean and efficient development model. I takes some time to get into it, but it really pays back to do so in large projects.
If you're looking into alternatives, perhaps you should consider Apple's WebObjects. It's essentially what JSF is trying to be, along with a robust, mature, *lightweight* JDBC object-relational mapping and object persistence layer that is scads more mature than Entity EJB's. Pure Java, runs on J2SE 1.3.1+, deployment licenses amount to $499 per server (free with XServes). It's also highly scalable -- this is the technology that drives the Apple Store online, the iTunes Music Store, and Apple's .Mac service.
--Paul
(disclaimer -- I work for Apple; however, I've been doing web development using ASP, J2EE, and WebObjects for years. IMHO WebObjects is far more elegant and robust than the alternatives.)
Yeah, I thought the same, the Joint Strike Fighter vs MS code. Damn the geneva convention and lets napalm that sucker! Colleteral damage highly advised. If only they can accidently take out Java as well. Then all will be well.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
For me the two obvious choices are ASP.net vs Java Server Faces.
Why are they the two obvious choices? What about PHP for example? It sounds like you've already made your mind up - why bother asking the question?
Time is an illusion. Lunchtime doubly so. - Douglas Adams
- Non-existant error reporting: If an exception is throw by the code backing it up, the error message on the front end will be something like "Exception: '{mycomponent.dosomething}'". Which really means that dosomething threw some other exception that it is hiding from you.
- Everything is a post: JSF tries to apply MVC to the web, which is fundamentally broken IMO. The web is transactional, not event driven. To make it appear that everything has callbacks, all the links in the web app are done by making javascript submit a POST form for the page. Much harder to debug than any other web app that I've ever worked with. You can't just see the params on a GET url and expect links to work like every other link on the web
I've never used ASP though, so I can't really compare. Myself I prefer servlets that spit out XML and use XSLT to give HTML. The designers don't seem to like the XSLT much though.http://jakarta.apache.org/tapestry/
I've enjoyed developing PHP applications, so you might also want to consider some form of LAMP-oriented system. If you do, consider using Zend Platform, the new PHP server management system from Zend; it's supposed to make administration of PHP webservers much easier.
;) If you go that route, consider using either Java WebStart (if you prefer Java) or Microsoft's ClickOnce (if you prefer .NET).
.NET route, which I would personally recommend over Java, you might also consider developing the application in the new Windows Presentation Foundation. Although it's still in BETA right now, WPF applications deployed with ClickOnce have the option of running inside the browser -- the user gets a much richer experience than web applications can grant even with AJAX, but are still on the web. Think of the browser option as a cross between a Java applet (which .NET has been sorely lacking) and Mozilla's XUL.
.NET, you cut off non-Windows platforms. If you run WPF, you are cutting edge (it's not even finished yet!!), but you have a small client-base until Vista takes off.
That said, I have a radical suggestion: use a rich client rather than web application. Even with AJAX, the web is still a very limited user experience platform -- I've always preferred manly GUIs to sissified pansy-web-pages.
If you prefer the
Of course, there's a trade-off... if you go the rich-client route and use
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
Is this really 'just a front end'? If your project is really just a front end to an existing body of business logic, it doesn't really matter that much. Front end coding will be the easy part. Going through your server or appserver business logic and tweaking it for your new interface will be where the work is. In a well designed web front end there should be as little business logic as possible. This way the front-end coding is reduced and replacing your web interface down the road with another front end becomes easier.
Laugh if you want, but I'd probably code the appserver-side logic in the Progress 4GL running on Open Appserver and then use a Webspeed front end if the requirements were low, if not maybe write the web interface with Visual *.Net or whatever the team was comfortable with. IMNSHO, the middle tier is where your big decisions should be. That way you're not permanently tied to any particular front end.
This sig kills fascists.
Seems like every time I see .net deployed, it only really work with MS browsers. Then the under-knowledged team has to try to figure out how to get it work in the real world. Then there's also the endless security issues with very very long fix times. You'd have to be high to not know it takes way too long for MS to fix known security problems.
Consider Microsoft for games, but not for business.
.
e ator/index.jsp [sun.com]
e ator/reference/quicktour/2/flash/index.html
Java has some new ide's for free that seem to produce web pages (I'm not exactly sure what java flavor). They look really slick, and have me thinking about switching to java from php.
http://developers.sun.com/prodtech/javatools/jscr
http://developers.sun.com/prodtech/javatools/jscr
I don't know JSF, but I'll comment on how this might compare with ASP.NET v1.1. (Haven't used 2.0 much, but it's much improved in many ways.
1. Non-existant error reporting: If an exception is throw by the code backing it up, the error message on the front end will be something like "Exception: '{mycomponent.dosomething}'". Which really means that dosomething threw some other exception that it is hiding from you.
I don't think this applies to asp.net. If the code backing it up throws an error, and you're displaying errors(rather than catching them) on your main page. You're going to see the full details.
Now if you are using Remoting to a different server(usually like say from a presentation to data tier), that can get hard to debug sometimes. You'll get an exception, but not necessarily the full details.
The worst is if your web.config file is malformed somehow, you'll just get a generic error telling you that there is an error and you pull your hair out. But once you get past that it's very easy to debug.
2. Everything is a post: JSF tries to apply MVC to the web, which is fundamentally broken IMO. The web is transactional, not event driven. To make it appear that everything has callbacks, all the links in the web app are done by making javascript submit a POST form for the page. Much harder to debug than any other web app that I've ever worked with. You can't just see the params on a GET url and expect links to work like every other link on the web
Well, you won't like ASP.NET then.
But you know what? I seldom actually develop that way. IT's nice at times because it's easy to just throw a page together. But most of the time I seperate out my application in such a way that I use the querystring.
Maybe I'm just old-school. But the point is, you don't have to develop the easy way, you can go in and make it specific. At least with ASP.NET.
I've never used ASP though, so I can't really compare. Myself I prefer servlets that spit out XML and use XSLT to give HTML. The designers don't seem to like the XSLT much though.
ASP is not ASP.NET. The only thing they share in common is those three letters.
Most of my ASP.NET development is similar to your XML/XSLT to give HTML. Except I'm calling stored procs and getting back DataSets. I then feed the DataSet into some kind of rendering class, like the built-in DataGrid or DataRepeater.
I find XSLT useful in certain cases. I think it's hard to work with, and the few GUI type editing tools I have found are crap forcing you to use a text editor all the time. Also, at least in my experience it has a lot of server overhead compared to the Dataset rendering that ASP.NET provides. I don't know why, may just be the MS XML parser controls.
Not sure why you're considering JSF and not Tapestry, but in case you want to add the latter to your shortlist, here's a good, detailed comparison between Tapestry 3.0 and JSF:
t ry.php
http://www.realsolve.co.uk/site/tech/jsf-vs-tapes
Tapestry 4.0 was just released, so that comparison a little dated now, but still worth a read.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
I am C++/Java Developer and at work was asked to write web-based applications that would display and manipulate very specific data to users from multiple data sources. Already Knowing Java I turned to J2EE for my web development, using a mixture of JSP and JSF. I found the most useful part of JSF for me has been the tag. I used a JavaBean to make JDBC connections and build and array/list of data objects. dataTable will display dynamic columns from your data structure on the web page. In your dataTable you can mix Java data types, html and other JSF components, CSS can be used to make your dataTable pretty. Using JSF saved me a lot of time with web page development.
I did consider ASP for this project but there was too much MS overhead since time was a consideration on this project
You could check out this netbeans flash demo that explains the ease-of-use of developing a Java EE 5 application. That includes adding JSD support to the project.
n -2005-GlassFish-EJB3Persistence-NetBeans-Demo.swf
http://weblogs.java.net/blog/binod/archive/foss-i
MasterPages. Page templating ensures consistent page layout throughout the site, without the hassle of a centralized dispatcher logic like e.g. a front controller.
WebParts. Makes creating portal websites and/or -pages a no-brainer (well, once you get a grasp on the concepts involved). Drag&drop works in all common browsers. The user can rearrange webparts, collapse/expand individual parts, add from a catalog, hide/remove parts, export/import to/from local files, link properties across parts. For the developer creating a webpart involves roughly the same effort as creating a page with the same functionality.
Declarative Localization. Finally lets you do those multilingual sites without cluttering the pages with conditionals or code to retrieve text values. Localization is declarative: The tags are adorned with a meta attribute which specifies a resource key. The lookup/substitution is completely automated. You are still working with the markup in your default language. Alternative languages are specified in external resource (xml) files. These may alter any attribute, e.g. image urls, text etc.
Caching. Fine-grained control over output caching (page and pagelet caching). This includes declaratively setting up cache dependencies to invalidate the cache. Database systems (Oracle and SQL Server) can even be set to invalidate the caches automatically (event based) when the result of a query would change because of a database change. Other caching options inclused application managed caching and resultset caching.
Themes/Skins. Lets you declaratively alter select properties of controls across the site. You can think of themes like server-side style sheets. Being server-side they can alter properties of server-side controls. One theme may choose to not use paging in GridViews, while another theme may choose to enable paging with a pagesize of 20 for all GridViews.
Multiple compilation/deployment options. In one end of the spectrum you can deploy fully precompiled sites, in the other you can deploy sourcefiles and leave all compilation up to the webserver. There are pro/cons indicators of each model.
Adaptive Rendering. Serves same purpose as renderkits. Lets you specify alternative rendering for specific devices. In 2.0 this has meant that the former special "mobile controls" for WML has been folded into mainstream ASP.NET.
Asynchronous Webpages. Some web pages needs to call upon external resources, e.g. webservices. Some of these calls make take a long time (seconds). Tieing up the thread/process of the webserver while the page/model waits for the request will lead to decreased scalability. Asynchronous pages will let you relinquish the thread. When the external, asynchronous call returns, another thread is dispatched again to complete the processing.
Membership Controls/-Providers. A number of standard controls for creating a membership sites: Login, CreateUserWizard, LoginView (showing alternative content based on login status and/or roles belonged to), LoginName, PasswordRecovery. All of these controls are fully customizable, i.e. you can take full control of the rendered xhtml. The controls includes membership specific functionality. The controls work their magic by integrating with a Membership Provider. You can go with one of the two supplied, or implement your own.
Integrated Personalization. Choice of theme, language, webpart customizations etc. are by default integra
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*