Full Context Development Newsletter Announcement & Astro 2.0 review
Your source of objective analysis about programming tools and trends
Hey Full Context Developer,
It’s been a long while since my last email. Likely you only got the initial confirmation message. A lot has happened in my life during this time but I have cooked up some very ambitious and exciting plans to create a next-level newsletter where everything uses my unique perspective.
If you subscribed on my site because you liked the full context reviews I have some awesome news to share!
I will be writing similar, but shorter takes on the most recent releases and updates of tools or new trends mainly in the frontend world. My goal is to fight the hype with an objective take on the real life benefits of what the “things“ actually provide. No BS, no fanboying, no marketing, just analyzing what the tools are really good for in terms of generated value. I expect that it will fuel some interesting comparisons too.
How can this benefit you?
It helps to create compelling arguments for tech decisions with an objective, results-oriented take. That in turn can help your career growth.
If you are new to software engineering it can help you to understand how our work connects to the wider business and how one influences the other.
For experienced developers this can open up new ways to collaborate with stakeholders and decision makers outside of engineering.
For entrepreneurs, founders and early startup employees it helps to find the solid tech foundations that lead to the business outcomes you want to achieve.
If any of that sounds interesting, read on! Oh yeah, just to make sure we are on the same page, I will use the evaluation system from my book and reviews. If you are not familiar with the RIP CAR, CPU-DB and Impact Point concepts, I have a short introduction in this blog post.
Astro 2.0 release
(The heading is a link to the release announcement. Read it if you need more context)
This one sets us up for a strong start! Astro is one of the most exciting tools in the FE world in the last year or so. It packs a lot of fancy keywords and has a lot of hype around it. This new release just ups the game so let’s dive deep into the latest changes and find out who can benefit from them and by how much. Here’s the quick summary:
Content Collection API
I will be honest, I hate schemas, but however much I dislike them this feature packs a lot of business value for a broad range of companies!
Mdx
and Frontmatter
are nice tools to work with as developers and Astro 2.0 solves a real pain with possibly huge impact for the low price of some upfront schema definitions. Preventing simple mistakes at build time that can bring down entire sites is the kind of improvement that makes an upgrade to a new version a no-brainer. If it can prevent some of the P1 incidents this feature saves customer satisfaction and trust, money and developer hair. Intellisense and added type-safety are icing on the cake that add a bit to developer productiveness and reduces the required long term maintainability effort.
Who would gain the most from it? Written content heavy sites with lots of
mdx
files. It's most impactful when the user base is large and even more so if lots of people are working on those file, so the chances of error multiply. In terms of my own scale of frontend project categories it translates to Level 1 & 2 complexity. (See the image below, preferably opened in a new tab)
Who should not care? Web application type project (think Gmail), or any non static-content focused sites. To an extent smaller companies where the chances of error are lower. These mostly translate to Level 3 & 4 from the scale and lower Level 1.
Impact points in best case scenario: (Scale down according to your situation)
Business Opportunity: +100 by preventing P1 issues
Customer Experience: +100 in the same vein
Productivity: +100 for easing the work of all developer through the schema setup likely done by one person.
Hybrid Rendering
Hybrid rendering sounds cool but it’s not a groundbreaking, new idea. It gives Astro the capability to mix SSR and SSG functionalities in the same application. In other words you don’t have to choose between the two anymore. It’s how Next.js and similar frameworks worked for quite a while. Nonetheless, if you are an Astro user this opens up some cool possibilities with impactful benefits.
Mixing the two modes enables you to find the appropriate choice for different situations. SSR is best utilized when delivering dynamic content. You can look things up from a DB, personalize parts of the app or put it behind authentication. It helps with SEO performance compared to client side rendering, and in case of Astro it is the only way to reduce sometimes painstakingly long built times if you work on a site with (tens of) thousands of pages. On the other hand, SSG improves the first meaningful paint metric, which in turn increases customer engagement and conversion rates. When you are showing real time data the only option is to use client side rendering so the choice of rendering strategy boils down to the need of dynamic content vs loading speed on those pages.
To have the best of both worlds you would need an On-demand incremental regeneration like feature, where you can dynamically cache SSR’d pages and invalidate the cache programmatically, while also having the choice of doing good-old SSG.
Your deployment choices are limited to the SSR supported options and I’m not aware of documented ways to self-host hybrid rendering Astro projects, let me know if you do.
Who would gain the most from adopting it? It depends on what you used so far. SSR is in general best fits E-commerce sites, or very large sites with static content where SEO performance matters but SSG would clog down your deployment, development or CI/CD processes. So this is clearly targeted toward big, or soon to be scaled projects. SSG can be a critical tool to increase conversion rates and to extend user journeys. That’s best suited for marketing sites, landing or sign-up pages or anything with a clear CTA (call to action) purpose.
Who should not care? Well, I think everybody should care who are not working on Level 3 & 4 applications. Level 3 might still benefit from them if has parts from the Level 1 & 2 category.
Impact points in best case scenario: (Scale down according to your situation)
Business Opportunity: +200 by improving SEO of dynamic pages
Customer Experience: +1000 if your business critical pages had to be SSR’d before but SSG now improves conversion rates significantly.
Productivity: +1000 if the project is large enough for the SSG build to seriously bog down the work processes and now you can alleviate this with SSR.
Costs: +200 if the project is large enough so that the SSG build process adds significant costs through large CI/CD resource usage and now you can alleviate this with SSR.
The Rest
Errors, Redesigned / Dev Server Optimization / Vite 4.0 / The Astro Open Roadmap all belong to the same category from my perspective so there’s no need to analyze them separately.
Tools like these that improve the efficiency of developers by either speeding up the work processes or making it more reliable and easier to plan have the same business effects. They lower costs directly through the reduced engineer hours and improve customer experience by speeding up the release cycle. In turn they can help with improving customer trust in- and loyalty for the product.
Who would gain the most from these changes? The obvious answer is everybody, of course. However teams working with tight deadlines or under resource constraints can benefit the most from these upgrades. Projects that depend on deep and prolonged customer relationships (involvement in user communities, cross sale and up sale business models) can reap more than average returns from these changes.
Who should not care? Well, nobody? If I really want to come up with a relevant case here, when your development efficiency is not a bottleneck to reach your goals you might simply don't mind these, but who wouldn't care about improving their development experience? I, for one, would never say no to that.
Impact points in best case scenario: (Scale down according to your situation)
Business Opportunity: +100 as a faster release cycle can contribute getting early feedback that helps to increase product market fit and to beat the competition.
Customer Experience: +100 as a faster release cycle can contribute to improved customer engagement and loyalty.
Productivity: +1000 depending on team size, the effects of build improvements and ease of debugging can add up to significant improvements.
Costs: +200 depending on team size, the effects of build improvements and ease of debugging can add up to significant reductions in engineering hours.
In Summary
Astro managed to create an update that makes developers’ lives better while delivers a huge chunk of added business value for a lot of use-cases. I hope they will keep up with this level of improvement release-after-release. The future of the project will be a blast!
In conclusion, who gains the most from the upgrade? 2.0 brings the most benefits to big websites with lots of static content and lots of users. It’s also very impactful for marketing and landing pages. It’s not a hard sale for any other type of project though, the added quality-of-life improvements will help any developer using Astro.
And finally the total business impact of this release:
(If you are unfamiliar with this stuff, scroll to the bottom of this page: Code to Money Roadmap)
It sums up to:
Increased Revenue: 1440 IP
Protecting Revenue: 590 IP
Reducing Costs: 1875 IP
Avoiding Costs: 290 IP
This wraps up the first volume of the Full Context Development Newsletter! Wholehearted thanks for sticking around till the end. Please let me know your thoughts on Twitter @fullctxdev or here in the comments. If you would like me to write about something specific make sure to shout out! I’m all ears.
As an early newsletter every share can make the difference so I appreciate them super very much. See you in the next one!
Nice! This one sounds like a no-brainer. Did it look like there were any gotchas for people trying to upgrade from 1.X? Ever since Vite screwed everyone over moving to 3.0 I hesitate to assume upgrades are minimal.