Closed SteveSandersonMS closed 6 years ago
Totally get that you need to place limited effort where the crowd is going. Aurelia has decent templates they provide themselves. Vue seems to be getting more popular, what's criteria would it have to meet before it can be given first class support.
I'd also like to know what the criteria is for choosing which frameworks are "officially" supported.
Vue has definitely risen in interest in the last couple of years (as seen with this google trends comparison and I think should still be considered.
Blue-Vue, Red-React (Angular is too popular and including it makes the graph hard to compare)
Just to be sure: this is limited to the templates and not the underlying JavaScriptServices and/or SpaServices (prerendering)?
This is a more fair comparison of ReactJS (Note that there is no dot) and Vue.js. React is one third more popular than Vue at the moment.
Just to be sure: this is limited to the templates and not the underlying JavaScriptServices and/or SpaServices (prerendering)?
You are correct. The underlying JavaScriptServices/SpaServices packages (including prerendering helpers) are a fully supported, shipping part of ASP.NET Core. We have no plans to stop working on them. They are required for our Angular/React support, which as mentioned in the announcement, is something we're continuing to invest in. It's only the Aurelia/Knockout/Vue templates we're no longer developing and asking for interested community members to take over.
@RehanSaeed Interestingly the graph changes again if you compare both without dots (vuejs vs reactjs) and you can clearly see that vue has become a force in the javascript world.
It seems to me the only officially supported frameworks are the ones backed by large companies. I guess it's understandable but sad.
@RehanSaeed If you compare the names with a dot in both, or without a dot in both, Vue wins. You can't compare one with a dot and the other without it, that's misleading.
https://trends.google.com/trends/explore?date=today%205-y&q=vuejs,reactjs,vue.js,react.js
oranges and apples https://trends.google.com/trends/explore?date=today%205-y&q=vuejs,reactjs,electron (-:
Slightly surprised at the dropping of official support for Vue, with the industry adoption rapidly increasing.
But, It's not a huge loss.
The Visual Studio and Visual Studio Code teams have made strong efforts to support Vue; the latest release of Code offers syntax highlighting, support for single file components, snippets, debugging recipes posted by a Program Manager of the Code team. Visual Studio offers similar support thanks to Mads Christensen.
Personally I would recommend people look to Nuxt for SSR, PWA, and static site generation, and maybe use WebAPÌ or go 'serverless'. The Microsoft developer tooling for those combinations is very good; it`s a more flexible approach combining the best of current technologies without munging them together, and solves the core problems that most people wanted to address with Vue and NodeServices / JavaScriptServices.
P.S I always take Google trends with a pinch of salt. The only thing it highlights is the importance of naming your product to be something that is not easily confused with other common words (or the reverse, if you want to appear 'popular')
I really liked the Aurelia version. I installed it and it just worked. It's so easy to use. I hope someone will take on the support for Aurelia.
This decision does make sense. Vue and Aurelia were already way ahead in terms of their CLI implementations. Vue has Nuxt and a whole host of integrations with more suitable Node implementations. Express, Hapi, Koa, Feathers with websocket support templates already exist for Vue/ Nuxt. It will always move faster.
This project is Angular first, React second. Its target is to keep .Net being used by slow moving large companies and stop them looking at other technologies that is all.
For React, is the official decision to only support create-react-app and not redux or server side rendering in React?
Will The new react CRA template be released at the same time as 2.1 (Hunter's roadmap said summer time frame if I'm not mistaken)
Want to confirm that the old React templates will not be supported or maintained in any way by Microsoft.
CRA doesn't have SSR so the new template(s) won't have it either. Same for TypeScript support.
This is disappointing. The Aurelia templates were great, seriously why?
Its unfortunate decision to not support Aurelia. As its seems many of Microsoft people are involved with Aurelia one way or other. Aurelia seems to be deliberately pulled down for God knows reason, where as its hands down one of cleanest Javascript development framework.
I don't think this means ms doesn't want you to use Aurelia, just that maintaining multiple templates is hard..
These days you could be working on the latest fancy js framework that could be completely outdated the next week with lots of breaking changes having happened. Personally, I think there is much more value in someone maintaining sample projects like this one than having minimal "dotnet new" templates that require just as much work upgrading to the next major version of the underlying framework a month into a project.
I for one welcome the new community focused Vue
templates...
Anyone taking up the mantle?
We would love for someone in the community take the unsupported projects and continue them (or start from scratch, or whatever). If someone does choose to go down this route, we'll gladly link to it prominently from the readme of this repo
We are simply not staffed to manage this number of templates. It might not be common knowledge, but the entire ASP.NET Core team is 22 engineers, 2 engineering managers, and a handful of program managers. We do all the design, development, and testing of all of Microsoft.AspNetCore.* (including the new Blazor project!), and a whole lot more (such as previous versions of MVC, Web API, WebHooks, etc.). If we spread ourselves thin by juggling too many projects, both quantity and quality of features will inevitably suffer, and I don't think anyone wants that.
@Eilon I definitely understand from my side, even though I was initially disappointed. I've been playing with the whole template stuff since this announcement and it's great - but working with the whole spa setups can be quite fiddly and takes time and effort. Better the community handle this and you guys focus on the good stuff like Blazor 😉 and keep supporting the Javascript services so we can still get that nice webpack hot-loading action...
As for vue (cc @ctolkien) there is a nice starter template at https://github.com/MarkPieszak/aspnetcore-Vue-starter which currently needs to be cloned/manually downloaded, but I'm sure a dotnet new template will be available soon
If anyone's interested, the vue starter template from https://github.com/MarkPieszak/aspnetcore-Vue-starter has now been converted to a proper dotnet new tempate with a nuget package at https://www.nuget.org/packages/aspnetcore-vuejs/
We make significant use of the Aurelia templates. I don't understand why support for it is being dropped, @eisenbergeffect What's your take on it?
@stefan505 nothing that we've done is going away; we simply don't have enough staff to continue working on it and maintaining it.
@Eilon I understand the reasoning. I've noticed that the Aurelia CLI has grown significantly since I last looked at it and it does offer a very similar ASP.NET Core + Webpack project template.
I'm not too impressed that CRA is being standardised on as it loses the whole typescript integration, which is of immense value, but also a complete pain to setup. Similar for SSR.
If there is limited value-add over CRA, why even bother with asp net, may as well just go full node?
@DanHarman
That is basically my approach. Keep the UI with Node (i.e. Nuxt.js, Next.js) for SSR, code splitting, preloading, static site generation, and creating a PWA / offline. That gives you access to the request response pipeline in Node for i18n etc (you can't get that with Node Services - I asked).
Then call Web API for data, which acts as the gateway to use of .Net Core for important business logic, architectures such as CQRS etc.
Use the right tools for the right job.
Blazer is an interesting prospect for the future.
@mcquiggd You may be right. I’m going to check out next js tonight as perhaps thats the answer. One of those things I’ve been aware of, but not tried.
The good thing about dotnet new reactredux is that its about the one place you could find an example configured to get everything running on aspnetcore, but perhaps thats the wrong question anyway. At least with next js they have config for typescript, ant design, all the stuff that was a near vertical learning curve!
@AWulkan @mika76 just to be super fair. react isn't just searched for by reactjs or react.js. In fact, it's searched for enough using just react that google has created a category specifically for the react javascript library in general to track all searches related to it. Vue isn't popular enough (yet?) for them do that.
Not to throw any fuel on the fire of "which frameworks" are popular.. but based on GitHub stars:
With that said, Angular seems to have a strong following with .NET developers... not quite sure why tbh.
Hi, me and colleague would like to maintain the vue asp.net core template, we made a decision at work a couple of weeks ago to go with asp.net core and vue for all new web development. We're new, but if someone can bother to hold our hand at the start I'm sure everything will work out :)
@ctolkien Speaking of fuel for the fire, and what is popular with who...
I'll mark this closed because there's no active work item here, but please feel free to continue discussion!
FWIW, I couldn't be more disappointed in the aspnet team for deciding not to offer an official Vue template. Vue is proving itself amongst enterprise devs, and deserves a fully-supported template. Please reconsider.
if react and angular communities are so great why they don't work on this. I understand that libraries, tools, and frameworks are like this, some will die sooner than others, but sometimes I ate Microsoft in the way that they just start something and then just leave it to die because it's not a trend anymore. Good luck with Blazor but it seems to be other/next abandoned promise.
@nmocruz
You seem confused with what this is about? These are just templates. None of the libraries, tools, or frameworks are "dying". There's nothing stopping you making a project that uses the JavaScriptServices libraries with whatever client-side frameworks you want.
The frameworks in the dropped templates are still supported, they still work, it's just you have to make the project yourself, rather than having a template that does the basics for you.
And it doesn't seem to be to do with trends. Vue for example is only on the rise, not the downfall. What it does seem to be is that "there's only enough time in the day to do X things, and there's > than X things to do" so they have to focus on the "biggest wins". That sucks, but it's how the world works a lot of the time.
FWIW, I found the React templates useful when I started out, but now I've gotten comfortable with it all I rip out most of whats in the template and customize it to my own (and the company I work for) needs.
The templates are handy to get going, but it's Microsoft.AspNetCore.SpaServices and Microsoft.AspNetCore.NodeServices which are of the real value. Writing those would be much more of a pain than coming up with a template that makes use of them.
Usually there are always blog post and samples around which are non-MS that describe the latest "this is a good way to do it now". Since every new release of [insert SPA framework here] comes with new patterns and best practices, it is a constant effort to update templates and provide guidance for migration.
Templates that MS ships with VS are covered by a support policy so including a framework template in-box is likely a big effort for MS (since there need to be people knowing about Vue and the details of the Vue templates when you contact MS Support. And they might even have to monitor the JS lib versions in the template for security issues.)
A bit of a communication issue here might be that "supported" means "you can call MS support under your support contract" and "not supported" does not necessarily mean "it won't work and we don't plan on making it work if it doesn't"
@AndyCJ I'm not confused when I mention software life cycle I didn't mention killing features of support for stuff, so maybe I have confused you with that. I know that we can still work with older templates and as you said is just a template, we can even use it without a template and other libraries. My point was more about MS keep support for angular and react that have the biggest communities and drop for others who maybe could need some help because are not popular or have fewer resources to build these templates. I understand that the support angular and react will reach a bigger number of developers/consumers but In the last years a saw people picking frameworks/libraries more because others have also picked the same, so people are increasing the rating not by the quality but just they are choosing others choices even when there are too many weirds things in these options. What is sad is seeing MS being nice and be inclusive at some point, and then just quit like they are despising something that are not good anymore.
My understanding from @SteveSanderson is the the comment here about Microsoft support policies is incorrect. Could someone from Microsoft clarify whether or not the SPA templates fall under any Microsoft support?
Templates that MS ships with VS are covered by a support policy so including a framework template in-box is likely a big effort for MS
@pkellner
Is this what you're looking for?
The Microsoft.AspNetCore.SpaTemplates package never shipped in the .NET Core SDK, and never reached an official level of support. The ASP.NET team's development resources are finite, and we think we can deliver more valuable features to ASP.NET developers by focusing elsewhere.
So:
The Microsoft.DotNet.Web.Spa.ProjectTemplates package, containing Angular, React, and React+Redux templates, is not affected. This ships in the .NET Core SDK and is officially supported. We continue to invest development effort in this package. We can put more time and effort into these SPA templates now the effort isn't so spread out.
...
(Taken from the aspnet issue linked to in the first post in this thread)
Thanks @AndyCJ Just to be 100% clear, the retiring React templates (react and react-redux) that are being replaced with the create-react-app templates will be supported through the normal Microsoft policy which if I remember correctly is 10 years?. I'm only asking again because that is at odds with what @SteveSanderson who I believe maintains these templates told me at MVP Summit recently.
@pkellner
I'm sorry, I only know as much as what I've linked to. I hope you can find the detail you're looking for.
I read the linked text to say that:
The Angular, React, and React+Redux templates are already in the Microsoft.DotNet.Web.Spa.ProjectTemplates package, and the Microsoft.DotNet.Web.Spa.ProjectTemplates package is already shipped as a part of the .NET Core SDK.
Because they're already being shipped they are already officially supported, but "officially supported" isn't defined.
I haven't read anything which talks about replacing the current React/React-Redux with the create-react-app templates.
This thread is about the VueJS, Knockout, and Ember templates, no longer being updated. They currently live in Microsoft.AspNetCore.SpaTemplates, which has never been a part of the .NET Core SDK, and so has never been officially supported. (Again, it's not defined what "officially supported" means).
It sounds like you might be asking a separate question about upcoming changes to the React/React+Redux templates, and what the definition of "officially supported" is. So maybe that would be better as it's own new issue, rather than being attached to this one?
Hopefully I'm understanding you correctly, and apologies if I'm not.
@mcquiggd
That is basically my approach. Keep the UI with Node (i.e. Nuxt.js, Next.js) for SSR, code splitting, preloading, static site generation, and creating a PWA / offline. That gives you access to the request response pipeline in Node for i18n etc (you can't get that with Node Services - I asked).
So I just created an app on Next.js and have just encountered the horror of trying to deploy a node app on windows so that it can reliably run on server restart etc. Its a complete mess with projects that look semi dead like iisnode or dodgy service wrappers. It feels like Microsoft are trying to drive us all to linux?
Meanwhile trying to use the new react template and add typescript is a whole different horror show. There is so much unnecessary friction here.
I'm sure its all easier for MS now, but it sucks for their developers.
@DanHarman
Is this a VM, Azure App Service or something else...?
With Node and .Net Core apps I've used Linux, and Azure App Service without problems . Also sometimes Azure Functions for Nuxt. And sometimes Service Fabric for .Net Core. It's all pretty flexible...
For Node (and clustering) on Windows, try https://www.npmjs.com/package/pm2
On Azure App Service, select Linux as the underlying OS, and then under Runtime Stack select your Node version - it currently goes up to Node v 9.40. This will then use PM2 to control your App Service.
This might help:
https://docs.microsoft.com/en-us/azure/app-service/containers/quickstart-nodejs
https://github.com/aspnet/Announcements/issues/289