Page MenuHomeDevCentral

How are we building our webstack?
Open, HighPublic


Determine the languages and frameworks of the Web application stack.

Event Timeline

dereckson created this task.EditedMar 30 2015, 14:22
dereckson raised the priority of this task from to High.
dereckson updated the task description. (Show Details)
dereckson added a project: Tasacora.
dereckson added subscribers: dereckson, Ash-Crow.

As the user UI will rely on JS, and the application code will be done in Python, we have two evident choices to build our service for the main server:

  • Django - a more conservative choice
  • Node - a full JavaScript stack, with external calls to our Python software

We could also rely on a PHP back-end, but I'm not as comfortable for this choice as for the other ones, as it would require newcomers to the project to deal with three languages instead of two.

If we don't rely on a PHP back-end, let's go for Django. For easy JS manipulation of .svg files, we should try and see if raphael.js suits our needs.

List of (front-end) JS frameworks to consider

Python drawback

Several handy tools like GulpJS are mainly optimized for full JS webstack. So, using a Django server, we'll lose a little bit of comfort configuring these tools.

dereckson moved this task from Backlog to Working on on the Tasacora board.Apr 8 2015, 10:28

About the browser stack, two questions (more or less related)

  • Does a framework bring a lot comparing to vanilla javascript for the use ?
  • Which browser we intend to support. A good target would be in my opinion Grade A support by mediawiki
dereckson added a comment.EditedNov 30 2015, 08:16

Note: I'm only going to speak about the front-end, as the fact we code the back-end in Node.js or in Python doesn't matter a lot to this question.

Frameworks like ReactJS offers to build all the front-end as one application, without duplicating all the HTML/JS code.

That means you don't write anymore in 3 languages (Python for the controller part, HTML for the views, JS for the code to run on client) but only one: JS. So DOM elements are not put in HTML, but instancied by JS.

In React, a web application is a set of components, with properties (immutable constants) and state (mutable variables). Like in GUI programming a component could be a widget (e.g. a textarea) or a set of other widgets. You write a method how to render the widget from a given state and app code only changes state, rendering will be called implicitly.

They offer great introspection, and we actually can debug it in browser console (my browsers tend to have debuggers components for React and Ember for example). If you manipulate the DOM with Plain JS or jQuery, you only have the initial or final DOM browser representation to inspect, not the natural objects you manipulate.

You can scroll for an example of what it brings.

Finally, they play nice with unit testing: See for example

As a rich JS application, targets browsers would then be the same kind able to run Visual Editor, anything recent, but not IE6, IE7 or links (IE8 is supported by React by the way). That makes sense, especially as we have a CLI application to offer, nina, to those liking to work on the console.

dereckson moved this task from Working on to Next on the Tasacora board.Jan 6 2017, 06:53
dereckson moved this task from Next to Backlog on the Tasacora board.Jan 27 2017, 23:36