JS Framework

I am getting quite unimpressed with all the JS boilerplate and spaghetti code we have to write to achieve simple AJAXification. I don't think a JS framework is something realistic with everything tied to Elgg's view system, so I am thinking more and more about using Elgg as a data provider and creating UI on an AngularJS or ReactJS stack.

Here are some issues I have bumped into while playing with this:

  • Elgg's routing system is cumbersome and is not suitable for data consumption. Page handlers are hard to work with, difficult to tap into with a plugin, and at large are redundant. We need a more granular routing system that ties into views or uses closures/callbacks. I am thinking something along the lines of Slim Framework (http://www.slimframework.com/)
  • Web services are draining life out of me. Our page handlers should be capable of serving raw data without us having to write extra code. Consumers should be able to hit any URL with an API key and consume data. All these method exposures are extra work that noone has time for.
  • Better JSON support. Our view system doesn't work well with JSON. The JSON output we produce doesn't always validate.

I am not sure Elgg needs (or is capable of embracing) a JS framework of its own in the near-term future. Given the variety of frameworks out there, I would much rather have an option to choose and switch whenever I want, who knows what's the next big thing after React. If we can turn Elgg into a better data store, I think we will start seeing more stand-alone bootstraps for various JS frameworks.

I have tried hard to envision Elgg as an Angular or React app, but it seems it will be easier to write a native JS app that uses a NoSQL database and all the latest JS tech than try to make the view system work with a JS framework younger than Backbone.

Anyhow, just sharing thoughts. I am getting tired of writing HTML in PHP, and going out of my way trying to achieve simple data-binding with jQuery.

  • It would be nice to popular an entity list via JSON.

  • Very interesting thoughts, I was wondering why the web_services are not maintained while it would be good to have this as an always available route to data. It needs to become more robust then with API key management, rate limiting, exposing services to the outside from admin panel, etc..

    I also thought the page handler of elgg is somewhat complex but thought that this was my issue.

    A good webservices API and JS framework for the frontend, combined with HTML5 might be the best way forward and attract new developers. It also would make it possible to have a better split in front end developers and backend. Currently frontend and backend are very much tied into the plugin structure and php API

    Me personally have to upgrade my js  (angular an jquery) skills, but I am definitely willing to do that.

  • Agree with the sentiment, here. I'd be delighted to work with you on the next iteration of routing for elgg. Hopefully something that would make it trivial to expose web services and not cumbersome.

    One thing I don't see anyone doing that could set us apart is focusing on controllers as a model for http resources. So they have methods that map directly to http methods. This would hopefully keep the learning curve low. The methods could just return anything json serializable and you'd have a json api by default without any extra effort. Any other rendering to HTML or RSS or whatever would be another layer on top of that.

    I'd also like to avoid writing our own dispatching code. That seems like the meatiest part. Slim could be fine, but I'm partial to the {curly} syntax of FastRoute and Laravel.

    I also think named routes are a requirement but they're something of an afterthought with laravel. FastRoute had a very compelling and thorough analysis of why their approach was fastest, so that's my current favorite right now. Speed is not something Elgg is known for. It couldn't hurt to focus on it a bit more...

    One thing I also liked about laravel is the method injection. So services get injected straight into the controller methods, rather than having to pipe them through the constructor. This cuts out a lot of boilerplate. And we could inject read-only services into get/head/options but writable services into put/post/delete. The performance benefits here are again nice for automatic caching guarantees, etc.

    Once these pieces are in place we can really build a standard set of APIs for Elgg. Wdyt?

  • You are the boss :) Whatever we can do to make life easier for all.

  • I'm cool with moving to any routing system that adds features (but I would miss the capabilities of the route hook if it had to go). I suspect routing is seldom the performance bottleneck unless your app isn't doing much at all.

  • Well you may think of me as the boss because I assert my opinions strongly but I have no more authority than anyone else here. And I hardly have any time to implement any of these ideas myself. So really what I'm asking is: have I convinced you enough for you to go and implement this for the rest of us?

    :)

    Some examples of what's in my head to make things more concrete:

    class HelloResource {
      public function get() {
        return ['hello' => "World!"];
      }
    }

    // start.php
    elgg_register_route('hello', [
      'url' => '/hello',
      'controller' => HelloResource::class,
    ]);

    // Example response to GET /hello
    Status: 200 OK

    {
      "hello": "World!"
    }

    // Example response to POST /hello
    Status: 405 Method Not Allowed

    {}

    Now lets try with input params:

    class HelloResource {
      public function get($name) {
        return ['hello' => $name];
      }
    }

    // start.php
    elgg_register_route('hello', [
      'url' => '/hello/{name}',
      'controller' => HelloResource::class,
    ]);

    // Example response to GET /hello/John
    Status: 200 OK

    {
      "hello": "John"
    }

    // Example response to GET /hello
    Status: 404 Not Found

     

  • @evan i have done something similar for a new project i'm working on, it's quite simple, just tried to make something like Laravel's controllers. Check it out: https://github.com/enkeli/elgg-routes 

    it's not a final plugin, certainly it does need some work and testing. But i'd be glad on spend some time working on making something simimlar to the core.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.