I’ll go against the grain here and say I like this initiative.
Symfony has an immense amount of talent behind it, as a product it’s a veritable treasure to the PHP community. That same talent putting effort into a frontend package bodes well for something amazing happening. Maybe not in the first iteration, but surely on the second or third.
Selfishly I also am keen on seeing this add competition to Laravel. I have been the biggest fanboy of Laravel for years, but 2020 was a weird year for Laravel and I’m no longer sure in what direction it’s heading.
I’m glad we share the same opinion on this initiative that being said I haven’t follow the Laravel community much this year. Would you care to elaborate on what’s going this year with it? Cheers.
But why, why just we can’t stick with backend only for api and separated front? Let’s just focus in symfony for api.
But why, why just we can’t stick with backend only for api and separated front? Let’s just focus in symfony for api.
That part already exists, works perfectly and I don’t see what else can be improved.
Adding some libs like swup, chartjs etc… is an actual progress. API? Too simple anyways.
The most common case against JS frameworks that take full control (react, angular) is that your forms become super-limited when it comes to dynamic field, collections etc.
So this really is a big step forward, after all, forms is the strongest component Symfony has.
PS:
Not talking about multi-page forms or those with few text fields. Imagine big ones with collections having their own collections, complex validation rules that can be only done on backend (i.e. not field related), dynamically created/removed fields/collections based on value of some other fields…
Agreed, it looks like this is trying to fix the problem that Javascript applications are mostly inscrutable to non-js developers. I don’t really think that’s something that Symfony is in a good place to solve, it’s much more important to make JS apps easier to read and write.
Why not? You don’t have to use it. It’s a separate package.
So… “Jetstream for Symfony” ?
To be honest I’d rather have an API oriented framework and let my colleagues who actually know how to do front-end (or mobile apps) build separate projects that consume the API, rather than have everything in the same project.
I could see the benefit for smaller one man projects though.
No thanks, full stack vendor lock-in is not something I want
I don’t like it. They build the wheel anew. For example, I’d rather to use webpack and configure it on my own instead of Symfony Encore. It gives much more options, bigger community and more already done+published code snippets.
Members
Online
