Client-side languages

Bosco

Hi folks,

Here's the story. I'm just about to embark on my first web-based (intranet) project, which is a simple (I hope) timetable management system. I intend to do the server-side processing and database access using JSP/Servlets, and use Oracle for my back-end.

The question is, apart from HTML, will I need to learn a client-side language such as JavaScript or VBScript in order to put things like buttons, text and dialog boxes etc. on my pages? Or can any/all that be implemented on the server?

If client-side coding must be done would I be better off using applets seeing as I'll have to learn a load of Java anyway?

Any comment/help would be greatly appreciated, but please, don't wander off the topic.

Thanks, Bosco.

Enygma

You don't *need* a client-side scripting language at all. It's nice for some effects like mouse-overs etc. but for buttons, text-fields etc you just use plain ol' HTML.

You should try and get all your processing done on the server rather than the client, at least you'll know the environment and you have control. If you use JavaScript you're relying on the user to have it enabled on their machine.

As for Applets.....no.

Good luck with JSP, I've been using it for a while now and I think it should be on the top of everyones list of "things to learn".

kayos

Originally posted by Bosco


The question is, apart from HTML, will I need to learn a client-side language such as JavaScript or VBScript in order to put things like buttons, text and dialog boxes etc. on my pages? Or can any/all that be implemented on the server?

If client-side coding must be done would I be better off using applets seeing as I'll have to learn a load of Java anyway?

Right first off never use VBScript on the clientside that is a no no as it will only work on windows. After that I would not advise using applets cause there a pile of $%^£ IMHO.

JScript is the way to go for your client side codeing but keep this to a min. And as a rule of tumb pop-ups are annoying.

Most of your content will be coming out of the DB I guess so you willbe using JSP/Servlets to generate this.
Your buttons well normally these are submit and reset and these only need a clientside HTML form.

Get yourself a copy of Dreamweaver UltraDev as its a dreamy (excuse the pun) tool to use and it supports JSP/ASP/ColdFusion which ever you want to go for.

I can not even pretend to know much about JSP and Servlets but I'm sure phobos will lend a helping hand on that front.

Any comment/help would be greatly appreciated, but please, don't wander off the topic.

As if anyone on these borings would wander off topic

[mental note]
Must start looking into learning JSP
[/mental note]

phobos

Yeah plain 'ol HTML is fine for doing your forms (text boxes, checkboxes, radiobuttons, and command/submit buttons) etc.

The action parameter of your HTML form will point to the Servlet or JSP code online. That code will then use a JDBC connection to the data tier (Oracle RDBMS).

There is a lot of ppl doing/learning this kind of thing right now. So I recommend you learn it, and while doing that keep in mind what you might do next. I'm going to say no more, coz I would be just rambling off the point.

;-phobos-)

Shiminay

I wonder do Bosco and Phobos know they're in the same college?



Anyway Ro - do what Weston says
(and the guitar's still in one piece).

DS

Oh man whatever you do just stay the hell away from JavaScript. It takes uselessness to a whole new level. It does very little that a server sided language can't.

The Corinthian

Originally posted by Enygma
You don't *need* a client-side scripting language at all. It's nice for some effects like mouse-overs etc. but for buttons, text-fields etc you just use plain ol' HTML.

You should try and get all your processing done on the server rather than the client, at least you'll know the environment and you have control. If you use JavaScript you're relying on the user to have it enabled on their machine.

There is certain functionality that the client (the ppl paying as opposed to a browser ) will almost certainly want that cannot be done without some degree of client side scripting.

As it's an intranet, you should have a degree of control over what browser it'll work on. Pin them down to a specific browser, such as IE 4+, and this will help where it comes to certain client-side compatebility issues that would normally find with VBS, JavaScript and in particular, DHTML (or is that dHTML :rolleyes: )

Catch_22

Originally posted by Discharger Snake
Oh man whatever you do just stay the hell away from JavaScript. It takes uselessness to a whole new level. It does very little that a server sided language can't.

Its a very nasty language one that i have never really got to grips with but im going to have to one way or another, howrever to say that there is very little it can do that server side cant is ver wrong. Ive seen java script intervaces written by people who have a couple of years experience with it and it an really do some pretty cool stuff, admittedly the result is 15-20 thousand lines of unreadable code but it can provide serious interactive functionality much more so than any server side scripting.

However on top of that there is the security issue which in any sort of widespread production environment means you are restricted to server side.

c22

dahamsta

Originally posted by Discharger Snake
Oh man whatever you do just stay the hell away from JavaScript. It takes uselessness to a whole new level. It does very little that a server sided language can't.

Horseputty!

JavaScript can be very useful for simple tasks, particularly for task acceleration and usability. Take form validation as an example - hackers tell us that forms should be validated on the server-side, and they're absolutely right in that, but faux hackers say that doing client-side validation is bad or wrong, because "what's the point in doing it twice?"

Well, I'll tell you the point - it accelerates the process. Most people have JS turned on, so if an error is made in the form and JS picks it up, it saves a call to the server, thereby saving time for the user and making them less inclined to just give up (this is vital in eCommerce applications). And of course it saves processing time and bandwidth.

And there can be no doubt that JS event handlers have proved invaluable for usability - onMouseOvers and onMouseOuts for demonstrating focus, onClick's and onSubmit's for validation, etc. JavaScript is very useful when it's used *correctly*. And although it's taken quite some time for crowss-browser standards to become accepted, they are getting there.

adam

DS

Ah sure I was a little trenchant in my comments, I mean I use JScript for everything you mentioned. But the thing is, there isn't anything you didn't mention! It's only good for form validation (as long as you double the validation on the server, you can't risk someone with JS turned off and sending corrupt data to the server, or someone deliberately turning it off to bypass a certain data test), the odd onmouseover and fancy image swap, and primarily speed. Everything else can be done a lot more safely consistently on the server, with the only sacrifice being the slight clumsiness of numerous server requests. JavaScript is definitely an important part of web development, indeed, many things are impossible without it, but it should never be an integral part of any web application.

Nietzschean

all i have seen here is people slam java applets..they provide different functionality to server side pages and client side app's...you have alot of extra functionality in the form of even sockets....a chat program in asp is not nearly as effective as an applet...sure interfaces tend to be more tedious and not as nice as some other approachs but it has its uses...real time fully controled connection can have alot of uses to a website....and its good use of proper java.....and as for the issue with ms not supplying it in XP afaik there new updating software is good in this aspect...for the home user a small 5meg or so download is requested to be done on a once off so java applet's can be viewed...they didn't come from hell...ms did

Bosco

Hi folks,

Thanks to everyone who replied. I've learned much, believe it or not, and the thread didn't even deteriorate into a slagging match

Thanks again,

Bosco

dahamsta

On JavaScript:

Ah, there's plenty of other applications for JS man. Some of the DHTML stuff out there is not just very groovy, but often quite helpful too. And usability isn't just limited to mouseovers and that, there's other things too, like the "vB Code" in this very application. Coders don't use it a whole lot, but I'll bet Joe Average (or at least Joe Average that updates his browser more than ONCE A BLOODY DECADE) uses it quite a lot. On top of that there's all those little helpful doodahs scattered around the web, like currency and measurement convertors - the Euro being a big example. They're not strictly necessary, so if someone doesn't have JS, well, tough caca. But they are handy. And as JS improves and becomes more compatible, it'll be used more and more.

I agree with your final statement though, that JS shouldn't be relied upon. But that goes without saying really, and it doesn't mean it shouldn't be used, it just means it should be used *sensibly*. I mean, really, how many of us have sites that have to be absolutely perfect? And how many sites are? We'd all be using HTML 3.2 if we had to go that far. And we'd still have to either produce four or five sites to cover all the bases, or write backend code to make sure the correct code was delivered. And they'd all look pretty crap too...

But of course I'm one of those "forward thinking" people that thinks that anyone with JS turned off is a loony, and anyone that has cookies turned off is an even bigger loony. Security and privacy management isn't about understanding technology, it's about common sense, which an awful lot of users seem to be well short on. It'd do people a world of good to put all the meeja pundits crap about JS and cookies out of their mind, and talk to someone who actually knows what they're talking about. But then everyone who whinges about JS and cookies thinks I'm a loony. Go figure...

On Java:

Dunno where that rantette came from Serialkiller, since no-one in the thread knocked Java applets as far I can see, but I'll tell why people do knock Java applets - it's because when Java first reared its ugly head, it was used primarily for absolute crap. The same people who injured our pride - and more importantly our sight - with BLINK and MARQUEE discovered Java and coded up stupid little doodahs that achieved nothing bar giving design and usability gurus brain tumours and coronaries. On top of that, the Java plugins didn't work very well, and the sight of "Starting Java..." in the status bar usually ended in a sigh of frustration and the occassional tempter tantrum. Windows 95 was bad enough, but adding Java into the fray was the straw that broke the camels back. And it was everywhere, you just couldn't get away from it.

But I've seen Java used for some superb applications. As you said, it remains by far the best application available for chat - there's simply no alternative out there unless you want to buy a multi-processor box, a gig of RAM and an Apache guru to tune the arse off the server. Flash doesn't even come close, it's cool but it's not right. I've also watched it being used by Jesus M. Castagnetto to build the Metalloprotein Database and Browser, something that is used daily by researchers around the world. And there's plenty more where that came from.

But Java got a bad rap because it was used primarly as a toy in the early days, just like Flash. And the same goes for Java as goes for JavaScript - and Flash - in that used sensibly it's a magnificent tool, but when it's used for something stupid like a marquee, it's an absolute crock. And that's why I have Java turned off in my browser. Because it's still used primarily as a toy. Some people never learn...

adam