After reading and listening what fusion is, I thought I was lossing my mind.
I'm glad the author said he took it way too far, and that it is a way to introduce javascript developers to back-end code.
But that last statement got me thinking, why do javascript developers need to have backend code in their front-end code to learn back-end development?
The initial idea of splitting back-end and front-end code is that people or teams can work independently to reduce the time to complete an application.
In the interview the author said someone who knew Vue wanted to know what they should do to make the component work with the backend. And that what sparked the beginning of the package.
I think this is a failure in communication, because in a back-end/front-end configuration the first thing you do is decide which are the API endpoints and what the data is they can receive or send. You can decide that in the beginning of a project, or when features are going to be developed.
When thinking a bit more, what instead of adding back-end code to a UI library learn the Vue person blade, twig or any other backend templating solution. This way it gives a person a way to build the html on the server.
It has benefits; the pages will be more performant, SEO compliant and you don't need an extra build step with a javascript bundler.
Learning a back-end templating solution syntax is also not that big of a step away from the javascript UI libraries as it is very similar.
Also state management becomes obsolete, because the way pages work in the back-end is to create them from scratch each time. There is no need to replace parts of the page or worry about too many repaints.
This gives you as a front-end developer more time to create the javascript code you need to make the site as interactive as you want it to be.
If the Vue person still wants more control, then we go in full stack territory and that requires more learning because creating a UI and creating secure and robust backend are different skills. The plumper is not the best person to lay a roof and vice versa.
When hearing those statements I also got the feeling that javascript developers can't or won't use anything else than javascript. I think that is a wrong assumption. Typescript is an example of that. Because of that language javascript developers are going to feel at home in static typed back-end languages if they want to learn them. This will open up a whole new world of job opportunities.
Am I thinking too much, or too back-end centric?
Top comments (1)
My experience with a realword application is different. When a program is BE heavy then I rare saw a javascript/TS on BE business side. Just on SSR (as you mentioned) but that part I don't count as heavy BE instead just a other part of FE.
I faced python BE on scientic app, and java, .NET on insirrance app.