Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ASP, PHP, dotNET 5

Status
Not open for further replies.
Hondy

Hondy

Technical User
Mar 3, 2003
864
GB
Hello

Are there any glaring reasons that I shouldn't consider ASP, PHP or dot NET for a commercial web app?

If I speak to .NET'ers they indicate ASP and PHP are old hat and not suitable for proper web apps. I don't believe this, but I need some kind of Pros Cons?
 
Sort by date Sort by votes
If I speak to .NET'ers they indicate ASP and PHP are old hat and not suitable for proper web apps.
Click to expand...
Well, duh. Consider the source.

It depends on what experience you or your developers (if not you) have.

It further depends on what services already exist on the server side (if any). If you have a .net server and expertise in-house, by all means take advantage of the platform. If not, or if you have php experience, use that.

By extension, this applies to coldfusion or any other development platform as well.

(The short answer is nonsense; there are no glaring reasons). But individual circumstances may clearly tilt that answer.

Greg
"Personally, I am always ready to learn, although I do not always like being taught." - Winston Churchill
 
Upvote 0 Downvote
yeh i know that, thats why I need to be able to argue the difference. I think that because .NET is related to ASP and that PHP is "free" leads to language snobbery.

So then, given that .NET is compiled, does it have any security or other advantages over PHP?
 
Upvote 0 Downvote
I would second what Greg says about use what is available. If you have a choice of all of them, use the most appropriate tool for the job. I personally prefer Perl for most of my server side work but PHP's image handling is much better than Perl's so I tend to use a mixture.
As for being old hat, I would always try to use a language which I know will do the job in hand.
Having said that .NET may be a much better way of working than my current method, I have never used it but as I prefer to write the code myself rather than have an interface create it for me, the old hat applications suit me just fine.

Keith
 
Upvote 0 Downvote
Upvote 0 Downvote
thanks, i wish i knew more about the technicalities of the languages to be able to put up a decent argument.

I have a project to do and my preferred developer is a PHP guy but I'm going to have to argue the point with the in house developers (who won't be dealing with the project)- but they will be saying that I chose the wrong language :s

Arghhh
 
Upvote 0 Downvote
Why are the in-house people not doing it?

If it is a stand alone project, it doesn't really matter what language it is written in, as long as it does the job in a reliable way. The only issues the in-house devs would have, would be if they needed to interface to it or maintain it. If they need to interface with it, get the specs of the I/P & O/P vars down in writing before any dev is done and get the author to provide full docs.

Keith
 
Upvote 0 Downvote
in-house people aren't involved, its complicated :)

Out of interest, when you code something and spend hours documenting it for your clients do you then charge for this service?

I have worked with a few programmers and it rarely comes with documentation unless you specifically pay them to sit down and write it, I don't like this and they would argue "ok you can have docs but I will charge more per hour to have this included" - in other words full documentation is either part of the price or an extra, either way you pay for it. I can see the logic in this but if you pay for an hours work then have to pay an hour to get them to write it down its a bit harsh.

OK so PHP = good :)
 
Upvote 0 Downvote
Well there's an argument from both sides on the documentation issue.

1. A coder should document anything that they are producing for a client. It sort of goes without saying really. But they should include this in their initial costs.

2. You can't really expect someone to work for nothing. If they haven't included or charged for documentation then you can't really expect them to then write all the documentation for free. As a 'buyer' you should ensure it's included in the price you are paying.


As for "PHP = good". Yes, I love PHP and would use it as my language of choice. But that's just because it's what I do. There is no reason an application cannot be written in .NET as oppose to PHP.

There are alot of great apps written in PHP, there are great apps in .NET. Equally there are alot of badly written apps too.

Personally, I tend to find that .NET apps seem to fail more often. But I think this is indicative of the many .NET "developers" (note the quotes) that just point and click with no real understanding of the mechanics of what goes on under the hood - nor of software development best practice.

The only limiting factors in the choice of language are those already pointed out. Namely:

1. Who is going to support the app? Are they able to work in that language?

2. Will the app integrate easily with other apps already in place?

For instance, if the support team know nothing of PHP then it's a bit daft to commission a PHP application in the first place. You should at the very least consider the cost for training, support into the lifetime costs of the project.





--
Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.

 
Upvote 0 Downvote
Documneting an app shouldn't take too long but the additional time has to be paid for in some way. I am not industry trained so their procedures are very different from mine. The industry people I know seem to spend a great deal of time in meetings without actually coding anything, that is paid for by someone. I am not knocking this way of working because there is little point in writing anything until the team know what the app has to do and which team member is responsible for which bit. My projects are all small, stand alone apps which are developed with the client. At the start of the project, I usually have a very vague brief which I develop into a full app. My docs are usually brief notes throughout the script which describe what each section does.

During the time of writing the app, I will live and breath the script and know it inside out. A few months after completion I don't know it at all and if the client wants something adding, the notes within the script are essential for me to return to it.

Working out what other peoples scripts actually do can take a lot of time and cost so docs are essential in the long run.

Keith
 
Upvote 0 Downvote
Thanks guys, I do agree entirely with what you say that someone must pay. Programatical documentation worked into the price is like an insurance policy in case you need additional programmers I guess! Of course the documentation will be good enough for this... won't it? ;)

Most of our stuff is M$ - but I would love to go the opensource route to reduce costs.

Cheers!


 
Upvote 0 Downvote
I'd go so far as to be quite specific about what you expect to be documented. If you expect unit tests (which can then be used to understand the code - from a developers perspective) then make sure you state this clearly (what coverage do you expect etc). If you expect "business analyst" style documentation at a high level - make that clear. If it has a significant user-facing component, is there a design (or style) guide that is expected (or updated)? Do you require the developer to maintain (any) existing documentation (such as the design guide or specific use cases)? I'd write it down as part of the initial contract to ensure there is no confusion down the line.

Cheers,
Jeff

[tt]Jeff's Blog [!]@[/!] CodeRambler
[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094
 
Upvote 0 Downvote
Yeh thanks Jeff.

I would like to know what percentage of a project is actually code writing time when you have:

Meeting after meeting
Code writing
Testing
Bug Fixing
Documentation
Roll Out
More bug fixing! ;)
 
Upvote 0 Downvote
Code writing should be less than 20-25% of a typical project. Analysis, design and testing should take the bulk of your time. (Your mileage may vary).

Hey, you guys start coding; I'll go see what they want...

Greg
"Personally, I am always ready to learn, although I do not always like being taught." - Winston Churchill
 
Upvote 0 Downvote
Why can't Coldfusion be part of the solution? CF8 can do pretty much anything you want, and learning CF is incredibly simple as it follows HTML-style coding.

_____________________________
Just Imagine.
 
Upvote 0 Downvote
Hondy, for me it's about time management. We all have to deal with external activities (meetings, presentations, documentation, bug fixing etc) and I tend to manage them in such a way that I ensure I get the chance to do some coding...

A typical day might be:
9.00 standup meeting to discuss progress and identify what tasks will be done in the following day
9.30-10.30 available for meetings (or doing bug fixes if no meetings)
10.30-12.30 coding new functionality - not available for meetings
1.30 - 2.30 bug fix exploration and delegation
2.30-4.30 coding new functionality - not available for meetings
4.30-5.00 document the work completed today
5.00-6.00 available for meetings (or doing bug fixes if no meetings)

If you do a little bit every day, it's not such a burden - and you don't forget what it was you worked on. The documentation medium for us is a wiki - so it's 100% visible to everyone all the time (which makes it harder to ignore doing).

Hope that gives you some mileage!

Cheers,
Jeff

[tt]Jeff's Blog [!]@[/!] CodeRambler
[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094
 
Upvote 0 Downvote
Jeff, I have to admit I don't really use wiki (or even visit that site much), but if you're using wiki as a documentation medium for your company, doesn't it mean that anyone on the web has access to it? Usually documentations have processes that is meant for internal folks. How does that work for your company?

_____________________________
Just Imagine.
 
Upvote 0 Downvote
I think Jeff may be suggesting A wiki rather than Wikipedia

Have a look at the Wikipedia definition of wiki to get a better understanding of what he is suggesting

___________________________________________________________
If you want the best response to a question, please check out FAQ222-2244 first.
'If we're supposed to work in Hex, why have we only got A fingers?'
Drive a Steam Roller
Steam Engine Prints
 
Upvote 0 Downvote
You are indeed correct, I mean A wiki [smile]

We use the Trac wiki:
It's been configured on the corporate intranet to remain available only within the intranet. Personally I get frustrated by the markup you have to use - but you get used to it.

Cheers,
Jeff

[tt]Jeff's Blog [!]@[/!] CodeRambler
[/tt]

Make sure your web page and css validates properly against the doctype you have chosen - before you attempt to debug a problem!

FAQ216-6094
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

electronicsfreak
  • Locked
  • Question
PHP Notice: in file /language/en/mods/arcade.php
Replies
2
Views
54
ChrisHunt
ChrisHunt
topjimmie
  • Locked
  • Question
PHP/MySQL query is simple, but not returning a value. Any advice? 2
Replies
2
Views
67
ChrisHunt
ChrisHunt
fauntleroy
  • Locked
  • Question
PHP form question - non-mandatory fields
Replies
1
Views
66
johnwm
johnwm
dinger2121
  • Locked
  • Question
cms for ASP .net site
Replies
1
Views
34
AGus01
AGus01
Ferrian
  • Locked
  • Question
Transferring session data between ASP and PHP
Replies
1
Views
65
BabyJeffy
BabyJeffy

Part and Inventory Search

Sponsor

Back
Top