tl at rat.io
Fri Jan 8 14:28:48 UTC 2016
- 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.
> On 07.01.2016, at 14:56, tl <tl at rat.io> wrote:
> Okay, answering my own post ;-)
> server side based on Node, Express, React, MongoDB
> visualizations with D3
> 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:
> * 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.
> 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  (developed and backed by Facebook) is by far the most prominent of the frameworks to support isomorphic rendering . 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 . There is a problem though - React tries to control the DOM just like D3, the visualization engine - but there exist solutions to that .
> Another, maybe less involved solution for isomorphic rendering is called Rendr . It’s less well known and less supported though, so my first shot would be React.
> 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…
>  http://blog.yld.io/2015/06/10/getting-started-with-react-and-node-js/
>  https://github.com/reactjs/express-react-views
>  http://oli.me.uk/2015/09/09/d3-within-react-the-right-way/
>  https://github.com/rendrjs/rendr
>> On 06.01.2016, at 22:30, tl <tl at rat.io> wrote:
>> Following are some notes from the discussion.
>> Possible outcomes:
>> security mode.
>> sense, users will have to switch to medium-high security to watch those.
>> making them as usable and as useful as possible, rather than worrying
>> about users having to change their Tor Browser security setting.
>> - 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
>> - It's sufficient to host static content, which can be mirrored much
>> more easily than dynamic content.
>> - 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
>> - Look into alternatives to Bootstrap, like Bourbon.io.
>> So far, so unclear. Input welcome!
>> metrics-team mailing list
>> metrics-team at lists.torproject.org
> < he not busy being born is busy dying >
> metrics-team mailing list
> metrics-team at lists.torproject.org
< he not busy being born is busy dying >
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the metrics-team