Organiser of the Edinburgh Language Exchange and The Edinburgh Open Tech Scene |
Full Snack Developer 🥪, Ramen guzzler 🍜, quiche murderer 🥧. A friendly cat.
I used to maintain my own hobby website back un the early 2000's before jQuery time. I wrote a "matrix screen flow" and a drag-and-drop lib for a summer job, puzzling out the differences in position calc between browsers. Hell at the time, but simple enough. Then did zero web dev for about 15y.
A couple years ago I had a go at vue.js to make a simple website. I got directed towards its tooling, its weird all-inclusive dev environment and ended up with something that indeed worked - but that was intricately dependent on vue.js runtime processes. Not something I could just add to an existing page. A previous commenter here pointed out how frameworks don't play well with anything other than themselves. If you find a limitation in the framework relative to what you want to achieve, you jump through hoops of restrictions imposed by a framework that has its own opinion, heedless of your needs.
Simply put, unless you greenfield your project to a framework, and marry to it, you're f/cked for any other type of web development.
So I am pretty much of the opinion nowadays that if you have to learn a framework for a specific project, you need to do it, but the real question is, why would you tie yourself up like that? On the contrary, try to not rely on framework idiosyncracies. If it can't play well with existing systems, is it worth betting reliability on, for the long term?
The sole reason frameworks exist is to make your life easier by providing functionalities you need out of the box. It would be too much to always write everything from the scratch.
Also, choosing framework mostly comes from the personal preference. I typically choose React because I'm most familiar with it and I know it's ecosystem very well. I never came into the situation where I thought damn, I wish I didn't chose React but X or did this without any library and I worked on both, small and huge projects.
In very rare cases where you have multiple frameworks on the front-end or need to incorporate them you can implement microfrontends.
Organiser of the Edinburgh Language Exchange and The Edinburgh Open Tech Scene |
Full Snack Developer 🥪, Ramen guzzler 🍜, quiche murderer 🥧. A friendly cat.
Indeed. Frameworks, libraries, and many other applications and tools, are designed to make a task easier.
My point is, if the framework in question and its own ecosystem have a tendency to force you into doing things One Holy Way, at the exclusion of the rest of the ecosystem, it's definitely worth stepping back and thinking, "Why?"
Because of the reason I mentioned in the first point - writing everything from scratch would take too much time and it will lead to unnecessary repetition.
If someone already wrote a library for making HTTP requests, it's properly tested and it's stable, why would you write your own library? Just to be able to say that you're not forced to do things in a certain way?
I used to maintain my own hobby website back un the early 2000's before jQuery time. I wrote a "matrix screen flow" and a drag-and-drop lib for a summer job, puzzling out the differences in position calc between browsers. Hell at the time, but simple enough. Then did zero web dev for about 15y.
A couple years ago I had a go at vue.js to make a simple website. I got directed towards its tooling, its weird all-inclusive dev environment and ended up with something that indeed worked - but that was intricately dependent on vue.js runtime processes. Not something I could just add to an existing page. A previous commenter here pointed out how frameworks don't play well with anything other than themselves. If you find a limitation in the framework relative to what you want to achieve, you jump through hoops of restrictions imposed by a framework that has its own opinion, heedless of your needs.
Simply put, unless you greenfield your project to a framework, and marry to it, you're f/cked for any other type of web development.
So I am pretty much of the opinion nowadays that if you have to learn a framework for a specific project, you need to do it, but the real question is, why would you tie yourself up like that? On the contrary, try to not rely on framework idiosyncracies. If it can't play well with existing systems, is it worth betting reliability on, for the long term?
The sole reason frameworks exist is to make your life easier by providing functionalities you need out of the box. It would be too much to always write everything from the scratch.
Also, choosing framework mostly comes from the personal preference. I typically choose React because I'm most familiar with it and I know it's ecosystem very well. I never came into the situation where I thought damn, I wish I didn't chose React but X or did this without any library and I worked on both, small and huge projects.
In very rare cases where you have multiple frameworks on the front-end or need to incorporate them you can implement microfrontends.
Indeed. Frameworks, libraries, and many other applications and tools, are designed to make a task easier.
My point is, if the framework in question and its own ecosystem have a tendency to force you into doing things One Holy Way, at the exclusion of the rest of the ecosystem, it's definitely worth stepping back and thinking, "Why?"
Because of the reason I mentioned in the first point - writing everything from scratch would take too much time and it will lead to unnecessary repetition.
If someone already wrote a library for making HTTP requests, it's properly tested and it's stable, why would you write your own library? Just to be able to say that you're not forced to do things in a certain way?
Enjoyed reading that 😎