[metrics-team] JavaScript on metrics.torproject.org

[tl]

I think the discussion has a few different aspects and it’s worth to get them clear:

Target audience:
If the viszualizations on the metrics site are targeted at end users or the inetersted public in general static visualizations would probably be sufficient to illustrate all basic facts that we want to get across. More sizzle doesn’t hurt but it’s not necessary.
Everyone seriously interested in the data could benefit quite a lot from interactive visualizations because they make it much easier to get to the specific aspect that one is interested in. Question is: wouldn’t people willing to work with the data in a serious way use somehing much more specialized anyways, some offline tool, local installations?

Security:
Switching to D3-based visualizations would make it possible to add ineractivity and animations through JavaScript. This is not eye candy but functionality, ultimately more information, at the expense of security. That extra interactivity wouldn’t be accessible with the Tor browser in high securiy mode. The base visualization itself stays accessible to everybody, some interactivity can be achieved through tradutional HTML means (forms, iframes)

Technology stack:
The site is based on servlets and is technologically getting stale. Switching to JavaScript enhanced visualizations would lead to the question why not base the whole website backend on JavaScript, especially if we need to implement technology that allows serverside generation/emulation of Javascript technology if the client has JavaScript disabled. Everything would be made from one technology then, easing maintenance and attracting contributors

Developers:
Switching to a JavaScript based site would attract webby developers and turn away C/Java/Python/gnuplot people. Would that be more a risk or a chance?

Information:
It is important to understand that interactivity done right equals information. We use  visualizations to make information accesssible in graphs that would otherwise be buried in columns of numbers. Interactivity makes it easier to access much more graphs. Animation make correlations easier to understand.


> On 15.01.2016, at 14:25, Karsten Loesing <karsten at torproject.org> wrote:
> 
> Signed PGP part
> On 13/01/16 01:00, tl wrote:
> > Hi Karsten,
> 
> Hi thms,
> 
> > tl,;dr
> 
> Indeed, this was a really long posting, and I understand that it's due
> to the fact that this is a very broad discussion.  But we should both
> try to keep our postings as short as possible, both to prevent this
> discussion from stalling and to make it easier for others to follow
> along and chime in.

Well, you did ask for a discussion, didn’t you? I did write _that_ long last time because you profoundly misunderstood me the time before. But since it seems that you misunderstood me last time again maybe terseness would be more heplful anyway. I’ll try [8]! And sorry for the edgyness in my last mail! That got me worried more than it’s length, afterwards.

But it is indeed a broad discussion and it won’t get easier if we don’t try to keep all aspects in view.

> > I think we have a misunderstanding here. I’m speaking about two
> > ways of using JavaScript: server-side and client side. Client side
> > I’m totally in favor of a site that works without JavaScript as far
> > as possible - and that is quite far - but adds functionality for
> > those that have JavaScript enabled and that is not possible to
> > convey without client side Javascript. Server side there are
> > reasons why I think it could be beneficial to use a JavaScript
> > framework, but I have no idea about the security implications
> >
> >
> > Longer:
> >
> > I think that almost all of what the Metrics site or other sites in
> > the Tot network need can be done without client side JavaScript.
> > These are static pages, serving text and a few bitmaps and there’s
> > absolutely no reason why they should demand the use of JavaScript.
> > Sites like Atlas and Globe could be done perfectly fine without
> > client side JavaScript and if I understood correctly they where
> > done with one of the heaviest JavaScript frameworks around just
> > because it was the fastest way to do it - which often translates to
> > "that was the tool that we knew already".
> 
> Agreed.  And yes, we didn't have a discussion like this for Atlas or
> Globe.  Maybe they would have written differently if we had.
> 
> > But client side JavaScript comes into play when you want
> > interactive visualizations. There are 2 graph visualizations on the
> > bottom of a random Globe page I visited [0]. These graphs can be
> > generated on the server and delivered to the client as SVG vector
> > graphic or as PNG bitmap graphic. But there is also a slider under
> > these graphs with which you can control the period to be shown.
> > This is client side JavaScript. It allows you to intuitively select
> > a period and to update the graph accordingly without a whole page
> > reload - thus allowing to play with the data, making the experience
> > of drilling for details fluid and seemingly effortless blabla.
> > Ahem, well, sort of, but you get the idea. Without client side
> > JavaScript you have to resort to form-based interfaces. These don’t
> > need to look bad either - CSS  made the 1990 form styles go away
> > for good - and you can mitigate the page-reload problem by putting
> > the graphics in an iframe. So it’s not all black or white but you
> > can easily imagine that these tricks will only get you so far while
> > some features are just not possible achieve without client side
> > JavaScript. For example you won’t get animations without JavaScript
> > (there are special cases where CSS animations can save your ass,
> > but not in general and not with reasonable effort as far as I
> > know). Animations and fluid interactions are not just gimmicky
> > nice-to-haves. Animations can be very important to understand
> > transitions and thereby correlations, good interaction is key to
> > successfully investigating the data. Look for example at the dc.js
> > standard exampel [1] and try a) not to be impressed and b) to do
> > that without client side JavaScript. No way!
> >
> > So: there is stuff that is as cool to have as impossible to do
> > without client side JavaScript. We can always say "we’ll try" - and
> > we should! - but we will ony get that far. And like Letty I want to
> > able to do the cool stuff too. Most of the work is in aggregating
> > the data and setting the whole thing up. That people with high
> > security settings won’t see it shouldn’t mean that nobody else can
> > profit from it.
> >
> > It’s easy to do meaningful rudimentary non-scripted static versions
> > of JavaScript heavy visualizations. It’s not so easy to do them
> > well and as good as posssible. There certainly is the danger of
> > moral hazard: putting much love into the shiny scripted
> > "experience" and neglecting the tedious, somehow bolted on
> > form-based version. I hope that the isomorphic JavaScript
> > frameworks that I wrote about in my last post help here, becauese
> > they allow to render server side what normally the client would
> > render. But that really has to be tested to be sure and I fear that
> > a quick Proof of Concept will not reveal all problems and
> > possibilities.
> >
> > Realisitically I think we should define which visualizations we
> > want, like: what is the basic stuff that really needs to be there -
> > and do that without client side JavaScript as good as possible.
> > There will inevitably always be ways to make it even better with
> > client side JavaScript, and we should try to implement some of
> > those too, as examples and tool boxes for how to build client side
> > JavaScript that goes the extra mile and stays accessible to
> > non-Javascript enabled browsers. Hopefully the isomorphic web
> > frameworks will enable us to do that without too much extra work.
> > Apart from that we can’t do much more than appeal to people to take
> > the need for non-scripted web pages serious and use the tools and
> > examples that we are able to provide.
> 
> I think the first question we need to answer is how interactive we
> *need* our visualizations to be.  I agree that Globe's slider for the
> time period shown is useful, and I can see how animations can help
> understanding correlations better.  But we should be able to come up
> with a few concrete examples where less interactive visualizations are
> simply insufficient to educate the public about certain aspects the
> Tor network.

It always depends on what you want to achieve. If you want to educate the general public about the topic of directory disagreement, then one screenshot of a typical view an Lettys animation provides a fine illustration.
If you want to use the visualization to examine how often the ratios of disagreements change, or what are the extremes and how often they occur etc or, ultimately, if you have to find out what the typical situation in authority disagreement is, then the more interactivity, the better.

Since information hidden in the data but not accessible without unwholesome effort amounts to no information at all, interactivity directly translates to information. Of course not everybody needs all of it. If the graphs on Tor metrics only serve to proovide some general introduction then we can get away without JavaScript okay (although the general public surely loves animation and interactivity).
If those graphs are meant as tools for developers too, then the more JS the better I’m afraid.

> That's why I made a "site map" of Metrics that shows all graphs that
> are either currently implemented or that are planned to be added at
> some point.
> 
> https://people.torproject.org/~karsten/volatile/metrics-sitemap.pdf

That looks good but do you also have a list of links to these visualizations?

> Can you maybe pick two or three of these visualizations, or suggest
> related ones, where you think that interactivity based on client-side
> JavaScript would make the visualization significantly better?
> 
> > Now server side JavaScript: given the above somehow passionate plea
> > for _some_ client side JavaScript I sort of took it for granted
> > that porting the backend to JavaScript too would be the sensible
> > thing to do, especially if we find that an isomorphic web framework
> > like React really delivers on the promise and makes it easier for
> > us to serve scripted visualizations that are rendered on the server
> > if the client has JavaScript disabled. There are more and more web
> > developers that can code JavaScript and feel at home in a
> > Node.js-based environment but for whom a Java- or Python-based web
> > framework would be mostly intimidating (you can count me in). So:
> > why not?! Maybe not because of security concerns, and as I said
> > already: I have no idea what is secure in that realm and what
> > isn’t. Node.js is in Debian stable, but what does that mean? Is
> > therefor every package that runs inside Node.js safe too? Or is it
> > not?
> >
> > One important thing to consider is that client side JavaScript
> > can’t harm anybody who hasn’t enabled JavaScript in the first
> > place. Sure, if we provide cool interactive JS-driven
> > visualizations we provide incentive to enable it
> >
> > You might have problems with moral hazard, but might also have
> > problems with no hazard at all because not many people want to work
> > under a strict non-JS regime.
> 
> I think many of these concerns are addressed on this wiki page:
> 
> https://trac.torproject.org/projects/tor/wiki/org/operations/Guidelines
> 
> Regarding packages running inside of Node.js, specifically those that
> are installed using npm, those would fall under "Packages installed
> via third-party package managers (really bad)".  And as you can see,
> Metrics is guilty of doing that by requiring some R packages, even
> though I think we could as well switch to Debian packages for those.
> But given that we might away from them, I'll leave everything as it is.

Ok, thanks for the answer.

> >> On 12.01.2016, at 13:00, Karsten Loesing <karsten at torproject.org>
> >> wrote:
> >
> > [...]
> >
> >> What do you think about building a small prototype of a
> >> visualization that requires client-side JavaScript and another
> >> one that doesn't? Most people are not web developers, so they can
> >> hardly follow the discussion of web techniques here.  Giving them
> >> an actual example might make it easier for them to understand the
> >> differences.  I'd be willing to help with building these
> >> prototypes.
> >
> > Take Lettys visualization and take away the animation and the time
> > slider. Take away the time sliders from [0]. Never have something
> > like [1]. I could pick some more examples from the D3 gallery [2].
> > Do we really need more proof?
> 
> I could imagine taking away the animation and time slider from Letty's
> visualization and still having a very useful visualization.

Yes. But which time would you choose, and how. The slider and the animation help you a lot to spot irregularities, which is important. Also, see above with respect to target audience. Showing a screenshot to a newbie is good, but it’s not good enough if you want to understand the sources of the problem, how it evolves and what could be done to mitigate it.

> And I could imagine taking away the time slider from the Globe graph.

Time-selection is doable with form-based interfaces too, but
- much more effort to use
- therefor less likely to happen.
And which timeframe would you choose? Is that enough?

> What I cannot imagine yet is never having something like that specific
> D3.js sample visualization, but just because I don't know how much
> we'd be missing in the specific case of visualizing Tor network data.
> Right now, I can live without it.  I can't say yet whether I will be
> addicted by it in the future.  This is related to my request above for
> specific examples that would benefit vastly from more interactivity.

Well, you’re being a little unimaginative here ;-) But give me the links and I’ll try.

> > I’m getting a bit edgy and probably I'm not the best embassador
> > with respect to the usage of JavaScript: I had discussions pro/con
> > JavaScript in leftist circles since 20 years, I had discussions
> > pro/con fax machines before and in between I had discussions
> > pro/con CSS, because some die hard anarchists considered it street
> > to stick with their rotten Netscape Communicator 4.7.6. I find
> > these discussions most often very arbitrary: mail is okay, but fax
> > is not. Fax is okay, but computers are not. Computers are okay, but
> > not databases. The web is okay, but not JavaScript, and so on. Why
> > not just say: it depends. Can it harm somebody, can it profit
> > somebody, can somebody profit without someone else being harmed?
> 
> While I see your point, I want to note that this situation is a bit
> different.  Tor is both shipping the Tor Browser and advocating that
> users stay safe on the Net which may include turning on the
> high-security mode.  At the same time Tor is providing content on Tor
> Metrics that requires users to lower their security setting, at least
> for the really cool stuff.  You see the contradiction there.  That's
> why I don't want to make this whole decision lightly.

I don’t take it lightly either. I’m very interested in providing solutions that satisfy both concerns. I just don’t see why the security concern should overrule any other aspect. There should be compromise, - with an emphasize on security, but with exceptions too.

It’s not about 'cool stuff' and flashy glizz, it is about functionality and access to information - which is of course the ultimate cool.

> > I totally respect security concerns. I absolutely understand
> > concerns about moral hazard like in the example above and I think
> > we should have that in mind and try hard to mitigate it. I find it
> > a good and satisfying challenge to achieve as much as possible
> > without JavaScript. But I also think that JavaScript is a cool
> > technology, that being able to script visualizations provides
> > really useful and otherwise unachievable benefits and that we
> > should not give those away because some people can’t profit from
> > them. That sort of standardization on the lowest level only causes
> > frustration.
> 
> I hear you with regard to developer happiness and wanting to use cool
> technology.  That's certainly a factor here.
> 
> But please also hear me with regard to user happiness (which includes
> Tor Browser users on high security)

Well, that is not the real contradiction here. It did emphasize in all my posts so far that I value the happiness of Tor Browser users on high security. I do question however what they gain by taking away interactivity from other users, about whose happiness I’m concerned too.

> and system administrators (who
> really hate it when we use non-standard package managers that put
> their systems at risk).

That is another thing and I’ve been asking for guidance on it in my last few mails on this topic.

So npm, although itself in Debian stable, is not enough. I still find the Debian Package Manager site quite unhelpful when I want to find out which packages are in stable and which are not but I seem to have figured out that

- node.js [0]
- express (most popular web server and basic web publishing framework) [1]
- mustache (rendering/templating framework) [2]
- backbone (web publishing framework) [3]
- less (css framework) [4]
- browserify (port JS from server to browser) [5]
- jQuery [6]
- D3 (visualization) [7]

are all in Debian Jessie stable. Having Express and all the other web libraries in would seem like good news to my naive eye. The most important aspects are covered. There may be more but the bottomline is: there is enough.
I havn’t checked all the dependecies though, trusting in the reasonableness of the package repo.


> >> I have more thoughts on the web frameworks and on requirements
> >> like avoiding packages not contained in Debian stable, but I'll
> >> hold them back until we have that discussion.
> >
> > I’d love to hear about those thoughts right away!
> 
> I think I included all those arguments above.
> 
> Moving forward, I suggest we (you, I, others) write two prototypes to
> try out two different directions:
> 
> - MEAN (or just the EN part of it) with React and D3 to draw a graph
> either on the server or on the client, depending on whether the client
> has JavaScript or not.

It seems to me that react is not available for Debian stable. You certainly know your way around those archives better than I do so you should check yourself (please do, can you? I’d like to be sure).
There are other ways to achieve the same goal with more effort and within Debian stable, e.g. with Browserify, or with jQuery at the least (and most annoying, but well…). Given the absence of react from Debian stable I’d check them too before putting much effort in react.

> - Node with D3 to draw either the bubble graph or Letty's
> visualization, and iframes and CSS magic, to see how far we could get
> when abstaining from client-side JavaScript.
> 
> My sense is that we'll make more progress on this discussion by trying
> out some concrete approaches than by reinforcing our arguments given
> before.

If that makes the problem space clearer to you, very well, go ahead. I do fear though that you’re procrastinating. The real question is not the JS web frameworks but what D3 interactivity has to offer and if we need it. The world of JS web frameworks is  "vast an infinite", it’s hard not get lost there ;-)

> It's fine if you don't want to hack on these prototypes.  Just let me
> know, and I'll pick one and hack away.

Well, not just now. I don’t quite understand how this bubbled to the top of your priority list. I've put some effort in these mails in hope they are helpful. Building a prototype always takes me quite a while. I guess you’re more efficient in that respect.

> But even if you don't want to
> write code, now's still a good time to suggest different prototypes if
> you hope that the result will help us better in deciding whether or
> not to support client-side JavaScript on Tor Metrics.

One point of my longish posts was that non-JS versions can take us a long way, but JS-interactivity adds information and tooling, not just bells and whistles. The arguments to abolish them completely from the site should therefor better be very good, and I don’t see that.

Another point is that if we agree on using JS for some visualizations of the site than it also makes sense to switch the backend to state of the art JS technology, provided the security concerns can be adressed - which they can as I’m no convinced - since you want to get away from the servlets anyway.

Switching the technology stack of the Metrics site to JavaScript makes a lot of sense without using JS on the client side. You don’t have to prove the usefulness of client side JS in some cases to justify that transition. You can procrastinate the discussion about JS on the client side but lay the foundation for it being possible now without much downsides. You mostly gain. The cost of course is that you introduce Javascript to your technology stack-.

In the end I guess it’s most of all a question about contributors: you generate possibilities for genuine web developers to contribute but you’ll probably loose the C/Java/Python/gnuplot folks. Where do you want to steer that ship?


ciao
thms




[0] https://packages.debian.org/jessie/nodejs
[1] https://packages.debian.org/jessie/node-express
[2] https://packages.debian.org/jessie/web/node-mustache
[3] https://packages.debian.org/jessie/node-backbone
[4] https://packages.debian.org/jessie/web/node-less
[5] https://packages.debian.org/jessie/node-browserify-lite
[6] https://packages.debian.org/jessie/web/libjs-jquery
[7] https://packages.debian.org/jessie/libjs-d3
[8] without luck though




> 
> > Ciao thms
> 
> All the best,
> Karsten
> 
> 
> 
> > [0]
> > https://globe.torproject.org/#/relay/7C16F60CD2AEB2208ADF5B69187DDF8A61C85EAE
> >
> >
> [1] https://dc-js.github.io/dc.js/
> > [2] https://github.com/mbostock/d3/wiki/Gallery [3]
> > http://arstechnica.com/security/2016/01/going-forward-the-tor-project-wants-to-be-less-reliant-on-us-govt-funding/
> >
> >
> >
> >
> >
> >> All the best, Karsten
> >>
> >>
> >> On 08/01/16 15:28, tl wrote:
> >>> Two additions:
> >>>
> >>> - just found a list of popular isomprphic JS web frameworks:
> >>> http://isomorphic.net/libraries but nothing about which one
> >>> interacts the best with D3 - a decision about a simple
> >>> templating language on top of express would have to be made
> >>> too. Handlebars is popular, but I’m not an expert.
> >>>
> >>> And, while thinking about it, I’m increasingly inclined to
> >>> promote a solution where all pages that don’t require strong
> >>> interactivity are realized with a simple templating engine
> >>> (like Handlebars). For the few visualizations that benefit
> >>> heavily from client side JS, the templating engine would have
> >>> to be replaced by an isomorphic webframework like React. That
> >>> way, not all pages would be build the same way but most of them
> >>> would be quite simple to build and maintain.
> >>>
> >>>
> >>> Still waiting for comments and ideas before moving this topic
> >>> to tor-dev.
> >>>
> >>>
> >>> ciao thms
> >>>
> >>>
> >>>> On 07.01.2016, at 14:56, tl <tl at rat.io> wrote:
> >>>>
> >>>> Okay, answering my own post ;-)
> >>>>
> >>>> tl;dr: no Javascript for most of the site JavaScript as
> >>>> enhancements to pages where sensible server side based on
> >>>> Node, Express, React, MongoDB visualizations with D3
> >>>>
> >>>>
> >>>> I favor a solution where we have a site working fine without
> >>>> JavaScript and in some places even finer with JavaScript.
> >>>> With "some places" I mean additional interface elements to
> >>>> control (and play with) visualizations and maybe some
> >>>> additional site navigation too. There’s no question that
> >>>> omitting JavaScript is both praticable and a good thing to
> >>>> do, for reasons of security as welll as performance. But it
> >>>> is also undeniable that JavaScript can facilitate some
> >>>> awesome user interfaces especially with data visualizations
> >>>> that are not possible otherwise. JavaScript usage has been a
> >>>> contested topic right from the start in the 1990ies. My
> >>>> stance is: banning JS from ones personal browser is
> >>>> absolutely fine and reasonable and forcing JS on all users is
> >>>> unacceptable. Abolishing JS  however is a shame since it can
> >>>> be tremendously useful in building user interfaces, and
> >>>> interfaces are the connection between the user and the data
> >>>> (read: not negligible). Building interfaces that work fine
> >>>> without JavaScript but offer easier and more fluid
> >>>> interaction with JavaScript is harder than doing it only one
> >>>> way (either with or without JS) but it is possible without
> >>>> nasty hacks or excessive bloat. I think the extra effort is
> >>>> worth it and this is the way to go. Since IMO this settles
> >>>> the question if we should/could use JavaScript on the site it
> >>>> follows that we should also port the current metrics site
> >>>> backend to JavaScript/Node and base its visualizations on
> >>>> D3.js. That way the whole thing will be based on only one
> >>>> technology - but of course will still require mastering the
> >>>> building blocks. But now, enough with the fundamentalist
> >>>> foreword and down into the drudgery...
> >>>>
> >>>>
> >>>> It looks like we don’t need a full blown CMS since only two
> >>>> or three rather technical people will maintain the website.
> >>>> Therefor we can go with one of the established web frameworks
> >>>> and build the little admin interfaces we might need
> >>>> ourselves. A popular JS web framework stack is known by the
> >>>> name MEAN which mimics the LAMP acronym and stands for
> >>>> MongoDB, Express, Angular.js and Node: * Node.js is the
> >>>> JavaScript runtime in which all server functionality is
> >>>> hosted/embedded and is available as Debian stable package *
> >>>> MongoDB is a very popular database, based on JSON, available
> >>>> as Debian stable package as well. I worked a lot with it when
> >>>> aggregating data for the 'visionion' visualization project
> >>>> and although I’m not partucularily fond of it it makes
> >>>> working with slightly unregular document types rather easy.
> >>>> It provides mapReduce functionality to eventually aggregate a
> >>>> little data by the side and its JSON based data schema makes
> >>>> it easy to access from a web app. But I wouldn’t mind to work
> >>>> with PostgreSQL either. * Express is the de-facto standard
> >>>> for web servers in the Node ecosystem and a little more than
> >>>> that. It can be extended with some little templating engine
> >>>> to build sizeable static websites which would be all we need
> >>>> if we go the non-JS way on the frontend. * Angular.JS is a
> >>>> full blown web application framework (developed and backed by
> >>>> Google) - providing the view to Express instead of some small
> >>>> templating engine - that is rather popular (also Arturo
> >>>> recommends it ) and provides all you could ever need in one
> >>>> (big) box. The big downside is that it needs JavaScript on
> >>>> the client side.
> >>>>
> >>>> That’s the MEAN stack. Node and Express are de facto
> >>>> standards, MongoDB may be just fine. The interesting question
> >>>> is what to use for the view layer on top of Express: a simple
> >>>> templating engine doesn’t provide the JavaScript interface we
> >>>> desire to implement elaborate visualization interfaces while
> >>>> Angular.JS doesn’t provide the non-JS baseline considered
> >>>> mandatory. There exist of course a plethora of JS web app
> >>>> frameworks - too many to analyse them here. A few of them
> >>>> provide the new hotness "isomorphic rendering" which means
> >>>> that the site can be rendered on the server as well as in the
> >>>> browser. The original aim is to speed up initial pageload and
> >>>> optimize for SEO, but I hope it can be used to implement a
> >>>> non-JS-and-JS-too-site. If the browser does not support
> >>>> JavaScript it renders a page that was pregenerated on the
> >>>> server. For most of the metrics site there will be no
> >>>> difference at all since they don’t need any JavaScript. For
> >>>> visualizations though it can make a big difference.
> >>>> Visualization controls will be just (nicely styled) forms and
> >>>> interactions will require a roundtrip to the server.
> >>>> Visualizations will only be able to show limited amounts of
> >>>> data because they can’t fetch data in the background. Some of
> >>>> the worst problems with this approach can be mitigated by
> >>>> loading the visualizations themselves into iFrames, reducing
> >>>> flicker and loading times. If the browser is willing to
> >>>> execute JavaScript though additional data is fetched in the
> >>>> background, zooms and sliders and tooltips appear,
> >>>> animations make it easier to understand effects etc. It will
> >>>> be the same information, but it will be accessible much
> >>>> easier and make more sense. It remains to be seen how much
> >>>> code duplication that involves. Some of the interface
> >>>> elements would have to build as HTML form elements as well as
> >>>> D3 elements. There duplication is unavoidable. Those
> >>>> interface improvements that rely on fetching data in the
> >>>> background should be implementable rather seamlessly.
> >>>>
> >>>> All this is not exactly trivial. There will be obstacles but
> >>>> after some googling I’m quite convinced that there are
> >>>> sensible solutions too. React [0] (developed and backed by
> >>>> Facebook) is by far the most prominent of the frameworks to
> >>>> support isomorphic rendering [1]. React is a fine piece of
> >>>> technology on its own, rather popular (not as much as
> >>>> AngularJS, but still) and well supported too. In contrast to
> >>>> the all-encompassing AngularJS it only aims to be a view
> >>>> layer and integrates nicely with Express [2]. There is a
> >>>> problem though - React tries to control the DOM just like D3,
> >>>> the visualization engine - but there exist solutions to that
> >>>> [3]. Another, maybe less involved solution for isomorphic
> >>>> rendering is called Rendr [4]. It’s less well known and less
> >>>> supported though, so my first shot would be React. If none of
> >>>> these work out as hoped there’s always the possibilty to use
> >>>> a simple templating engine with Express and add
> >>>> JavaScript-based interactivity through jQuery to some
> >>>> selected visualizations that we think are worth the extra
> >>>> effort. That may not be very elegant or scalable, and more
> >>>> 2005 than 2015, but as a backup strategy it’s proven and
> >>>> works.
> >>>>
> >>>>
> >>>> A question that I have is about security: the latest version
> >>>> of Node in Debian stable is 0.10.29 from July 2014. That’s
> >>>> not bad. I wonder though if it’s save to load just about any
> >>>> module available to Node out there - as Node is the
> >>>> (hopefully) secure sandbox it runs in - or if we have to get
> >>>> Debian-stable npm packages for Express, React etc too? That
> >>>> might prove difficult…
> >>>>
> >>>>
> >>>> Ciao thms
> >>>>
> >>>>
> >>>> [0]
> >>>> http://blog.yld.io/2015/06/10/getting-started-with-react-and-node-js/
> >>>>
> >>>>
> >>
> >>>>
> [1]
> >> https://strongloop.com/strongblog/node-js-react-isomorphic-javascript-why-it-matters/
> >>>>
> >>
> [2] https://github.com/reactjs/express-react-views [3]
> >>>> http://oli.me.uk/2015/09/09/d3-within-react-the-right-way/
> >>>> [4] https://github.com/rendrjs/rendr
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 06.01.2016, at 22:30, tl <tl at rat.io> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Karsten, Letty and me recently had a conversation about the
> >>>>> use of JavaScript on https://metrics.torproject.org. The
> >>>>> problem space in brief is that the metrics site needs nice
> >>>>> visualizations which need nice interfaces which can profit
> >>>>> very much from some nice JavaScript whereas there are a lot
> >>>>> of nice people who very reasonably insist on deactivating
> >>>>> JavaScript in their nice Tor browsers. So: what to do? A
> >>>>> side aspect of this discussion is that the metrics website
> >>>>> needs a technical overhaul. It’s based on some hard to
> >>>>> maintain servlet/JSP and while we’re on it we could as well
> >>>>> port it to some JavaScript/Node based framework on the
> >>>>> server side if we decide to use more JavaScript anywy.
> >>>>> Following are some notes from the discussion.
> >>>>>
> >>>>> +
> >>>>>
> >>>>> Possible outcomes: 1. Don't require any JavaScript, works
> >>>>> without issues in high security mode. 2. Only require
> >>>>> JavaScript for some visualizations where it makes sense,
> >>>>> users will have to switch to medium-high security to watch
> >>>>> those. 2b. For visualizations that require JavaScript to be
> >>>>> really useful, provide a simplified version that works
> >>>>> without client-side JavaScript. 3. Require JavaScript for
> >>>>> most visualizations by first looking at making them as
> >>>>> usable and as useful as possible, rather than worrying
> >>>>> about users having to change their Tor Browser security
> >>>>> setting.
> >>>>>
> >>>>> Benefits and possibilities of using JavaScript - Ability
> >>>>> to load new data from the server, based on user input,
> >>>>> rather than pre-loading all the data that the user might
> >>>>> want to look at. - Handle user input more directly than via
> >>>>> HTML forms which require a server round-trip. - Let the
> >>>>> user decide whether they want to lower their security in
> >>>>> order to look at a visualization, rather than making that
> >>>>> decision for them. - It's sufficient to host static
> >>>>> content, which can be mirrored much more easily than
> >>>>> dynamic content.
> >>>>>
> >>>>> Possible approaches for passing on JavaScript - Avoid full
> >>>>> page reloads by using iframes. - Investigate more graph
> >>>>> frameworks than just D3.js, including gnuplot, R/ggplot2,
> >>>>> others.  A major reason for using D3.js is its tight
> >>>>> integration with user input elements. - Make heavy use of
> >>>>> CSS 3 features/tricks. - Add tooltips to canvas.
> >>>>>
> >>>>> Next steps: - Find out why the bubble graph takes so long
> >>>>> to load.  Try to avoid the parts that take long in future
> >>>>> graphs. - In addition to the bottom-up approach taken here,
> >>>>> also take a top-down approach by thinking about contents
> >>>>> and only worry about possible implementations later.
> >>>>>
> >>>>> Next steps after that: - Think about possible web
> >>>>> frameworks, like Angular.js if we decide to use JavaScript
> >>>>> or Django if we decide against it. - Look into alternatives
> >>>>> to Bootstrap, like Bourbon.io.
> >>>>>
> >>>>> +
> >>>>>
> >>>>> So far, so unclear. Input welcome!
> >>>>>
> >>>>>
> >>>>> ciao, thms ----
> >>>>> _______________________________________________
> >>>>> metrics-team mailing list
> >>>>> metrics-team at lists.torproject.org
> >>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>
> >>>>>
> < he not busy being born is busy dying >
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________ metrics-team
> >>>> mailing list metrics-team at lists.torproject.org
> >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> >>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> < he not busy being born is busy dying >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________ metrics-team
> >>> mailing list metrics-team at lists.torproject.org
> >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> >>>
> >>
> >
> >>>
> >
> >
> >
> >
> > < he not busy being born is busy dying >
> >
> >
> >
> >
> >
> 





< he not busy being born is busy dying >





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20160115/30b8ba99/attachment-0001.sig>