Modularizing web applications

Question

I was wondering how big companies tend to modularize components on their page. Facebook is a good example:

There\'s a team working on Search that has it

Answer 1

This isn't something that should happen on the fly, it's baked in the company structure. No telling how Facebook or any other specific site/company does it, but it can be as simple as maintaining a single database table. Like:

project_namespace

• id
• namespace
• directory

So, you've got your core application (1, 'core', '/htdocs/core'). There's probably a PM or senior in charge of it, and some monkeys to create & maintain it - an extra database table if HR isn't already managing that relation, but that's irrelevant here. Each namespace would require a common structure, ./css for CSS files, ./templates for HTML templates, ./js, ./images, and so on. Again, there can be a db table for that, but irrelevant to this example. Add any number of other teams - search (2, 'search', '/htdocs/search'), accounts (3, 'users', '/htdocs/users'), the web services guys (4, 'services', '/htdocs/services/') and so on. Each value is unique, and I'm just making this up so please ignore the lack of detail.

Now you've got your build process - a script or series of scripts that pulls everything from source control, runs the CSS and JS minifiers, and generally compiles all the disparate parts into a website. It loads the namespaces from the db table and prepends them (or just the unique IDs) to every relevant CSS rule, HTML element ID, Javascript class, or whatever is needed. The "core" namespace would probably have some special rules, allowing other namespaces to call on it, sort of a meta-API (again not so relevant to the example, but realistic).

That's the gist of it at least, but it doesn't necessarily involve anything I just mentioned. For some teams that could just be an email reminder of "FTP your changes here, but jerk you best not overwrite my stuff," and for others it's a 3-ring binder of rules implemented with a rigid assembly line, wired to any number of bug trackers and code review tools, of automata performing unit tests and processing makefiles and checking permissions and so on and so forth. I'd guess Facebook leans more to the latter.

Long story short: information organization and a build process to maintain it.

So yes, everyone can (and should) be aware of what others are naming their div tags & JS functions and everything else important, thanks to this ominous MCP-looking entity maintaining the rules and handing out the names. With the right process and tools, you'll never not know.

Answer 2

A namespace clashes problem can be avoided by using a naming convention. Additional reading:

• CSS Practice: Pseudo-Namespaces in Complex Projects
• CSS Namespaces Support - Functional and Design Specification

In short: It depends how your system is built, but assuming that everything is composed out of modules, then name your CSS identifiers (or JS IDs etc.) as follows: SiteName-ModuleName-Function.

If you're willing to use your application language (e.g. PHP) to intervene with the CSS/JS code, then an "arbitrary" naming may be used, by assigning each module it's dynamically-generated numeric id and attaching that id to the identifier of the client-side language object. For instance:

# PHP script
class module_articles {
    public function __construct() {
        $this->GUI = new view;
    }
    public function display_articles() {
        // The CSS file is rendered first by the PHP engine and
        // the identifiers name is constructed with the $this->GUI->id property.
        $this->GUI->load_css('path/to/file.css');
    }
}

class view {
    private static $instance_number = 0;
    public $id;

    public function __construct() {
        $this->id = ++ self :: $instance_number;
    }
    public function load_css($path) {
        // $id can also be the CSS file path (slashes replaced with underscore)
        // or the module name itself (e.g. module_articles)
        $id = $this->id;
        include $path;
    }
}

Eventually, the CSS file should be something like this:

/* CSS of module_articles */

<?php echo $id ?>author_name { /*...*/ }
<?php echo $id ?>article_date { /*...*/ }

Note: The file should be included via PHP's include keyword! Use Output Buffering to output it later.

Answer 3

UI conventions should be documented when multiple teams are developing UIs.

Preferably you should have the same team write/design the UI for all components, then break up the other layers as needed.

Answer 4

Web development definitely brings some organizational challenge. HTML/CSS is not exactly the dream environment for splitting work. It is very important to define certain rules and strictly follow them.

My personal tactic I have come to is to prefix the names in shared sources (like CSS or markup components) with some module suffix. If you keep to the strategy, it will uniquify the names globally.

For example:

instead of

div.question_title
div.question_body

you could use

div.so_question_title
div.so_question_body

div.su_question_title
div.su_question_body

Also agree with teams on some shared data like colors of the color scheme. Define them somewhere globally and reuse them everywhere.

Another issue arrives when teams are working on different parts of the same page. Here if you're developing a page component, you may find one day something is broken because the guys working on the page itself changed something and changes propagated down the element hierarchy.

For example, if you define a CSS style in this manner:

div.main_news *
{
    /* ... */
}

it would be asking for trouble. I suggest that you have at as a rule to define CSS styles with the minimum possible scope which is sufficient for some technique to work.

One possible workaround: each submodule firstly resets all the styles for its top-level hierarchy element, like:

div.news_container
{
    /* Reset styles */
}

so that you can now work on the module resting assured the changes in some parent elements would be stopped at your perimeter.

UPDATE: Regarding divs with UIDs. If you mean Facebook, I'm not sure what UIDs you are referring to. Only hidden inputs have some long cryptic IDs as their values (main page, not logged in), but this is likely the result of the framework automatically generating these values for some reason. I once wrote some code (for ASP.NET MVC) for Html helpers to generate unique IDs application-wide (I wanted to bind checkboxes with labels by IDs completely automatically and transparently for me). Another case could be that a stateful event-driven framework (such as ASP.NET WebForms) has unique IDs generated server side as a requirement to support its operation. Each control has to have some unique ID so that it is possible to know on the server side which element raised an event on a page. Also some WYSIWYG editors would add auto IDs to elements when you drag them and drop to a form.

This all aside, it is of course possible to have some pre-build script to go over the code and inject unique IDs into markup and CSS code portions. But you really need to know exactly what and why you are doing this. I'm personally of the opinion this "uniquization" in general can be achieved manually by enforcing some simple rules in a team, while some work can of course be automatized, like what I described above.