views:

47

answers:

1

I've been developing my first web based app for about two months now (I'm an undergrad student who is mostly experienced with C and Python with some Java thrown in to boot). So far my page works as a thin HTML layout (thin meaning a very simple layout, aka less than 50 lines of HTML) which is manipulated heavily by AJAX, primarily using jQuery. The AJAX is generated via. PHP in combination with SQL manipulation. This webapp will be used by a maximum of 6-10 clients (EDIT: users), and cross-browser compatibility is just a bonus; it seems IE7 is the weakest link.

I would like to know:

  1. What are the disadvantages of using such a client heavy approach vs. more browser 'loads' (note that I'm using bbq to deal with AJAX's breaking of back/forward/reload/bookmark/history). In my good conciseness as a new programmer trying to develop good practices should I focus my strengths on the principles of AJAX?
  2. Is the future of web development really moving as heavily towards the browser as a platform as I seem to perceive it? From my experience, it seem that scripting client side in JS makes for a half decent GUI toolkit, with AJAX backing it up as an easy to use data access layer.
  3. Obviously server side scripting will always have it's place. Where does server-side truly shine? eg: a) generating XML that will be injected via. JS and the DOM b) generating HTML that will be injected directly (no DOM manipulation) c) creating full pages that can be used within an iframe.

I'm trying to strike a balance, and it seems that everything I've read so far lacks a balanced perspective and just pushes AJAX as the end all and be all.

+1  A: 

Wow, that's serious topic and so many answers are possible.

In the industry, Ajax and client-side scription usage are as a productivity and maintainability issue as a GUI or usability tool. It's sometimes easier (especially in an MVC server environnement) to get only a part of content rahter than all content. But it's almost question of point of view

I'll try to answer your 3 questions, just remember I'm like you in the sense I think many articles or book really lacks of balance (obviously, me too) :

  1. To me the main disadvantage of using heavy javascript on client (such as building all GUI in JS) versus serving HTML pages from server is the lack of control you get over errors, little graphical bugs, environnement differences, etc. You end up acting like a software vendor distributing desktop applications, you cant get real control over useability on client-side. Of course, this disadvantage can be almost totally struggled using a browser agonstic framework (like jQuery) and running rendering tests in many environnement. You should try both technicles, using Ajax is not always best and it can sometimes save your life (go build a dynamic tree with multiple selections and millions of branches with only HTML). I general I apply this rule : if user changes screen (ie between a listing and a form) I reload the whole page, if not I use Ajax.

  2. I must disagree, in web developement, client side scripting wil still keep being used for GUI stuff, except for offline web solutions (like Gears) there is no reason the browser embeds databases or hard business logic. Business layer is just too important to us to rely on browser to handle it. Data storage is on the same position (again to me) it has to be kept on servers. This separation of concerns is in my everyday job and I think these huge responsibilities can never be delegate to a browser, there is just too much insecurity, incompatibility, bugs issues.

  3. Server side shines at all stages I stated below, but as for data transfer format I prefer transferring directly HTML to browser or using JSON for any other structured data I need to pass. Using XML seems a little verbose to go for lightweight clients. If you can avoid iframe, do it, there is no reason to use them in 99.9% of cases I've saw.

As a matter of conclusion, you're student, learn things that are interesting. If you prefer improve your knowledge on client side, do it, there is a lot to learn here (HTML parsers, DOM and JS apis, browser internals are really interresting to me).

But you have to know in corporates I've worked for, the web as 2 meanings : communication and a support for business application GUIs. I currently work for web applications (intranet), we are 3 front end developers doing PHP and javascript while there are 20 people doing server side Java. Just to give you the place taken by GUI in professional wide scale apps.

Benoit
Awesome answer, the most insightful thing I've read as a student who will be entering the industry within the next two years. I'm intrigued about the browser being used as a platform for apps, as it seem(ed!) it was going to be a hairy process distributing my under the table app in a corporate environment, and, well, I'm a Google fanboy. I could have whipped up an app using Python in half the time it's taken to learn and develop in PHP, Javascript, AJAX and the DOM. Glad I took the time to learn however! From my limited experience however, the browser won't be replacing native apps very soon.
Eric Coutu
Sure browsers won't replace desktop apps, it's well fitted for almost all administrative gui (forms, etc). For heavier GUI, java web apps are just great too
Benoit