decisions decisions -- json - ajax - html and dom kungfu

23 views
Skip to first unread message

Jimmy Brake

unread,
Nov 8, 2011, 1:44:34 PM11/8/11
to prototype-s...@googlegroups.com
Hi,

About two years ago I built an app almost completely in js and json. The only thing in good ole HTML were the instructions.

I really liked the final product. If I had built the app my normal way of .. a little HTML, a little js and a healthy dose of ajax.updater .. aka HTML in my replies ... I would have been done much faster.  However I really liked how clean the code was and how easy it was to extend the app.

Now we have just finished an app of similar complexity .. and just to get it out the door we used the tried -- true and sort of ugly ajax.updater. However I really want to take the one or two weeks and remove all the HTML and replace with 'new element -- insert/update'.

Pros
  1. imho much cleaner code
  2. easier to extend because of #1
  3. more reusable code
  4. according to the prototype docs less prone to weird cross browser foo because prototype can work it's magic
  5. way faster because I just pass the data(JSON) and the controller(JS) and the browser generates the view -- my initial app was blazing fast
Cons
  1. will take between one and two weeks to rip out the HTML and replace with JS
  2. utterly foreign to people that are not familiar with 'new element'

Thoughts ....?

Victor

unread,
Nov 9, 2011, 2:34:19 PM11/9/11
to prototype-s...@googlegroups.com
So you plan to receive JSON from server, then convert it to HTML and insert into page? HTML fragments are much easier in writing/validating/processing.

Richard Quadling

unread,
Nov 11, 2011, 3:35:51 AM11/11/11
to prototype-s...@googlegroups.com
Also, the use of templates may be a better option, especially if you
are populating pre-defined fragments.

Just supply the data to the template evaluator and insert it into the DOM.

On 9 November 2011 19:34, Victor <vkhom...@gmail.com> wrote:
> So you plan to receive JSON from server, then convert it to HTML and insert
> into page? HTML fragments are much easier in writing/validating/processing.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Prototype & script.aculo.us" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/prototype-scriptaculous/-/DAxhHxaBOFkJ.
> To post to this group, send email to
> prototype-s...@googlegroups.com.
> To unsubscribe from this group, send email to
> prototype-scripta...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/prototype-scriptaculous?hl=en.
>

--
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370

Eric

unread,
Nov 11, 2011, 7:29:53 AM11/11/11
to Prototype & script.aculo.us
Hi,

On Nov 9, 8:34 pm, Victor <vkhomyac...@gmail.com> wrote:
> So you plan to receive JSON from server, then convert it to HTML and insert
> into page? HTML fragments are much easier in writing/validating/processing.

I am not so sure about this.
It really depends of what you want to do with the result from the
server.
If it is text/image and more or less static stuffs, you may return
HTML fragments, but if you plan to store/use those data for
computation, JSON return is definitely the best choice.
Also HTML fragments don't allow to do everything on all browsers
(things like inserting rows into an existing table or options into an
existing select tag for example are known to cause issues).

Like Richard said, templates are a good choice here too if your data
are often formatted in the same way.

Eric

Jimmy Brake

unread,
Nov 15, 2011, 2:43:04 PM11/15/11
to prototype-s...@googlegroups.com
Good thoughts and suggestions - thanks

I'll see if I can make a 'case' for the extra coding overhead.

  1. a gazillion connections if I have to send html in little pieces all the time - i am very very concerned about overloading the servers (total 80cores - 160gigs of ram - ~500gigSSD - not shared 100meg connection - internal network between the nodes is gigabit) --- with the json method - we do the initial DB dump - then each selection is sent to the servers
  2. when the session starts I put the entire menu db (max 2100 items - average is only about 150 items) as a var in the page
  3. i use that data to draw the menus and the submenus(submenus are dynamically shown as a client selects them)
  4. once an item is selected it's displayed in the list of selected items -- i also tee that process and send a json packet to the server
  5. we are only supporting ipads 
Make sense? -- if not let me know ..






--
You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group.

Jimmy Brake

unread,
Nov 15, 2011, 2:43:21 PM11/15/11
to prototype-s...@googlegroups.com
What you said is mostly true on both accounts. What I like about the straight json method is I can dump pretty much all the data they would use over the entire course of the session in just one response probably no more than  40 k for really large data sets. 

On Wed, Nov 9, 2011 at 11:34 AM, Victor <vkhom...@gmail.com> wrote:
So you plan to receive JSON from server, then convert it to HTML and insert into page? HTML fragments are much easier in writing/validating/processing.

--
You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group.

shellster

unread,
Nov 16, 2011, 4:46:52 PM11/16/11
to Prototype & script.aculo.us
Browsers are getting faster, and I am finding that it is far quicker
to pass data back as json, then use a JS templating engine to covert
the data into its HTML representation on the user's side.
Reply all
Reply to author
Forward
0 new messages