The future of Strapi - IMPORTANT

[pierreburgy]

The future of Strapi - IMPORTANT

As you have probably seen in this article: http://strapi.io/blog/the-future-of-strapi, Strapi is about to change a lot.

That’s why you need, more than ever, your point of view.

Please answer the following questions, by copy-pasting the block of text below:

**1. What do you think about this new vision?**
Answer:

**2. What Node.js framework would you use: Hapi vs Koa2?**
Answer:

**3. What downloadable plugins would you like first?**
Answer:

**4. What SaaS plugins would you like first?**
Answer:

**5. What front-end framework should we use for the extendable admin panel:** 
Answer:

**6. How can you contribute?**
Answer:

**7. Do you have any other suggestion?**
Answer:

In order to take the final decisions concerning the technical choices, we will probably create Twitter surveys in the next few weeks. In the meantime, we look forward to see what you have in mind.

[benjaminjs]

1. What do you think about this new vision?
Answer: Node needs something like this. Like this more than Nodal or Sails.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Hapi

3. What downloadable plugins would you like first?
Answer: Users & Group

4. What SaaS plugins would you like first?
Answer: Strapi Cloud

5. What front-end framework should we use for the extendable admin panel:
Answer: React/Flux/Relay/GraphGL?

6. How can you contribute?
Answer: Spectating, and complaints. Maybe some small features if well scoped.

7. Do you have any other suggestion?
Answer: Websocket support.

[suhaboncukcu]

1. What do you think about this new vision?
Answer: Seems like the logical move. I would like to have a proper guideline to migrate.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: No choice.

3. What downloadable plugins would you like first?
Answer: Users plugin which works with SocialLogin plugin and has ACL support within groups.

4. What SaaS plugins would you like first?
Answer: I would prefer integration with PaaS thingies instead of SaaS such as Firebase.

5. What front-end framework should we use for the extendable admin panel:
Answer: VUEJS !! :)

6. How can you contribute?
Answer: Bug reporting and bugfixes in several scales. Contribute with some plugins. I was thinking to create a basic forum with a script to contribute society.

7. Do you have any other suggestion?
Answer: Redirect every question and discussion to one channel and set up a tracker for that channel to comprehend necessities better in future. Even a Strapi forum would work just fine as I pointed at 6.

[eikaramba]

1. What do you think about this new vision?
Answer: Really depends on what the pricing will be. The problem is that the whole framework ecosystem is strongly build around open-source free-for-all projects, which means the actual willigness to pay will be quite low. So you will really have to stick out with a good developer-friendly framework and rich plugin marketplace, so that the costs are worth the saved time. Maybe consider a free-tier (along the free plugins), in which you can use them for free as long as you don't have too many users/traffic/api calls whatever.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2 because of the future-proofiness(tm)

3. What downloadable plugins would you like first?
Answer:Users & groups(along with authentication and authorization!), then API Manager

4. What SaaS plugins would you like first?
Answer:Stripe

5. What front-end framework should we use for the extendable admin panel:
Answer: Aurelia.js(would nicely fit in the ES6/use-only-standard-js/always-the-best future-proof vision of yours) or Vue.js

6. How can you contribute?
Answer: I have my own startup, so maybe by using it and paying for it :)

7. Do you have any other suggestion?
Answer: Keep up with the updates, recently i felt the project was slowing down. And with updates i don't necessarly mean commits but maybe just news, discussions etc. (i have to admit i'm not on slack)

[pierreburgy]

@benjaminjs, @suhaboncukcu and @eikaramba: thank you for your feedback.

1. @benjaminjs, yes, Node needs this mix between a framework and a CMS. @suhaboncukcu we will take about creating clear migration guides. Good idea @eikaramba.
2. We need more votes for the framework choice.
3. Users and groups looks to be the most wanted downloadable plugin.
4. @suhaboncukcu actually, the deployment it would be a PaaS, so you can write your own code and, then, deploy it. @eikaramba, what are your expectations concerning the Stripe plugin (admin panel integration, invoices management, users plugin connection...)?
5. React.js and Vue.js are the two in our short-list.
6. and 7. Thanks again.

[eikaramba]

@pierreburgy If i had to choose, it would be indeed admin panel integration. Also maybe an abstraction of the API to make it even more simpler(tbh it is quite easy already, but it's a long time since i used it manualy. Nowadays i'm using a complete shop solution so that i don't need to interact with stripe anymore). Sure enough the integration with the user db would be nice then.

[Aurelsicoko]

@eikaramba This our way of thinking too! The admin panel should be an abstraction layer of interfaces. It should allow you to easily manage and display your metrics in only one and unique interface. If you need to do some granular research or analysis, you could go on the dedicated interface offered by the third-party service. To achieve this goal, we have to fill our marketplace with a lot of plugins with basic features (ex: users & group, media library, upload) and third-party integrations (ex: Stripe, Mailchimp, AWS, Slack, and much more).

[sskyy]

1. What do you think about this new vision?
Answer: Seems great! Integrate Studio with admin panel will make Strapi much easier to use.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: definitely Koa2.

3. What downloadable plugins would you like first?
Answer: Users and Group along with RBAC.

4. What SaaS plugins would you like first?
Answer: cluster plugin.

5. What front-end framework should we use for the extendable admin panel:
Answer: React!

6. How can you contribute?
Answer: Help implement core features or plugins. I wrote a similar framework years ago.

7. Do you have any other suggestion?
Answer: Move fast! I've been waiting for a long time.

[abelsoares]

1. What do you think about this new vision?
Answer: Great. Monetization only in plugins keep the core open.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2

3. What downloadable plugins would you like first?
Answer: Users and Groups, Authentication.

4. What SaaS plugins would you like first?
Answer: Deployment.

5. What front-end framework should we use for the extendable admin panel:
Answer: React.

6. How can you contribute?
Answer: Plugins, core issues/bugs.

7. Do you have any other suggestion?
Answer: More incremental releases, keep shipping.

[yanickrochon]

First of, I am not an actual Strapi user, but I was looking at this project, wanted to know if you supported Koa2, then saw this. As a potential new user, here are my comments and expectations on the future of such project :

1. What do you think about this new vision?
Answer: It is not progressive at all. You are essentially trying to mimic what MeteorJs tried (except for the monetising part) with Atmosphere. Well, they are slowly abandoning it in favour of npm. And I agree with that 100%. The Node community does not need more package managers. However, you could "officially" list packages that were reviewed, and work with npm to integrate your PaaS with it (i.e. having the packages hosted on npm and keeping your own personal list of officially tested packages, with use comments and ratings). It should be possible to build something completely open source with Strapi; and I suggest you consider the same business model as WordPress for that reason. In fact, Strapi could very well be the equivalent in Node as WP is to PHP. If this is so, then I'd be on board 100%.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2. Because Koa is the only framework that wants to remain lean, and this is appeals to me very much. Koa2 is also future-proof and progressive.

3. What downloadable plugins would you like first?
Answer: Of course, users and groups.

4. What SaaS plugins would you like first?
Answer: Yes, clustering should be a must. Built-in would even be better.

5. What front-end framework should we use for the extendable admin panel:
Answer: React, of course.

6. How can you contribute?
Answer: anything... but no docs, I hate writing docs.

7. Do you have any other suggestion?
Answer: Put the thing in beta and encourage PRs. If you adhere to the philosophy of "less dependencies the better", it will prevent the core to become bloated and solid. Make it easier for people to see code coverage and build results. I originally found this project because I was looking for a framework built on top of koa... Well, if you are using koa2, then take a look at the build system they use, and how they keep up with new edge features in Node.js, etc. Also, make it Node 6+ and build around async / await (aka Promise).

Edit : PM2 already offers great metrics tools, why re-inventing the wheel? A proper integration would be better IMO.

[crunchtime-ali]

1. What do you think about this new vision?
Answer: I'm with @yanickrochon on the marketplace subject. While I have nothing against a marketplace PLEASE make it rely on NPM by enforcing some kind of naming scheme strapi-whatever or a tag.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2, it is as minimal as it gets in the Node world, easy to comprehend and extend.

3. What downloadable plugins would you like first?
Answer: I'm using Strapi v2 already in a big company project. Since there are no plugins yet I had to write a local-auth, redis session and swagger generator plugin myself (which was easy and straightforward)

4. What SaaS plugins would you like first?
Answer: None

5. What front-end framework should we use for the extendable admin panel:
Answer: Either React or Ember.js

6. How can you contribute?
Answer: I will fix the occasional bug, add to the documentation and release all plugins which may be useful to a wider audience (like the two above)

7. Do you have any other suggestion?
Answer: I'm already working with v2 despite there is no alpha version available. Please release an alpha with the current state to NPM, make it master and stop supporting v1 altogether! People getting to Strapi are probably confused because there is currently v1 and v2. You don't have to release v2 framework and studio at the same time. With the former released people can already start building plugins, generators and will contribute more to the framework core.

[abelsoares]

👍 for @dj-hedgehog comment, enforce the strapi-pluginName convention as it's very useful to find plugins! Also, release v2 as soon as possible, buggy sofware is better than no software, we need to get our hand on v2.

[junland]

1. What do you think about this new vision?
Answer: I like it. It's a good start :)

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Hapi

3. What downloadable plugins would you like first?
Answer: JWT Authentication or maybe a skeleton for making your own authentication.

4. What SaaS plugins would you like first?
Answer: None.

5. What front-end framework should we use for the extendable admin panel:
Answer: I honestly don't care which framework you choose, I just care if you can provide easy documentation to follow and it isn't a pain to look into the code and add new stuff to it.

6. How can you contribute?
Answer: PR (Reddit, Forums, etc.), Documentation, and community help

7. Do you have any other suggestion?
Answer: I love the idea of the studio, would be great to also create logic kinda like scratch does. Admittedly, I know this kinda sounds like Sailsjs Treeline (Which is a SaaS solution) or IFTTT but it is. I love the idea of just dragging and dropping logic without having to write much code. Also that would be great for people that are making REST API's that are not using a DB back end to talk to rather hardware such as GPIO, sensor, or even OS level communication.

[Aurelsicoko]

@junland: I love your last proposal! This really sounds like Treeline, Zappier or Flows (Stamplay). However, we also want to be able to offer chainable actions. Our ecosystem will be built around plugins and APIs, IMHO this kind of feature is a "must-have".

[sampology]

Hi guys, I looked into Strapi and looks promising. I'm sure you already decided about plugins to start with.

I would like to suggest MarkoJS (with Marko Widgets) for front-end. Have been using it for a while now and found it much easier and performant vs vue or react, especially on dynamic projects where you need to load templates on the fly. Have a read at least. You might want to have a look at LassoJS for bundling.

I would also go with Koa since it has a good community, extendable, works well with MarkoJS and ... generators :)

In any case, keep up the good work. I would become a subscriber if any SaaS provided will be reasonable priced.

Cheers!

[axe-me]

1. What do you think about this new vision?
Answer: I tried the v1 of strapi for a POC, great framework to use. but waited too long for v2 release, so didnt choose strapi for production use at end. So this time, dont let us wait too long..

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: koa2

3. What downloadable plugins would you like first?
Answer: user, auth, orm, cli, cache, MQ..

4. What SaaS plugins would you like first?
Answer: build

5. What front-end framework should we use for the extendable admin panel:
Answer: angular/2, react this is really doesn't matter

6. How can you contribute?
Answer: I would like to write some plugins and maybe help translate the doc to Chinese if you need i18n it.

7. Do you have any other suggestion?
Answer: release something.. update documents...hmm, some client side SDK will be nice to have (like those in loopback).

[Aurelsicoko]

@shanexie: We are so sorry for our lack of communication the few last months. We have been very busy. We are fully dedicated to Strapi from now. Our vision is well defined, and we know where we want to go! Strapi will not be a framework. Strapi will be a Content Management Framework. A great and easy tool to manage and synchronize your content (data, media) on multi-devices through an API. This new way of thinking does not change a lot of things for you, there will still have a framework, and an extensible administration panel. But we are thinking as an ecosystem where everything will be plugin.

I'm very surprised that nobody quoted Hapi as the framework to use. I really like the approach, it could be very interesting with our future plugins.

[pierreburgy]

Thanks to all of you for your answers. They help us a lot to make decisions. Here are some of our current thoughts for the future of Strapi:

• Node.js framework: Koa. Koa is flexible, lightweight and easy to understand. As soon as possible we will migrate to Koa 2 in order to avoid plugins breaking changes.
• The first plugins developed will be: Users (auth, groups and permissions), Content Manager, Content Type Builder and Settings Manager. For that, we are going to create a brand new admin panel using React.
• The first available SaaS plugin will be a one-click deploy solution based on a monthly recurring payment.
• We want to keep Strapi easy to learn, especially for front-end developers. Bookshelf is a really good option for SQL databases. However, SQL migrations require a good level from the developer. NoSQL databases have high flexibility what make them easier to learn. Also, Mongo is the world most used NoSQL database. That’s why we decided to choose Mongoose as default ORM. That will make developer life easier to develop both back-end applications and Strapi plugins. However, as a developer you will still have the ability to use any other ORM (including Bookshelf), but in this case you won’t be able to enjoy plugins usage through the marketplace given that they will be based on Mongoose.

If you have any question or suggestion concerning these choices, feel free to answer to this issue.

Looking forward to see your reactions.

[crunchtime-ali]

Awesome, I'm happy with the plan (just don't forget to release alpha ASAP). I'm against Mongoose as default ORM but as long as there's still a viable path to use SQL databases with Strapi's models I'm fine with that. Could you please extract the current Bookshelf ORM into its own repository as soon as it's pluggable into Strapi?

Also one more question: Will you release Strapi v2 with Koa v1 and switch to v2 as soon as all middlewares are compatible? I see some confusion arising on the user-side if you go with v1 first and then migrate to v2. On the other hand according to #41 there are still a lot of middlewares which aren't updated (we could migrate the missing 8 manually though as they're rather simple).

[pierreburgy]

We are going to release Strapi v2 alpha asap. Bookshelf ORM will be published on a separated repository.

Strapi v2 will be released with Koa V1: Koa v2 is no mature enough yet.

[junland]

@Aurelsicoko So is Strapi going to be Django in that's more like a CMS but yet can still be used for web applications outside of CMS? I'd also like to add I love the easy directory structure of Sails and I would like that Strapi keeps that paradigm. So with this new direction would it still be possible to use Strapi without the CMS aspect? Could have it where I think Sails or Featherjs has a command line that you can specify --dry then it scales out just back end stuff and leaves out front end resources and makes it super small.

[Aurelsicoko]

@junland: Strapi will never be a CMS. Our framework layer is very important. This layer gives the flexibility that every web project need. That's why, we think that the Content Management Framework is a better acronym for us. The directory structure will not change. However, we will add a new plugins folder at the root of your project. Some plugins will be added by default but there will not have some kind of required plugins.

The --dry command could be a good option to set up a Strapi project without the administration panel and without default plugins. Despite this, we don't want to be a framework. Our goal is to be an easy-to-setup and all-in-one solution to quickly build powerful APIs, and sometimes without writing any single line of code. The Node.js ecosystem and front-end developers need a solution which takes advantages of the CMS world (administration panel + plugins) and the frameworks (flexibility + plugins).

[junland]

@Aurelsicoko Alright, thanks for clarifying. Sounds good, I look forward to v2. :)

[mrexclamation]

1. What do you think about this new vision?
Answer: Great, I recently fell in love with v1 in a POC Project, you use nice concepts, can't wait for v2 to be released.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2, is Lightweight and extensible.

3. What downloadable plugins would you like first?
Answer: Users, Groups, Authentication.

4. What SaaS plugins would you like first?
Answer: None.

5. What front-end framework should we use for the extendable admin panel:
Answer: React.

6. How can you contribute?
Answer: Plugins, Core, issues/bugs I'll do my best.

7. Do you have any other suggestion?
Answer: Keep working, it's a nice framework, and please don't make us wait too long for the new version please.

[thesabbir]

we decided to choose Mongoose as default ORM.
🔩
However, as a developer you will still have the ability to use any other ORM (including Bookshelf), but in this case you won’t be able to enjoy plugins usage through the marketplace given that they will be based on Mongoose.

adios strapi! 👋

[cupofnestor]

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: No opinion, coming from Express. Based on community and github popularity, KOA seems like the obvious choice.

5. What front-end framework should we use for the extendable admin panel:
Answer: I'm into Angular, but doesn't matter much as long as it is flexible.

6. How can you contribute?
Answer: Bug reporting, offering suggestions for improvement geared towards media-centric project.

[pierreburgy]

Thank you @cupofnestor, as you can see in our blog (http://blog.strapi.io/inside-the-box-july-2016/ and http://blog.strapi.io/inside-the-box-september-2016/), we are finally going with React and Koa. Thanks for your contribution.

[paulocoghi]

Complementing what @ivan-saorin said, using Svelte (svelte/svelte) is the clear approach from now on to build front-end apps.

[Aurelsicoko]

@ivan-saorin Thanks for sharing your opinion! Did you suggest that the dashboard should be able to work with React and others? Currently, the main issue is that a React Component is not compatible with an Inferno Component for example. That's why I believe that the Web Component Standard will solve the problem. IMHO, we should be patient instead of trying to create a new kind of abstraction layer to be able to work with any framework...

@paulocoghi Thanks for the link! What are the main differences with UI library like React, Preact, Inferno?

[paulocoghi]

@Aurelsicoko There are many (like code splitting), but for me these 2 are the most interesting:

1. Every component becomes an independent vanilla JS module
With Svelte, you write your components in HTML, CSS and JavaScript, and they are compiled to vanilla js in build time. Then, in run-time there are no framework code or an additional .js file in the way, and your app loads extremely fast.

2. Interoperability
Svelte's components and/or widgets can be used in other projects, built with other technologies. In other words, widgets made for React only work in React projects, but Svelte's widgets work everywhere.

[ivan-saorin]

@Aurelsicoko IMO it is even worst. Not only choosing a specific framework impose that specific framework to the entire application. But, and this is in my opinion more important, major version of the same framework are often incompatible (e.g. Angular 1.x and Angular 2.x).
The real problem is that when the new framework (or new major version) will arrive sooner or later and your user base will ask for the new one. At that point your only chance will be to rewrite the entire admin panel from scratch. Not so funny.
On the other hand investing in an alternative solution (e.g. no framework for the container and iframes or... whatever) you could start writing new plugins with the new framework version immediately, and only update / upgrade the old plugins based on a policy you can decide and you can govern.

@paulocoghi the idea behind Svelte is promising. Sadly I didn't have the time to take a real look at it, yet.

[Aurelsicoko]

@paulocoghi @ivan-saorin Thanks for your answers! I'm sorry for the delay. We were very busy last two weeks. But anyway, I really like your attention and vision here. You're perfectly right! The main possible issue will be the compatibility and the migration to the next version of React in the future. However, the pursuit of performance has no end, and this is not an argument for switching to a framework to another one. React provides great performances until proof of the contrary. Svelte looks promising and what I like the most is the vanilla JS module compilation.

In our case, we have to consider two others things:

• Have an easy-to-setup and easy-to-use solution.
• Attract new contributors.

React is more attractive than Svelte. There are a lot of resources and tutorials and most of the frontend developers are using it. So, React is the winner and that's why we have chosen it.

From a developer perspective, I know this is not optimal but unfortunately, we have to make hard choices. We can't have the best design, the most performant framework and also continuing to move forward. The most obvious example is RethinkDB. If you didn't read this, you should. Currently, React is the best choice for us, IMHO. We can ship new features quickly, the community is active, it works well and that's sufficient for now.

[ivan-saorin]

I can see your points :) 2017-01-24 23:17 GMT+01:00 Aurélien GEORGET <notifications@github.com>:

…

@paulocoghi <https://github.com/paulocoghi> @ivan-saorin <https://github.com/ivan-saorin> Thanks for your answers! I'm sorry for the delay. We were very busy last two weeks. But anyway, I really like your attention and vision here. You're perfectly right! The main possible issue will be the compatibility and the migration to the next version of React in the future. However, the pursuit of performance has no end, and this is not an argument for switching to a framework to another one. React provides great performances until proof of the contrary. Svelte looks promising and what I like the most is the vanilla JS module compilation. In our case, we have to consider two others things: - Have an easy-to-setup and easy-to-use solution. - Attract new contributors. React is more attractive than Svelte. There are a lot of resources and tutorials and most of the frontend developers are using it. So, React is the winner and that's why we have chosen it. From a developer perspective, I know this is not optimal but unfortunately, we have to make hard choices. We can't have the best design, the most performant framework and also continuing to move forward. The most obvious example is RethinkDB. If you didn't read this <http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.html>, you should. Currently, React is the best choice for us, IMHO. We can ship new features quickly, the community is active, it works well and that's sufficient for now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABwwQQwOLfKIdsnBRG1Saddxy80QSFKcks5rVnhogaJpZM4ItoSO> .

[sbacem]

good idea @ivan-saorin

[zengxinle]

1. What do you think about this new vision?
Answer: a all- in- one solution. to get apis。

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2

3. What downloadable plugins would you like first?
Answer: user ---> organization -->positions , user --->role --->permission

4. What SaaS plugins would you like first?
Answer: one click to publish

5. What front-end framework should we use for the extendable admin panel:
Answer: crossui , react

6. How can you contribute?
Answer: money to buy addins

7. Do you have any other suggestion?
Answer: 1) hope to get new version 3 faster......
2) don't limit strapi V1.5 to node 4.8.0. then I can'nt try it in node 4.8.2 . it's ....

[camilodelvasto]

Sorry to come so late to this discussion. Hope my comments are still useful.

1. What do you think about this new vision?
I love that the studio is being merged. But I think that the real (economic) value would be in creating a marketplace that involves not only plugins for developers, but ready-to-use, plug-and-play themes, so that entry-level developers could embrace the ecosystem and bring paying customers for premium plugins or integration of services. Think of Envato market and their role in extending WordPress...

This could also be combined with a different SaaS model for simple use cases like basic CMSs, like what Contentful or GraphCMS do (websites still power most of the web), but with the added benefit that the software is still Open Source (so that there's no vendor lock-in involved) and that developers could still create applications on top of it. The studio is already great for lowering the entry barrier for non devs, so it still makes sense to have a SaaS model hosting both the studio and the backend for the less savvy users (those who would just consume the APIs).

4. What SaaS plugins would you like first?
Auth using social services
Image uploader with transformations (like cloudinary) for those using the admin as a CMS

5. What front-end framework should we use for the extendable admin panel:
React or Vue :)

6. How can you contribute?
I can create themes to consume the APIs, and eventually plugins.

7. Do you have any other suggestion?
Yes. It took me a long while to get here. I was looking for a node-based, sqlite-capable, open-source headless CMS with backend capabilities to provide content for my apps —yet I couldn't find any mention of Strapi on Hacker News, Quora or Product Hunt. I think the product is great and fills a need, and it deserves a lot more attention, so perhaps, more could be done in this area —I will help too :)

[yosbelms]

Since this issue is still open I will respond the questionnaire.

1. What do you think about this new vision?
Answer: Good to start.

2. What Node.js framework would you use: Hapi vs Koa2?
Answer: Koa2. It is fast, and stable enough for production.

3. What downloadable plugins would you like first?
Answer: Swagger API generator. Multitenancy. Cluster level stats.

4. What SaaS plugins would you like first?
Answer: Multitenancy. DB per tenant, and tenant per tenantID column.

5. What front-end framework should we use for the extendable admin panel:
Answer: React

6. How can you contribute?
Answer: Creating plugins, fixing bugs.

7. Do you have any other suggestion?
Answer: None

[chiqui3d]

5. What front-end framework should we use for the extendable admin panel:
   Answer: Vuejs

[soupette]

@chiqui3d the core members chose to go with React for the admin

[umarfarook882]

5. What front-end framework should we use for the extendable admin panel:
   Answer: I suggest Vue Js, its simple and getting better in front-end frame works.

@soupette is there any specific reason why the core members choose to go for React JS?

[emahuni]

Guys at least build a Vuejs front-end it's the in thing and simpler to work with

[derrickmehaffy]

@emahuni I think that ship has sailed.

[kitsunekyo]

the fact that strapi is using react for its admin panel is a huge bummer. not only is vuejs currently getting more traction than react, but its also easier to get into, faster to build interfaces with and promotes cleaner javascript in my opinion at least. (i've found react to be unnecessarily complicated for the simplest things like class binding, or conditionals, for no apparent reason)

would there be interest in offering a choice for the admin panel? maybe we (the community) could build a vuejs implementation of the admin interface and have it as a selection in the installer.

[derrickmehaffy]

@kitsunekyo I think at this point the choice is locked in, of course a fork can always be made to replace the react admin panel with vue.js. I'm sure the Strapi team had their reasons to use react instead.

Right now they are all quite busy with bug fixes and critical feature additions, I'm sure if someone wanted to start working on it, they might be able to look at it later.

For now the best choice would be to fork the project and see if it can be done.

[derrickmehaffy]

There is the common term "I never got fired for buying IBM" which states react is an industry standard, its far easier to find current examples and additions for react then vue right now. I'm sure that will change in the future but Strapi was started back in 2015 and the recent version (v3) I believe started back in 2016 (based on this thread)

Naturally the choice of language is always going to be subjective, if the strapi team were well versed in react it makes little sense for them to start working in Vue if they didn't know it right away in order to get a MVP up and ready. Unlike most of us the Strapi team do this as a job, thus their income is solely based on getting a product out the door. Most of us use and or provide our knowledge on our free time.

[emahuni]

what you are saying is very true guys, but I am not saying completely remove or replace the react implementation. What I am saying is provide an option. You see this project started a long time ago, but it's not yet done. Don't you think that the reason might be the unnecessary complexity of the tools being used?

For example, I used to work with php and smarty templates a lot, had many projects some that are being used by medical organisations at the moment. But developing simplest things such as websockets, speed improvements and changing of views and the like was a huge pain coz I was using very old tech which i was saying it's what I know and trying to learn something new to improve speed of production was a waste of time. But boy was i wrong.

I learnt about VueJS thru Laravel I quickly changed my mind since things i wanted to do were much more direct and simpler. I then noticed that I was bobbing back and forth between js (for vuejs) and php(for laravel) then decided to go all js. Then came in Node. Boy was I in for a surprise. Things got even simpler.

My point is that the speed at which i now develop has tremendously improved thanks to simpler well thought thru implementations such as vuejs. I have noticed the same with Strapi coz i want it for a backend. I was using feathersJs, but i think strapi is much simpler to reason about though the community around feathers is greater etc. There are a lot of things Strapi has that feathers cannot be, though the main punch is simplicity.

Strapi is more of a Vue's cousin. Take a look at feathersjs and compare it with Strapi. they more or less do nearly the same thing. however, Strapi is very very simple to work with, regardless of the admin end. it's actually cleaner than feathers which boasts simplicity. If an admin panel is built around vuejs, then vuejs community followers can flock to Strapi for this very reason I am putting across here.

What's happening here is a clean coded backend and a clean coded frontend. That's more powerful and faster to maintain and build rather than using React... it's tooooo complex to reason about and when you have bugs they are a huge headache and time consuming to solve, which is the situation the team might be finding itself in.

...and yes you can be fired for buying an "IBM" especially if it's counter-productive. If the one who is supposed to fire you doesn't, then they need to be fired.

instead of cursing the darkness, light the candle...

[kitsunekyo]

@derrickmehaffy nobody is questioning react as the choice of the core devs. react is insanely powerful but I feel like the binding to react while marketing strapi as "frontend agnostic" could hurt the volume of people actively participating in the strapi development / community in the long run.

my sole question was whether an OPTIONAL vuejs implementation of the admin backend would be something that could be considered to move into the core, once fully stable. not to replace react in any form.

strapi is marketed as "Front-end agnostic", (thats even a selling point on the landingpage) but whats the point of making the data consumption layer frontend agnostic but not the admin panel. thats where the biggest complexity lies for most of the people that will be implementing strapi on their production tools.

I would love to use strapi in our (Fortune 500) company and pay for a license, but will certainly not if all of my devs that will be working with it are mostly experienced in VueJS and have had no points of contact with ReactJs. Then I anway have to build the dashboard myself, and a lot of other teams will probably do the same.

[emahuni]

@kitsunekyo that is very true. I think we will also need an angular implementation as well with time. The biggest selling point here is framework agnostic, which can actually mean a lot to see many implementations of the frontend.

Anyway, that's what communities are for. Someone has to do it.

[Aurelsicoko]

Very interesting discussion... but I think most of you are missing that we're building an ecosystem. It means that our goal is to provide hundreds of plugins to the community. Each plugin has its own front-end. Do you imagine that every plugin's developer should develop the back-end and three different implementations of the front-end (React, Vue, Angular) part (admin)?

The community could help but it means that the ecosystem won't be equal if you're using React, Vue or Angular. It would also drastically reduce the growth of the ecosystem. I really like the idea but it seems almost impossible to implement or it implies that the full ecosystem will be available with React and the implementation would be partial for the others front-end frameworks Vue & Angular.

[Aurelsicoko]

Also, I read that some of you think we started the project is 2016. It's true but we are really working on it since July 2017 (~11 months). React isn't the reason why it takes so much time to build Strapi. We're facing many challenges which aren't all related to the development part.

This year, we structured the company, we improved our workflow to manage the community and release new features, and we were also very busy at something that will be revealed soon!

PS: We're hiring, feel free to take a look at our open positions

[emahuni]

Oh my, then that puts a hard limit on on the agnosticity of Strapi. I think i need to go thru the whole code base. My thinking was the plugins implement an api like system with a frontend made for each frontend framework. If that is the case, what i just said then implementing multiple front ends will just be a cinche. I am actually thinking of using vuetify or Quasar as the components lib for something like this. If you notice, it's very very simple to get an admin panel running. Please just have a look at these things, it's so simple. I am sure you will see that twitter bootstrap is very complex 😂 to work with than ready vue components such as Quasar or Vuetify.

[derrickmehaffy]

@emahuni Don't get me wrong I too would love to see a Vue admin panel, but the Strapi team picked react for a reason.

Also the ibm thing is a joke lmfao. We have a similar one in the networking field, you say "Cisco" in a meeting about buying equipment and no one will say no (even though I can't stand Cisco gear).

My point is here, if you think it can be done better, please do! There is nothing saying it can't be built and shown to the Strapi team! This is why open source is such a great concept, everyone can voice their opinions and show off changes. But what I don't like to see is dragging down the Strapi guys for picking one language or another, all programming is subjective. There are a million ways to do something and the Strapi guys work extremely hard, especially lately.

They have a ton of stuff going on other than just putting code out, thus I can see why they wouldn't want to fracture their focus on completely rebuilding what they have spent the ~ past year on.

Let's see what a Vue admin panel can do!

[kgrosvenor]

I would suggest Vue JS for the front end too, due to its superior DX and extend-ability, react is great but it keeps reinventing itself because it can't fit all use cases, it has a simple to use API which would make extending the Strapi admin much easier! Just my opinion :)

[kgrosvenor]

Oh my, then that puts a hard limit on on the agnosticity of Strapi. I think i need to go thru the whole code base. My thinking was the plugins implement an api like system with a frontend made for each frontend framework. If that is the case, what i just said then implementing multiple front ends will just be a cinche. I am actually thinking of using vuetify or Quasar as the components lib for something like this. If you notice, it's very very simple to get an admin panel running. Please just have a look at these things, it's so simple. I am sure you will see that twitter bootstrap is very complex 😂 to work with than ready vue components such as Quasar or Vuetify.

Totally agree about bootstrap being complicated, however I've always liked the grid system and spacing classes, they are so good, however creating an abstraction through components is always a bonus !