Changing a server centric site to a more JS centric one [closed]

First of all, I’m not really a Javascript guy, but more towards PHP.
However, I want to move to the next level, that is taking load off the server and let the client do the processing. Hopefully to be a more JS guy.

My first thought is to request of data off the server, and it just returns key-values which the client will generate the HTML and puck in the values.

There are 3 problems generally:

I find it so much easier to generate the HTML in PHP cause data exchange between the server and HTML is fluid. Unlike returning data in JSON, which I then have to select the DOM that I want, and put in the values eg. $('.personRecord').html(data['name']).
I also find looping through arrays and generating HTML easier than JS?
I find myself using so much of jQuery selector to select the element I’m interested to manipulate and I’m not sure if that’s the correct practice (going forward to be a JS ninja). But I’m doing it cause it sure saves lots of characters.
In order to select the elements easily, I tend to give them unique class names as identifier. Again, I’m not sure if that’s what a JS Ninja will do.

Going forward (web trend), I would like to know if I should try to put more work to JS?
Also, any ideas or thoughts on how I can overcome my 3 problems stated above?
Is it a sin to return formatted HTML as part of a JSON value? Or should HTML be generated in JS and only read values off the returned JSON when it needs?

Putting frameworks aside (I know there’s Backbone, Angular, Can.JS and many more) does anyone really do raw JS scripting? I mean, it is possible but seems extremely wordy.

Lastly, please advice how one would convert a server centric site to a JS centric one?

If what I wrote doesn’t make any sense, hopefully you can point some JS centric sites, and explain what approach they are using as an example. Sites that are full featured (say..maybe facebook, twitter, stackoverflow) and not just a TODO web app.

jQuery is a fantastic DOM manipulation tool. What I have found though is that it is helpful to pair it with a good JavaScript templating tool (Knockout.js is one of my favorites because of the declarative data binding-like workflow it uses) precisely to do as little low-level manipulation as is possible. That said, jQuery has fantastic array looping with .each().
The selector is the correct practice for retrieving DOM bits to manipulate. However, I would refer back to #1 for how to avoid doing repetitive manipulations.
CSS classes should be applied to groups or things that may potentially become groups. If you really need to refer to an item directly, use an ID. It is typically preferred to group things with classes and seldom think in terms of manipulating some precise element.

Raw JavaScript (without even jQuery, Prototype JS or MooTools) can be written and can be used to manipulate the DOM. This is seldom done in practice because of the DOM implementation incompatibilities that a good framework will hide for you. If you write raw JavaScript you will quickly find that you are spending a good deal of valuable development time rediscoving oddball JavaScript/DOM incompatibilities.

As for how to perform such a conversion, there are two angles to consider: project management and technological. From the first perspective, you probably do not want to do some wholesale conversion. Rather, convert individual pieces as you fix bugs or augment their functionality.

The question lacks enough detail to provide a good technical answer. Moving towards an MVC-like architecture might be helpful. I have found web services, even very small ones, extremely helpful as they allow me to serve up fairly “dumb” pages (even if they are presented by something less-than-dumb like ASP.NET) and have the JS call off to the service to fill in data and perform operations.

Finally, you may want to step back and ask yourself why you are trying to make this transition. Better performance? Better user experience? What problem does it solve? There may be other solutions to your immediate problem.

Bear in mind that client-side scripting is no panacea. There are trade-offs. You need to be even more careful in your handling of data scrubbing and validation (which you should be doing anyway) and ensure that both your client and server side code can gracefully recover from errors presented by the other.

Filed under: softwareengineering - @ 13:17

Thẻ: javascript

Thiết kế website giá rẻ

Danh mục

Changing a server centric site to a more JS centric one [closed]