Wow, thanks all for the reactions! This post is a reply to some of the comments.
On Thursday 23 November 2006 00:11, David wrote: > Other articles also suggest php is becoming a front-end language for > java. So why don't you beat them to the punch :) This is a solution that is worth an investigation, thanks for the links! On Wednesday 22 November 2006 22:39, Dave Cardwell wrote: > If the OP is used to programming in Java, the Perl-mindset is probably a > bit of a switch. I agree that something like CF or RoR might suit him > better. Well... this is not a choice that needs to be made on an indiviual base. The choice needs to indicate a new way of doing webdevelopment for the company.... Otherwise, I would have chosen PHP for the simple reason that I already know this language. The choice that needs to be made will probably need ar change of mindset! Get rid of developing using J2EE technologies when not needed. On Wednesday 22 November 2006 19:52, Jörn Zaefferer wrote: > - What does your existing server infrastructure allow and support? > - What does your team already? > - Do you have clients that may be interested in understanding your code, > and what are they familiar with? > - Do you need APIs to work with special formats like xsl, for im- and > exports? A new choice will most likely involve new servers. This is probably the biggest blocking factor. Fear of change. (this goes for the supporting infrastucture, the language to use and also the supporting methodology) We have no clients that are interested in the code. Clients want a working product, delivered on time. These will all be small new independant products, no API calls, no reuse. On Wednesday 22 November 2006 20:49, Glen Lipka wrote: > I used Cold Fusion for years. It has a pretty committed community, > although I wonder about Adobe's ability to keep it going properly. The > inventors of CF have long since left Macromedia/Adobe. > > PHP is so easy to learn. It just works. It is today, what cold fusion was > 10 years ago. (The fastest way to build something.) > > I have never met anyone who TRIED Python and didn't love it. > > ASP.net. Microsoft makes so many tools and they all hook into asp.net. If > you want to hook into Exchange or Active Directory or Word or Excel or any > of the microsoft stuff, you have to do asp.net. They have the dev tools > and some REALLY advanced tools like Windows Workflow. The investment is > heavier, and it is NOT easier, but man, they use the power of monopoly and > integration to take it seriously. > > Ruby on Rails. All of the above have a Rails type env. I am not sure if > Ruby on Rails is better than Symphony (PHP on Rails). Even CF has a rails > concept. I don't know alot of people who use RoR for enterprise stuff. I > know a couple who use the CF and PHP Rails concept. > > WebSphere, ATG Dynamo, Weblogic, any J2EE enterprise stack. Cost a > fortune. Hard to use. hard to maintain. Avoid avoid. Alert! > > You have to look at who you have working with you, existing skills and > integration requirements. Thanks, good points! Get back on the off-topic: I hear a lot of good comments on ColdFusion (amongst them that it uses a JVM and can therefor easily interact with existing classes) although I find the tag-based syntax uncomfortable. Ironically, ColdFusion has just be phased out in our company (I wasn't involved in this choice) for reasons of lack of knowledge (we had external developers), an additional server which was hardly used, versioning problems, 'gut feeling' of certain managers without IT knowledge and more. The more dynamic a language (i.e. interpreted/scripting languages), the quicker to develop, but the more difficult to maintain once the scope gets bigger. Static languages (aka compiled/system programming languages, not picking on the fact that a JVM is in fact an interpreter) have a lot of coding overhead by all the type-casts, exception/error-handling etc but are easier to maintain/test (!) especially when the project tend to get bigger. System Programming Languages are better for algorithms. memory management etc while dynamic languages are better for data manipulation etc. So... best would be to have a combination of the two worlds: a backend written in a system programming language and a front-end in a dynamic scripting language...(cfr Davids response)? Several statements in two small paragraphs. Am I right by making these statements? If this is true, the answer lies in scoping: small (whatever is meant with this) applications: use a scripting approach, optionally connecting to a backend written in another langauge. Bigger projects: use something like Java.... This will be difficult to defend towards management.... :-/ _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
