[#14] The changing paradigms of frontend development
bizit.substack.com
Hello readers,
This is an experiment w/ a new content format. I’d love to get some feedback if you think this did not come out well.
I was going through the “State of the Front-end 2022” report yesterday, and some of the points discussed were reminiscent of some of the work I did on the overall theme a few months ago.
Like many others, I began my front-end development journey w/ WordPress (WP). The lively plug-in ecosystem made it easy for anyone to get started, especially if you were a hobbyist. But the most significant pain points w/ WP were performance & maintenance.
Every WP project that took off needed a lot of updates, security patches, scaled-up servers & backends, among other things. Moreover, WP websites are typically full of plug-ins, not every plug-in is updated and/or works w/ the latest versions of WP.
Thus, while the entire plug-in ecosystem made it simple & easy for folks to begin their journey, it also made the entire “building” experience painful.
In comes Jamstack w/ a decoupled architecture → unlike a monolithic WP system, we have a separate backend & frontend. The backend is an API end-point & is separated from the frontend.
End-users do not connect to the database, they connect to the CDN & the CDN can be placed very close to the user & it’d turn out to be more cost-effective than a dedicated server.
And since there’s no direct connection between the user and the database, it’s also more secure. Every build is a separate environment & does not require the developer to worry about things like backups.
This opens up a few interesting questions/observations/conclusions that I’ve been thinking a lot about lately →
With the proliferation of managed backends & dbs, front-end developers have become very capable, almost like full-stack engineers. How does the split b/w front-end and backend engineers inside a modern org look like today?
As the edge/frontend/Javascript drives the state model, what does it mean for cloud databases?
As applications scaled, consuming databases from Heroku was limiting, which caused people to drop off from platforms like Heroku back in the day. Today, we have scalable databases like Planetscale, CockroachDB, and Yugabyte. What does it mean for the future of platforms like Vercel/Netlify as the Heroku 2.0 for frontend?
As we abstract away more of the infrastructure from frontend developers, can we include things like security & privacy as features? Put another way, can we think of empowering frontend developers to be confident that the code they’re shipping is secure & compliant right off the bat?
That is all, thanks.
If you liked this piece, please consider subscribing
If you’d like to discuss more on any/all of these points, please do so in the comments section below, LinkedIn, or on Twitter.
Thanks for reading this piece. If you liked/resonated w/ this, feel free to share it w/ others in your network
[#14] The changing paradigms of frontend development
[#14] The changing paradigms of frontend development
[#14] The changing paradigms of frontend development
I was going through the “State of the Front-end 2022” report yesterday, and some of the points discussed were reminiscent of some of the work I did on the overall theme a few months ago.
Like many others, I began my front-end development journey w/ WordPress (WP). The lively plug-in ecosystem made it easy for anyone to get started, especially if you were a hobbyist. But the most significant pain points w/ WP were performance & maintenance.
Every WP project that took off needed a lot of updates, security patches, scaled-up servers & backends, among other things. Moreover, WP websites are typically full of plug-ins, not every plug-in is updated and/or works w/ the latest versions of WP.
Thus, while the entire plug-in ecosystem made it simple & easy for folks to begin their journey, it also made the entire “building” experience painful.
In comes Jamstack w/ a decoupled architecture → unlike a monolithic WP system, we have a separate backend & frontend. The backend is an API end-point & is separated from the frontend.
End-users do not connect to the database, they connect to the CDN & the CDN can be placed very close to the user & it’d turn out to be more cost-effective than a dedicated server.
And since there’s no direct connection between the user and the database, it’s also more secure. Every build is a separate environment & does not require the developer to worry about things like backups.
This opens up a few interesting questions/observations/conclusions that I’ve been thinking a lot about lately →
With the proliferation of managed backends & dbs, front-end developers have become very capable, almost like full-stack engineers. How does the split b/w front-end and backend engineers inside a modern org look like today?
As the edge/frontend/Javascript drives the state model, what does it mean for cloud databases?
As applications scaled, consuming databases from Heroku was limiting, which caused people to drop off from platforms like Heroku back in the day. Today, we have scalable databases like Planetscale, CockroachDB, and Yugabyte. What does it mean for the future of platforms like Vercel/Netlify as the Heroku 2.0 for frontend?
As we abstract away more of the infrastructure from frontend developers, can we include things like security & privacy as features? Put another way, can we think of empowering frontend developers to be confident that the code they’re shipping is secure & compliant right off the bat?
That is all, thanks.
If you liked this piece, please consider subscribing
If you’d like to discuss more on any/all of these points, please do so in the comments section below, LinkedIn, or on Twitter.
Thanks for reading this piece. If you liked/resonated w/ this, feel free to share it w/ others in your network
Share