Closed jersiovic closed 7 years ago
I think that Orchard actually uses Angular in the admin. But I would say that it is mainly used for databinding than for achieving a SPA. Just like what has been done in Layouts. I believe that from what I've read React has a smaller footprint but also does less than Angular. It is not as complete as Angular and it adresses mainly using a virtual DOM "not shadow DOM" to be able to increase performances. React is a library vs Angular is a framework. React could be certainly used to increase performance in places needed but I'm not quite sure we should move from Angular since it has proven that it is mature.
If we plan to migrate to Angular 2 when it comes out then we should evaluate what are the alternatives out there. There is also http://aurelia.io/ that seems to be interesting... it has a cleaner markup than Angular. But right now I say, let's wait for Angular 2 and Aurelia to be out and mature before making a decision.
P.S. Aurelia router miss features
You can still mix React + Angular in any projects you'd like to fine tune performances.
While my own personal aesthetic preference goes to React | Redux, I think first you'd have to establish that SPA is what the dashboard should be. The same goes for isomorphic. I'm utterly unconvinced, personally.
I think that some features in Orchard admin views could be using better the concept of real time data view. Though per feature seems more convenient than totally SPA. From experience, having form posts is always good.
Per feature is my opinion too. We'll see when we do the first module that needs it ... media (currently KO), layouts (Currently angular), ...
Thank you for the feedback ... very sensible indeed
I think the way you are building Orchard 2 right now seems to be fine. If someone wants to run Orchard 2 as a SPA they should create it as one or more module(s).
If you want to make it easier for a developer to create a SPA module you could:
Personally I have earlier preferred knockout over angular and it can run nicely as SPA when creating your own router or extending with Durandal. But now I think there are 3 great libs for creating SPA out there:
FYI: Aurelia working with Razor (I created a skeleton available for download)
@gordon-matt do you plan making a Github repo with that code ?
@Skrypt , yes I do. I will be writing up an article / blog post of some kind and link to the example project that I will place on GitHub
I like Rolf's suggestion about APIs https://github.com/OrchardCMS/Orchard2/issues/149#issuecomment-224863313
I have read about Vue.js and like it, like I like knockout.js, very simple as I got the idea in less than 5 minutes, like KO without the wrapper around the properties.
To @Skrypt and whoever else is interested, the aforementioned repository is here: aurelia-razor-skeleton. I will be updating that at some point to show how you can dynamically add routes to Aurelia. I already achieved this with Durandal in my own app, which has a plugin architecture.
Thanks @gordon-matt will show this to some people that will be really interested on this.
+1 for Aurelia. It's so simple to work with and has a team focused purely on it. It helps that it's not maintained by one of the big tech corporates, as it can avoid the politics that can sometimes bring.
Apologies becuase I haven't looked deeply into how the new architecture works or where its going but I personally think it would great to see Orchard 2 designed in the way that WordPress has gone lately. In that you can use it as a headless API server and put your own JS frameworks on top.
If you are talking about the admin interface then yeah there is a case for choosing one and sticking with it. But I don't see why you would want to include a framework in any other part of it since that is up to the theme to do isn't it?
Also if it were just an API server with an view layer on top then it would mean that if some one wanted they could make what ever flavor they want of the admin in a fork.
@justsayno That's one of our goals, right. We'll still provide a front end UI, but it could be totally disabled for security reason and you could use the API only. Each module is supposed to provide dedicated APIs. We also have some work going on with OAuth2 so we can protect the APIs.
Great that sounds good. Then I think the framework that the main UI is built in is kind of irrelevant bar not choosing one that is either dead or not very widely used.
By the way I am really excited watching that vid about Orchard vNext and where this is going. I am a new Orchard user in general and almost tempted to just try to start with this version for my blog and get involved in helping build it too.
Is there any news about the work in this direction?
Because the admin is not built for a specific SPA framework, we'll keep it this way. I personally used Vue.js for the Media. Right now there is no reason to prevent another module from using anything else. And there is no required framework for any part of the admin (like navigation or routing).
Time ago I read some discussion about that in Twitter, but technologies evolve very quickly. So, I miss a central point where I can see opinions of Orchard community related to advances in SPA and how interesting you see Orchard to adopt one ore other technology. I want to learn in deep one SPA technology and the one you choose for Orchard 2 is important for me to decide. I imagine that also for others.
After Microsoft announced #UWP support for React Native https://t.co/5D8PRK1Ni9 https://t.co/bH05Bvv64G" and after reading about isomorphic feature https://blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/ I have another time more sympathy for React as the SPA technology for Orchard 2 @orchardcms
it looks to me that React has added 2 pros to its account to be adopted by Orchard 2: It will make more easy to develop multiplatform native apps with Orchard, using Orchard as a library instead of using it as a web app. And related to isomorphic feature we could move many code from our razor views to javascript/typescript because same code will run in client or server depending on our need.
What do you think? Has any concluding opinion related to the SPA technology topic the committee? Or is it still an open topic?