Buy a house, or cautiously build your own.
What's the difference between a framework and library? I've had this discussion with developers at work and meetups, and the core idea boils down to this.
You tell libraries what to do, frameworks tell you what to do.
Generally speaking a framework tells you what to do. It has a "right way" of doing things and provides tooling to support you.
All the tools are here
These are frameworks created by dedicated teams, and ship with everything you need to build large-scale applications.
- Basic state management
- Handling forms
- More (UI libraries, animations, etc.)
Official style guides
The respective teams then provide official style guides, depicting their framework's best practices. Once you learn that you're immediately productive.
If you believe in the structure and wish to invest, a framework is perfect for your project. Training new teammates becomes easier too, as they only need to learn one core tool.
Clear upgrade path
On top of that your upgrade path is super clear. Just follow the team's release schedule, read up on their breaking changes, and upgrade when you're ready.
This is just in my experience. I'm sure I've missed something.
Decreased Performance (sort of)
By necessity a framework is comprised of a lot of code. More code means longer download times and decreased performance.
As frameworks become compilers, however, I suspect this will be less of an issue.
Small applications don't need it
A scalable architecture must address many concerns like we discussed above. Some applications are so simple that using an entire framework makes things more complicated. You end up with tons of boilerplate without a ton of payoff.
Going against the framework can be difficult
This reared its head at my first job out of college, where we tried to compile some content outside of Angular's awareness. The result wasn't pretty, but we got the job done after some trial and error, and lots of bruises.
Although I hear Vue lets you incrementally adopt it to your existing application. This sounds promising!
It's a lot to learn
This point applies to any architecture, though. Whatever tool(s) you use, learning all of it takes time. It's either one big tool or many small ones.
You get too comfy
This applies to anything in life–sometimes we get too comfortable doing things in a particular way. This totally depends on your career goals though. Maybe this tool helps you keep a steady job or run an efficient business building applications. If that's what you want, keep doing it!
But if you're like many of us, the same tech every day gets a bit stale. Experimenting with other frameworks and libraries is key to keeping your skills sharp.
In direction opposition to frameworks, libraries are utilities built for a singular purpose.
The list goes on. Let's zoom in on React. What does it do?
That's all it does. Their guides show you how to use React and that's mainly it. The team doesn't officially appoint libraries for global state management, routing, HTTP, services, or forms.
And that's their design choice! It's a great position depending on what you're looking for.
You're in control
A library is 100% in your control. You determine how it's used, and you're sailing smooth after investing some time to learn it.
Add only what you need
If your application is small, a single library may be enough! No need to complicate things. As the app grows, you can mix and match libraries to build your own architecture. It's a great learning experience!
Learn many different tools
It's not all perfect though...
Custom architecture can ruin your app
Custom architectures are fun at first, but can be very costly down the road. I advise extreme caution if it's your first time building one.
A good architecture increases developer productivity and minimizes the pain of adding, modifying, and deleting code.
A bad architecture causes fear and suffering whenever someone touches it.
People choose Angular and Vue because they don't want to risk time and money building their own rules. They simply learn the framework's rules and focus on playing the game.
While in the React world, any two large-scale applications will vary in their structure. It all depends on what the team thought best.
Sometimes too many options is a bad thing, and we're struck by the dreaded analysis paralysis. Instead of picking a library and moving forward, we spend countless hours comparing different libraries that pretty much do the same thing.
It's still a lot to learn
Framework or not, a big application still takes time to understand. This is another reason why strong architecture's important, because it'll ease the learning curve.
Potentially hectic upgrade path
If I got paid every time two libraries in my
package.json weren't compatible after an upgrade, I'd be retired. Enough said.
Want Free Coaching?
If you'd like to schedule a free call to discuss Front-End development code, interviews, career, or anything else follow me on Twitter and DM me.
After that if you enjoy our first meeting, we can discuss ongoing coaching to help you reach your Front-End development goals!
Thanks for reading
For more content like this, check out https://yazeedb.com!
Until next time!