Re:Vue.js and Brunch: Webpack Alternative
by jdavis703 on Monday August 21, 2017 @05:31PM
(#15068023)
Boy I don't mess the days of dealing with SQL queries inside of PHP "view" files. Reminiscing aside, you can build server-side applications in both Vue and React.
Re:Vue.js and Brunch: Webpack Alternative
by bigmanwalter on Tuesday August 22, 2017 @12:28AM
(#15069703)
I'm not advocating for SQL in views. MVC and ORM are great. As is free auth and form generation from database models. I haven't seen a framework that gives me everything that Django or Laravel does for free.
You are _completely_ missing the point of frontend applications, here's a few to get you started:
- Ease of creating complex user flows.
- Decentralization of application work: app runs on client, less CPU cycles for my server!
- Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.
Re:Vue.js and Brunch: Webpack Alternative
by bigmanwalter on Tuesday August 22, 2017 @12:33AM
(#15069731)
You can build complex user flows with JavaScript on top of server rendered views. Ajax works great with server side rendering, see Pjax https://github.com/defunkt/jquery-pjax or Intercooler http://intercoolerjs.org/
The server is rendering JSON anyway, more or less just as expensive to serve HTML. Besides, the bottleneck is usually database access.
It's a false separation and forces you to expose far more than necessary. It's nice to have my full database available on every page render without needing to define explicit endpoints.
I also like having forms generated from database models.
Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born.
And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes.
Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.