Re: [CODE4LIB] server side vs client side

[Nate Hill]

Other Nate,
this is *exactly* the advice I needed.
indeed, i want to interact with the circles.
Much thanks!
N


On Thu, Dec 1, 2011 at 10:59 AM, Nate Vack  wrote:

> On Thu, Dec 1, 2011 at 12:35 PM, Nate Hill 
> wrote:
> > I should have provided a bit more information here.
> >
> > Here's a rough in-progress view of what I'm up to.
> > http://www.natehill.net/loadsketch/donerightclasses.html
> >
> > I was using processing.js to read a file and then visualize some of the
> > data... you can see the circles are being generated from the values in
> the
> > .txt file.
>
> If you want to be able to interact with the circles (and I would!),
> I'd recommend d3.js as an interface framework. SVG is slower if you
> want to draw lots of elements, but your elements are part of the DOM,
> so you can bind event handlers to them and such.
>
> And d3's approach of binding data and elements together is really
> elegant. It's remarkably easy to do stuff like this:
>
> http://mbostock.github.com/d3/ex/population.html
>
> With regards to your first question: parse the text into JSON,
> server-side, and send that. Modern browsers can process obscenely
> large JSON arrays really fast. You could parse the text client-side,
> but
>
> -n
>



-- 
Nate Hill
nathanielh...@gmail.com
http://www.natehill.net

Re: [CODE4LIB] server side vs client side

[Joe Hourcle]

On Dec 1, 2011, at 12:49 PM, Nate Hill wrote:

> As I was struggling with the syntax trying to figure out how to use
> javascript to load a .txt file, process it and then spit out some html on a
> web page, I suddenly found myself asking why I was trying to do it with
> javascript rather than PHP.
> 
> Is there a right/wrong or better/worse approach for doing something like
> that? Why would I want to choose one approach rather then the other?
> 
> As always, apologies if I'm asking a terribly basic question.


There's different advantages to each side:

JavaScript / JScript / ECMAScript / client side:
Scales better (as the clients do their own work)
More obnoxious to maintain (as different browsers may have slightly 
different implementations)
Less reliable (I keep mine turned off on my main browser)
Better detection of client features (you can always lie in a browser 
string, or just not send it)
May require extra layers of abstraction (APIs that then require extra 
taint checking)
More responsive for simple operations (if doesn't need remote calls)
Easier to do some tasks

PHP / ColdFusion / CGI / ASP / server side :
You can be assured that you know it's working, and error reports when 
it's not (assuming you log & check your logs)
the inverse of all of the ones in the 'client side' section
(but the inverse of 'Easier to do some things'  is till 'Easier to do 
some things')



I'm not going to make any claims about speed, as it's frequently dependent
on bandwidth/latency.  (if I can send data to the client on a slow link, and
have them build the structures around it, it might be faster than my doing
it server side, and more so if my server gets bogged down)

For some tasks, I'll do it both ways.  Eg, form input validation -- 

Once in javascript, so they get the warning *before* the submit the form,
and again on the server side, in case they have javascript off or are being
malicious.

-Joe

Re: [CODE4LIB] server side vs client side

[Nate Vack]

On Thu, Dec 1, 2011 at 12:35 PM, Nate Hill  wrote:
> I should have provided a bit more information here.
>
> Here's a rough in-progress view of what I'm up to.
> http://www.natehill.net/loadsketch/donerightclasses.html
>
> I was using processing.js to read a file and then visualize some of the
> data... you can see the circles are being generated from the values in the
> .txt file.

If you want to be able to interact with the circles (and I would!),
I'd recommend d3.js as an interface framework. SVG is slower if you
want to draw lots of elements, but your elements are part of the DOM,
so you can bind event handlers to them and such.

And d3's approach of binding data and elements together is really
elegant. It's remarkably easy to do stuff like this:

http://mbostock.github.com/d3/ex/population.html

With regards to your first question: parse the text into JSON,
server-side, and send that. Modern browsers can process obscenely
large JSON arrays really fast. You could parse the text client-side,
but

-n

Re: [CODE4LIB] server side vs client side

[Jonathan Rochkind]

Sometimes asking the question helps you arrive at the answer, especially 
when you have to explain to us people without the context why our 
answers weren't what you were asking!


I am only vaguely familiar (as in "heard of it") with processing.js.  Is 
it typically run client-side in the browser, or server-side in a JS 
interpreter?  What's it intended for? Certainly wanting to use 
processing.js is one reason to do things in javascript.


I don't think trying to get in-browser javascript to read in a text 
file is going to be a very easy thing to do though. (Or a very 
possible thing to do, depending on exactly where this text file is 
located).


On 12/1/2011 1:35 PM, Nate Hill wrote:

I should have provided a bit more information here.

Here's a rough in-progress view of what I'm up to.
http://www.natehill.net/loadsketch/donerightclasses.html

I was using processing.js to read a file and then visualize some of 
the data... you can see the circles are being generated from the 
values in the .txt file.
The actual text in the right column isn't being rendered as html, it's 
being drawn in the canvas... which is stupid, i need it to be html and 
actually do some stuff with it.


I'm going to rethink my approach on this whole thing, it may have been 
flawed from the start. Thanks folks.


N

On Thu, Dec 1, 2011 at 10:24 AM, Jonathan Rochkind > wrote:


Well, you need to use javascript if you want it to run in a
browser.  So that's one reason to pick it, and the main reason
people pick it for it's most popular uses.

It will be very difficult to get javascript running in a browser
to do what you just said though. Not sure if you were running your
js in an arbitrary client's browser, or server-side.

You _can_ run javascript server-side, but it requires setting up a
JS interpreter of some kind, etc., and most people don't do it
just for the heck of it, they do it because they have some
specific reason to want javascript for that. They want to be on
the cutting edge trying out crazy new things, they just love
javascript, they particularly want the non-blocking functionality
of the node.js server, they need to interact with other libraries
of functions already written in js, they have some crazy plan to
share code between server-side and client-side, etc.

So, yeah, I think you were on the right track, I'm not sure why
you were trying to do that in javascript either!




--
Nate Hill
nathanielh...@gmail.com 
http://www.natehill.net

Re: [CODE4LIB] server side vs client side

[Nate Hill]

I should have provided a bit more information here.

Here's a rough in-progress view of what I'm up to.
http://www.natehill.net/loadsketch/donerightclasses.html

I was using processing.js to read a file and then visualize some of the
data... you can see the circles are being generated from the values in the
.txt file.
The actual text in the right column isn't being rendered as html, it's
being drawn in the canvas... which is stupid, i need it to be html and
actually do some stuff with it.

I'm going to rethink my approach on this whole thing, it may have been
flawed from the start. Thanks folks.

N

On Thu, Dec 1, 2011 at 10:24 AM, Jonathan Rochkind  wrote:

> Well, you need to use javascript if you want it to run in a browser.  So
> that's one reason to pick it, and the main reason people pick it for it's
> most popular uses.
>
> It will be very difficult to get javascript running in a browser to do
> what you just said though. Not sure if you were running your js in an
> arbitrary client's browser, or server-side.
>
> You _can_ run javascript server-side, but it requires setting up a JS
> interpreter of some kind, etc., and most people don't do it just for the
> heck of it, they do it because they have some specific reason to want
> javascript for that. They want to be on the cutting edge trying out crazy
> new things, they just love javascript, they particularly want the
> non-blocking functionality of the node.js server, they need to interact
> with other libraries of functions already written in js, they have some
> crazy plan to share code between server-side and client-side, etc.
>
> So, yeah, I think you were on the right track, I'm not sure why you were
> trying to do that in javascript either!
>
>


-- 
Nate Hill
nathanielh...@gmail.com
http://www.natehill.net

Re: [CODE4LIB] server side vs client side

[Jon Gorman]

On Thu, Dec 1, 2011 at 11:49 AM, Nate Hill  wrote:
> As I was struggling with the syntax trying to figure out how to use
> javascript to load a .txt file, process it and then spit out some html on a
> web page, I suddenly found myself asking why I was trying to do it with
> javascript rather than PHP.
>
> Is there a right/wrong or better/worse approach for doing something like
> that? Why would I want to choose one approach rather then the other?
>

I tend to try to do most stuff server-side.  Javascript I try to keep
just to enhance the GUI system and perhaps do some AJAXy stuff.  There
is the fact that if you're using an external API that's not crucial
you might want to just do it javascript side.  So think about cover
images in a catalog for example.

You could have the server-side script go out, grab the image, put it
in a local cache, then prepare the link within the actual html.  But
if something goes wrong, you might either take really long to return
that page or never return it.

The approach that most folks do is that they have some javascript that
does an AJAX call.  So the page loads on the client and then when the
image comes back the cover image will be added.  If it never happens,
you've sent the page at least.

I know some who tend to always go to javascript because they're used
to not having control of the underlying system except for to add html
to templates and sneak in javascript that way.

However, that's awkward, difficult to maintain, error-prone, and
likely horrible for accessibility.  If you control the underlying
PHPthen yeah, do it on the PHP side ;).

My advice here is somewhat simplistic and general.

You do have my curiosity up now though.  What was you goal with trying
to load that text file?

Jon Gorman

Re: [CODE4LIB] server side vs client side

[Ken Irwin]

My general approach is "server-side first". Unless it's wildly easier to 
accomplish something client-side, then I think it makes sense to go for the 
consistency of server-side processing. 

So taking a text file, doing some processing, and spitting out what should 
behave for the user as if it's a static HTML document, server-side 
PHP/Perl/DrugOfChoice sounds like the way to go. 

Save client-side processing for the things it does much better than the 
server-side alternative; mostly, I think that means use JavaScript for 
browser-interactivity stuff that's easier to do in the browser. 

Ken

-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Nate 
Hill
Sent: Thursday, December 01, 2011 12:49 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] server side vs client side

As I was struggling with the syntax trying to figure out how to use javascript 
to load a .txt file, process it and then spit out some html on a web page, I 
suddenly found myself asking why I was trying to do it with javascript rather 
than PHP.

Is there a right/wrong or better/worse approach for doing something like that? 
Why would I want to choose one approach rather then the other?

As always, apologies if I'm asking a terribly basic question.

--
Nate Hill
nathanielh...@gmail.com
http://www.natehill.net

Re: [CODE4LIB] server side vs client side

[Jonathan Rochkind]

Well, you need to use javascript if you want it to run in a browser.  So 
that's one reason to pick it, and the main reason people pick it for 
it's most popular uses.


It will be very difficult to get javascript running in a browser to do 
what you just said though. Not sure if you were running your js in an 
arbitrary client's browser, or server-side.


You _can_ run javascript server-side, but it requires setting up a JS 
interpreter of some kind, etc., and most people don't do it just for the 
heck of it, they do it because they have some specific reason to want 
javascript for that. They want to be on the cutting edge trying out 
crazy new things, they just love javascript, they particularly want the 
non-blocking functionality of the node.js server, they need to interact 
with other libraries of functions already written in js, they have some 
crazy plan to share code between server-side and client-side, etc.


So, yeah, I think you were on the right track, I'm not sure why you were 
trying to do that in javascript either!

[CODE4LIB] server side vs client side

[Nate Hill]

As I was struggling with the syntax trying to figure out how to use
javascript to load a .txt file, process it and then spit out some html on a
web page, I suddenly found myself asking why I was trying to do it with
javascript rather than PHP.

Is there a right/wrong or better/worse approach for doing something like
that? Why would I want to choose one approach rather then the other?

As always, apologies if I'm asking a terribly basic question.

-- 
Nate Hill
nathanielh...@gmail.com
http://www.natehill.net