Sylius: [Quesion] Javascript Framework choice

[arnolanglade]

We could start to speak about the javascript framework choice. What do you think about http://knockoutjs.com/ and the pattern MVVM?

[stloyd]

Personally I would go (if any) with AngularJS.

[arnolanglade]

@stloyd : Google is evil, ahahah... I don't know angular, what do you like in angular? I discovered knockout few days ago. I have not lot of argument for it. I think it is simple, it can work easly with Symfony without rewrite some part of it in javascript...

[pjedrzejewski]

I will check out knockout but I was generally thinking about angular too.

[molchanoviv]

+1 AngularJS

[winzou]

Why don't we simply use jquery? It's widely used with lots of plugin/whatever already based on it. Plus it's hosted on many cdn and in many clients cache.

[stloyd]

@aRn0D Yea, all evil in the world is fault of Google =) About AngularJS, I would say is simple, well designed and tested (yeah Google =)), it easily integrates with Symfony (similarly like Backbone, but it's not so advanced).

I would recommend to checkout this blog post: http://sporto.github.io/blog/2013/04/12/comparison-angular-backbone-can-ember/

[molchanoviv]

The craziest idea! Lets use Dart and Dart-UI. :)

[arnolanglade]

@winzou : it is a low level framework, it is difficult to organize your code and extends plugins...
@stloyd : I will checkout your link asap !
@pjedrzejewski : what do you want for sylius, a simple page app or not ?

[jjanvier]

@winzou because

• it's impossible to do something well integrated with Symfony by using only jQuery
• it's always better to have a full stack JS framework rather than a lot of ugly jQuery plugins

Knockout ? Angular ? I have no opinion. Check this : http://www.slideshare.net/basarat1/mvvm-knockout-vs-angular

Whatever you choose, please take into consideration something that :

• will let the templates driven by Symfony
• will be to easily integrated with Symfony

[marcospassos]

I've experience integrating Angular with Symfony applications. The big challange is how to take advantage of the great Symfony features in the javascript world. Without this, we'll have a lot of polyglot duplicated code, that makes the maintenance terrible. For example, can you imagine now days you creating form templates manually? How to serve it to Angular statically? How to integrate the server side validation with the client side validation? How to do this without coupling serverside with clientside?

We achieved this creating a template exporter and a validation adapter for Angular. Basically, we have a XML where we describe all templates and partials. We can disable an input, remove the CSRF protection, add CSS classes, etc without add hard coded customizations in our serverside. Through a command, we generate all templates that will be served statically to clientside. We have a option --language (and --all-languages) that is used to specify the language used during exportation, generating a pack of templates for each language which increasing the performance considerably. Our form templates is smart enough to convert Symfony's validation in Angular validation and assign the required attributes, like ng-model. Thus, our backend was completely decoupled of our frontend and our performance is great.

<?xml version="1.0" ?>

<views>
    <resources>
        <view id="acme_product" src="AcmeWebBundle:Backend:Product/index.html.twig"></view>
        <form id="acme_type_product" name="option" type="acme.type.product">
            <option key="[csrf_protection]" type="boolean">false</option>
            <option key="[override][name][@attr][ng-model]">option.name</option>
            <option key="[override][presentation][@attr][ng-model]">option.presentation</option>
            <option key="[override][type][@attr][ng-model]">option.type</option>
            <option key="[override][type][@attr][ng-disabled]">option.id</option>
        </form>
    </resources>

    <outputs>   
        <output resource="acme_product">
        backoffice/product/index.html
        </output>
        <output resource="acme_type_product" theme="AcmeWebBundle:Backend:Product/theme.html.twig" template="AcmeWebBundle:Template:form.html.twig">
        backoffice/product/type/product.html
        </output>
    </outputs>
</views>

Running:

php app/console angular:template:dump --all-languages path/to/my/angular/template/repository

...will result in some directories like:

project/partials/en_US/backoffice/product/index.html
project/partials/en_US/backoffice/product/type/product.html
project/partials/pt_BR/backoffice/product/index.html
project/partials/pt_BR/backoffice/product/type/product.html

If we decide change our framework or give up of use a client side approach, we can just change our XML file or remove and all are done.

I had plans to launch a bundle for this, but the lack of time did not allow.

[arnolanglade]

I have no experience Angular but it seems difficult a little bit to only use symfony form...

[marcospassos]

The problem is not only related to forms. Using a clientside approach your backend is reduced to an API. Lose Symfony templates, form generation, validation and internationalization tools beyond all communications with the system (like configurations and DIC) is not simple as you think. So, it's not just about "Symfony form".

[arnolanglade]

Yes i agree with you, I think Angular does not seem the better solution... IMO we just have to animate the DOM... not more or we write sylius and you make a one page application....

[marcospassos]

I think Angular is a good option, in fact the best currently. We'll have this problem with any javascript full stack framework. Full stack javascript frameworks are made to do almost all job, except persistence. As said, the problem is that we lose all powerful Symfony's tools.

[arnolanglade]

I am not agree with you, if we loose all powerful Symfony's tools angular is not good/better solution... I prefer keep all Symfony's tools and find an other Framework, maybe not full stack framework...

[jjanvier]

I agree with @aRn0D. The best would be not to reinvent the wheel and use the minimum of JS possible. Just use it for DOM animation.

But it clearly depends of what you expect Sylius to be : full Ajax / one page app or not ? _Before choosing a JS solution_, we have to know _what we exactly want to do_, no ?

[arnolanglade]

Before choosing a JS solution, we have to know what we exactly want to do, no ? Yes I think it is the first step...

[molchanoviv]

+1

[winzou]

I personnaly don't want Sylius to be a one page application. Symfony ftw.

[albanR]

What we exactly want to do yes, but also who is the targeted audience. Something optimal but too complex could be detrimental to Sylius.

[molchanoviv]

IMHO we should let end users decide what do they wants. For this i think we should provide them good back-end part and leave them front-end part.

As for me. I don't like a one page applications.

[marcospassos]

+1 for Sylius does not be a one page application. It's a final user decision and adopt it in the sandbox is just add a lot of unnecessary complications and work.

[stloyd]

While I agree that frontend should not be one-page application, I would tend to agree that backend would be nice place for such approach, see i.e. the ServerGrove control panel (AngularJS + Symfony2), in such place it's even better to have a'la one-page application.

Just my 2 cents =)

[jrobeson]

i agree with @stloyd : let's separate admin concerns from storefront

[nimajneb-torram]

+1 to separate admin from the front as @stloyd and @molchanoviv said.
All clients will want his own front and it's their decision.

[Eponymi]

Storefront and admin are certainly separate concerns; but I think it's backwards to focus on backend with JS. Backend is about functionality, front-end is about UX. It seems that moving towards a one-page app on the backend is counterintuitive in terms of JS effort.

Not that the front-end should be a one-page app either; single-page apps area fledgling programming endeavor, and there are currently a lot of sites with serious traffic that have laughable initial load times. The JS framework functionality should be conceived in a way that blends the best of both tools (serve up "initial" html with symfony, edit the results with JS).

Also, AngularJS.

[jjanvier]

I think everyone agree that we are talking only about the backend. I _do_ understand that a "one page app" for the backend would have a "wahou" effect for our customers (I mean people that will pay us ^^) and that it would be a very interesting technical challenge. The exemple provided by @stloyd is really impressive and seductive, that's true.

But I totaly agree with @Eponymi opinion, and moreover I would remind you guys that Sylius is an _Ecommerce for Symfony2 − developer-friendly._ We chose Sylius for several projects in my company because it was written in Symfony and easy to customize (even the backend). Please don't forget that and if you go with a one page app, please do something that is _well_ integrated with Symfony and that has the _smallest_ JS footprint possible.

[jrobeson]

as long as the apis are designed correctly there shouldn't be a problem in making it do what you want.

[arnolanglade]

I totally agree with @jjanvier! When I started the topic I only spoke about backend... the front end must be simple because each Sylius integrator/developer with redesign it for their customer... If we make a one page application, developers will have to know perfectly Angular and Symfony instead Symfony it can 'afraid' some developers who you to use/contribute to Sylius. IMHO, Sylius user want a ergonomic and stable backend and he wants that quickly but it not possible to make it quickly with a fullstack framework (i.e. the comment posted by @marcospassos about form).

[kayue]

+1 on AngularJS and agree with @jjanvier's view. AngularJS does allow us to write less JS and rely more on HTML representation.

Some AJAX control in the backend is fine, however I won't want one-page-app in the backend as it is hard to modify and easy to break.

[amenophis]

I like the "one page" concept for the backend ! AngularJS is a really good framework for this purpose.

I don't know what is, and how knockout works, so I can't have an opinion on this framework.
Concerning AngularJS, I used it a little with a symfony2 REST API, and it works well !

To use it, we need to implement a Full REST API for all Sylius functionnalites.

Maybe i can help on this integration !

[arnolanglade]

@amenophis : knockout was just an idea... I don't know if it is the best solution to Sylius yet...
@kayue : :+1:

Some AJAX control in the backend is fine, however I won't want one-page-app in the backend as it is hard to modify and easy to break.

[docteurklein]

I personnally dislike this topic about chosing a js framework for this.
It should be totally independant from the server side.
And as said above, I also think we should just focus on a REST api and let clients (softwares) do what they want.

If i'd go to write a one-page client, I'd go with ember. And I definitively would place it as a separate project.

[kayue]

In the backend there might be a need for JS framework.

If we can make sure the page works without Javascript, would that be better?

So the JS framework will be optional (but loaded by default).

On Fri, Jul 19, 2013 at 5:02 PM, Florian Klein [email protected]:

I personnally dislike this topic about chosing a js framework for this.
It should be totally independant from the server side.
And as said above, I also think we should just focus on a REST api and let
clients (softwares) do what they want.

If i'd go to write a one-page client, I'd go with ember. And I
definitively would place it as a separate project.

—
Reply to this email directly or view it on GitHubhttps://github.com/Sylius/Sylius/issues/228#issuecomment-21238995
.

[doertedev]

I'd really like to see Foundation based Frontends, which, by design, is based on zepto/jquery. Using Foundation would rock the shit out of mobile layouts, without any efforts.

[amenophis]

To be sure, this choice concern only the full Sylius distributable version (like prestashop) ??
For each standalone bundles, we must not impose anything to the developpers !

Right ?

[jjanvier]

@amenophis yes, right

[arnolanglade]

@docteurklein : "you would place it as a separate project" you want to create a separate bundle to manage one page app, an onther webBundle?

[docteurklein]

another repository: "ember-sylius-backend-client".

[docteurklein]

That communicates via a REST api.

[arnolanglade]

@docteurklein : I like your approach, I can keep webBundle too but work on 2 client interfaces can be painful.

[pjedrzejewski]

@docteurklein Indeed, I think it's more about selecting the default framework. Used by us, like @amenophis said. Our controllers are already FOSRestBundle based, what we need is good serialization configs for all models.

[dizda]

+1 for AngularJS + FOSRestBundle

[rikless]

+1 for AngularJS. Every thing has already been said.

[Baachi]

I like the idea from @docteurklein. But i would also vote for coffescript.

[arnolanglade]

I think @docteurklein has right, the discussion about the client side should be independant from the server side. If we decide to create a one page app for the backend we should create an other bundle. We should create API or improve the ResourceBundle because It already extends the FOSRestBundle (if it is needed...). Lot of people wants to use Angular, I check it and it seems not so bad even if google is evil (I am jocking @stloyd). What the sylius core wants to do for the backend? Ask to the community or decide what is the best to Sylius? Thanks all for each answers.

[ghost]

+1 for AngularJS

[jjanvier]

In case it could useful to somebody, here is a tool to help choosing a JS framework : https://github.com/tastejs/todomvc

[kayue]

I used AngularJS in one of my Sylius admin page to replace Symfony's form "prototype" and I think it went ok, the Twig does look cleaner than before, and event binding no longer binding to element's class or ID.

However, to render a form with filled data in AngularJS, I have to transform form data into JSON / Model first and then pass it to AngularJS.

[raul782]

+1 AngularJS. I've been using AngularJS for my last projects, and the integration with symfony2 is really good, AngularJS has ngResource and it's really easy to talk to a Backend Api.

[mosch]

+1 FOSRestBundle

[aramalipoor]

+1 for StorefrontBundle in its traditional twig form.
And
+1 for AngularJS + RESTful API for Backend.

I've integrated Angular with a Symfony2 project lately and I found that there are a lot of ideas for abstraction that can ease the process of developing Sylius Backend as well as publishing a Bundle or two in the wild so they can be used in all Angular+Symfony integration projects.

E.g. FormType to Schema.json converter bundle which creates a Json definition of a Symfony FormType. It can work together with something like this.

IMO we can wire a lot of Symfony's power (Validation, Intl, Form, ACL, etc.) to Angular world. Not only useful for Sylius Backend but also other applications. Of course it's a lot of work. But I think it would be awesome.

[kayue]

@aramalipoor Schema.json sounds like an interesting solution.

My concern is it won't incorporate with form theme in Symfony.

[mosch]

I would choose React and a RESTful API. Active community, lot's of reusable components and really fast and fun.

[koemeet]

I am building an API around Sylius and currently use Ember for the client side, this is by far the best pick for such a big application as Sylius is. You should take a look at this, it is already very mature! Using Ember Data in conjuction with Ember is very powerful.

[kayue]

@mosch React isn't template driven, which isn't very a very good fit for Sylius IMO.

I think ideally Sylius's JS framework should allow developer to build awesome UI without modifying a lot of HTML (view), just focus on JS and PHP.

Therefor I think AngularJS is the closest one because it is template / attribute driven. (Web Components is even better if no browser drawback..)

[mosch]

@kayue you're right. react isn't template driven - but component driven. and it perfectly fits your requirements since stylius could provide a lot of configurable and reusable ready-to-use components.
The developer can either just use the ready to use components and just pass attributes to them to configure them, or they use some child components for maximum flexibility.

[RuslanZavacky]

Hey guys, I am trying to follow how you develop Sylius, and I would like to give you some hints on choosing the right framework for the Backen UI. Consider reading Investigation that was done by Ghost team about choosing a framework for their admin, they've already spent a lot of time and a lot of people from Angular world vs Ember world where involved in the discussions.

Main thread
https://github.com/TryGhost/Ghost/issues/2144

Angular.js Invetigation
https://github.com/TryGhost/Ghost/issues/2201

React Investigation
https://github.com/TryGhost/Ghost/issues/2203

Ember.js Investigation
https://github.com/TryGhost/Ghost/issues/2200

To sum up, they've decided to go with Ember.js. The speed, on how Ember is evolving is magnificent. The HTMLBars + Fastboot will land into Ember in 2015 and will make this framework really good for backend as Admin UI and also for Frontend as it will be available to render whole ember app in the backend.

[kayue]

Thanks @RuslanZavacky , good reference. Would you recommend Ember if we are not doing a single page app?

BTW, It is also worth a look to OroCrm's front-end architecture, since they are also built with Symfony.

[RuslanZavacky]

@kayue My suggestion might be the following:

• Separate repository to hold front-end of admin
• API of admin exists in the Sylius
• Admin frontend as sub-module added to Sylius.

Separation of concerns and separate people can work on it. And for that you have to go with API First Design and this approach will help other people/companies who want to manipulate admin of their e-commerce stores from their internal systems.

And when you work with Frontend as "real" front-end, which is not tied to back-end, you will develop it differently, and can use more tools to speed up development.

About your question "Would you recommend Ember if we are not doing a single page app?" Currently, there is no good solution, to create normal web page app that will be crawlable by Search Engines. Prerender.io can be used (and I am actually using it now to generate HTML representation of ember.js app, so I am kinda using it for not single-page app). But this approach with prerender.io brings different problems, you have to prepare Sitemap and HTML for pages before Google visits your page and then serve it statically, because each render with prerender.io takes a lot of time, sometimes till 7 seconds. Ember's FastBoot solution will solve this problem, but will be released in this year and I am really waiting for it.

[kayue]

@RuslanZavacky Thanks for introducing Ember's FastBoot, and yes this is the solution I want to use. I guess it probably won't be ready to use until the end of the year.

I was checking Ember's components, one thing I don't like about it is it requires handlebars. I think AngularJS's attribute approach is better in this aspect.

PS: Sylius probably won't be using any JS framework for store front, so SEO isn't one of the concern.

[RuslanZavacky]

@kayue very soon handlebars will be vanished from the Ember :) HTMLBars are almost there. There is and performance fiddle to compare some of the implementations: http://jsfiddle.net/Ut2X6/

Problem in Angular from my perspective is approach, that it starts from the HTML, and you have to place Angular on top of HTML.

Ember starts from the side of architecture and separation of concerns. So you have Routes/Controllers/Components that translates into HTML.

Angular plays in to different direction. One more thing is that Angular will release 2nd version, and its very different from the first one. So if you decide to start with Angular, you have to go with 2nd version. As Admin interface is not that you will rewrite often, then its better to choose something, that have more solid support & migration plan.

[dbalabka]

Thank you @RuslanZavacky for great constructive comments and advice. Unfortunately I do not have any experience with Ember, but I have have few comments about Angular.

So if you decide to start with Angular, you have to go with 2nd version

I'm not pretty agree with this, because:
The second version of Angular will not be release in near future. According to last Angular team planning meeting there are at least 3 versions of Angular 1 should be released. The current state of Angular versions:
1.2.x - the latest stable version
1.3.x - not yet stable
1.4.x - planning(http://www.infoq.com/news/2014/12/angularjs-14)
1.5.x - according to plan this version should be release in future.
Important thing is that Angular 2.0 will support only modern browsers for example IE10/11, because:

Yes, there are still older browsers in use, but we’re targeting these newer models as they will be the primary ones in use by the time AngularJS 2 is ready and you good developers have had time to build apps on it.
http://angularjs.blogspot.com/2014/03/angular-20.html

As you can see first version still maintaining and should be maintained few years, so migration to Angular 2.0 can be planned after Sylius 1.0.0 release.

[aramalipoor]

We've been using AngularJS about a year for our admin panel, we've faced a few _blocking_ issues which practically stopped us from moving faster. Now we're considering changing our tech-stack to a more robust and easier approach. Intuitive for customers and easy for developers with lowest technical debt as possible.

If I could find some free time I would be happy to talk about the details, but these articles from Shopify team describes the issues very clearly. I can say I'm 90% agreed with things they're saying about Admin panel!

• Rebuilding the Shopify Admin: Improving Developer Productivity by Deleting 28,000 lines of JavaScript
• Y-Combinator topic
• History of Admin of Shopify
• Summary of Their Findings

Some libraries that can come of use:

• Twine minimalistic two-way binding system by Shopify
• Symfony TurbolinksBundle port of the rails turbolinks gem

[kayue]

@aramalipoor Thanks for sharing. I am actually just started to build a backend with Angular 2!

[aramalipoor]

@kayue This is good as an experiment, but IMO not for production! be careful of the forms/APIs/uploads/build processes/tests/TESTS/TEEESTS!! :D Protractor compared to Behat/Selenium is like comparing a bicycle to a submarine when you're working under the ocean! We couldn't access Symfony's container (e.g. for required fixtures), we couldn't smoothly talk to storefront, etc.

Server knows best!! Which translates to dozens of API calls if your from Angular-context and just a few variable access if your from Twig-context!

ui-grid is not ready for intuitive API integration, specially with Symfony, for example when Sylius have merged their GridBundle a Symfony/Twig-based admin panel is going to get all the benefits of that bundle but anyone using API is going to do another extra layer for the integration, specially for an MVC framework like AngularJS.

Maybe using Angular (2?) or React.JS only for rich-client parts seems like a better idea than having a full-stack SPA using a framework!

I have to make it clear all of these are in the context of Symfony! For other frameworks/languages these can be untrue!

Anyway, wish you great success @kayue

[pjedrzejewski]

@kayue @aramalipoor Just as a side note, my grid implementation #3944 is format agnostic too, so you can get data in json/xml with all sorting/filtering functionality. That being said, rendering will be added in separate PR and will be done via Twig. But I can imagine having the rendering part in frontend and just consuming it via API calls. Grid fields configuration is in yml, so could be processed by this frontend framework, I guess.

[aramalipoor]

@pjedrzejewski Nice! This is a great news! Yes it could but the thing is it's better to keep main logic on the server since reading/manipulating/extending of those configuration is easier there. Imagine ImportExport bundle which trys to add a MassAction into every grid. Or a bundle trying to add a column based on some logic. Just like what OroPlatform is doing with their grids.

Moving this logic to the client-side will prevent flexibility and ease of development. IMO any application logic should stay on server and only components and widgets should be rendered on client. So even if you want to load grid data from an API lets not get the JSON and ask server to render that part in Twig (I know what you're thinking now :D I wouldn't say this a few months ago!!), and replace the table content!

Anyway IMO keeping a single technology (Symfony) and use a very simple binding in JS seems like a good approach.

[pjedrzejewski]

Well for Sylius grids will be rendered via Symfony&Twig of course, but also accessible via API. I don't think we have time to implement anything frontend-side. We will have a look at this for 2.0 possibly, when Sylius API is more mature.

[aramalipoor]

Yeah, implementing a client-side solution specially for a complex thing like grid is more of a hassle than problem-solver. Wise choice :)

[pjedrzejewski]

I think we can close this, because we are sticking with jQuery + SemanticUI for 1.0 and will rely on Symfony for rendering. Of course you will be able to build your own shop/admin UI on top of API.

We will definitely consider providing decoupled UI on top of some framework for future versions.