> Worst part for me is seeing sibling teams at my company fail miserably and live behind schedule and struggle a lot because they’re building full stack products/applications with it.
It's certainly possible to do it, but the time and resources it could take to do so will most likely differ. If it's an estimate/deadline driven culture, then it's likely that not having lots of historical data for how long certain things could take will result in mismatched expectations and bad planning.
Iteration and setting smaller goals could help, but it obviously will not always be the best solution for shipping things fast, especially if nobody has bothered to create useful packages or components in other projects beforehand that could be reused.
Though most technologies will have similar challenges, just in different aspects and to different degrees.
> And don’t even try to mention to them Laravel/Rails is easier because they’ll crucify you or call you a dinosaur or something.
Frameworks that focus on server side rendering and full stack development are pretty nice, though they can also be problematic in some regards sometimes.
For example, lots of folks out there who are running Mastodon instances or GitLab instances (Rails apps) run into issues with hardware requirements and scaling once they need to support larger userbases. Then again, the speed of iteration is hard to beat and for smaller projects (like my homepage, for example; but also most CRUD apps and such out there), either is probably okay.
However, I've also seen the other side of this in the Java ecosystem - an application that uses Spring and PrimeFaces, which has gotten harder to maintain and work with with each passing year. In part due to the frameworks themselves not really being the hot new thing anymore and not getting lots of attention, but also because scaling and keeping the performance good as the project grows is nigh impossible, though in part both because of how the project has evolved, as well as how all the components are integrated.
Similarly, if you have an API for your back end instead of doing server side rendering, you can easily create multiple front ends (in case you happen to use AngularJS and want to migrate to something more modern, or one of those other old libraries that went nowhere and were abandoned/deprecated), or even integrate with mobile apps and so on.
Though I have to say that even some of the full stack frameworks do some things nicely in that regard, since with Rails you can just append ".json" to your endpoint and get something pretty usable out of it! Plus, they lend themselves really nicely to codegen, at least for simpler cases (e.g. using Rails generators).
Overall I guess what I'm trying to say that solutions that will result in lots of coupling can be problematic. Tread carefully.
It's certainly possible to do it, but the time and resources it could take to do so will most likely differ. If it's an estimate/deadline driven culture, then it's likely that not having lots of historical data for how long certain things could take will result in mismatched expectations and bad planning.
Iteration and setting smaller goals could help, but it obviously will not always be the best solution for shipping things fast, especially if nobody has bothered to create useful packages or components in other projects beforehand that could be reused.
Though most technologies will have similar challenges, just in different aspects and to different degrees.
> And don’t even try to mention to them Laravel/Rails is easier because they’ll crucify you or call you a dinosaur or something.
Frameworks that focus on server side rendering and full stack development are pretty nice, though they can also be problematic in some regards sometimes.
For example, lots of folks out there who are running Mastodon instances or GitLab instances (Rails apps) run into issues with hardware requirements and scaling once they need to support larger userbases. Then again, the speed of iteration is hard to beat and for smaller projects (like my homepage, for example; but also most CRUD apps and such out there), either is probably okay.
However, I've also seen the other side of this in the Java ecosystem - an application that uses Spring and PrimeFaces, which has gotten harder to maintain and work with with each passing year. In part due to the frameworks themselves not really being the hot new thing anymore and not getting lots of attention, but also because scaling and keeping the performance good as the project grows is nigh impossible, though in part both because of how the project has evolved, as well as how all the components are integrated.
Similarly, if you have an API for your back end instead of doing server side rendering, you can easily create multiple front ends (in case you happen to use AngularJS and want to migrate to something more modern, or one of those other old libraries that went nowhere and were abandoned/deprecated), or even integrate with mobile apps and so on.
Though I have to say that even some of the full stack frameworks do some things nicely in that regard, since with Rails you can just append ".json" to your endpoint and get something pretty usable out of it! Plus, they lend themselves really nicely to codegen, at least for simpler cases (e.g. using Rails generators).
Overall I guess what I'm trying to say that solutions that will result in lots of coupling can be problematic. Tread carefully.