I am still not over the collapse of Gatsby (for reference i nearly joined the company in 2017, was saved only by my own character flaws).
They rode the highs - being the default docs tool for React, and building a massive ecosystem of integrations you could install out of the box. But too many abstractions, divided goals between cloud and OSS, and the better stewardship/design of Nextjs brought it down.
There were the simple lessons (https://swyx.io/a-world-without-plugins-cig). its easy to say in hindsight that graphql was too much for gatsby. i also believe the company went too hard for number of integrations over quality of them, an issue I had even in my interview. this was a poorer expression of the better insight that seb markbage had; just have a small api surface area bro (https://www.youtube.com/watch?v=4anAwXYqLG8)
But the bigger lesson is bitterer. Frontend tooling isnt worth that much. the fact that vercel is pretty much the only successful frontend startup of its generation makes it an exception to the rule (there are plenty of smaller companies that are thriving, like tailwind, but it is not a venture scale startup and thats fine). People dont pay for frontend tooling. they expect it to be free, expect it to do everything, get into internicine squabbles between frameworks when they are all basically doomed compared to just betting on React sponsored by Facebook and now Vercel (and a little bit of Shopify), or going back to fullstack frameworks like Django/Rails/Laravel. all frontend tooling, nextjs included, is just leadgen, loss leaders, while investors/salespeople patiently wait until you "grow up" by... building cloud backend/ci/cd services.
5 years ago i wrote about the "frontend ceiling" for individual developer careers (https://x.com/swyx/status/1682748872047886337) - i fear this is the "frontend ceiling" for companies.
I deeply admire Astro and hope they figure out a way to break the ceiling. Their recent cloud products have been encouraging.
I am for one surprised that the initial concept of Gatsby -- a static site generator with React, GraphQL and other hype words of late 2010s -- was actually able to raise $40+ million dollars to build a platform for what to me at the time seemed incredibly over-engineered stack for static html pages and an unproven founder.
RIP ZIRP. Kyle was cool and had the right attitude about a lot of things. He built some great frontend tooling e.g. fontsource, without locking it into his larger projects like Vercel did. That was very altruistic. Regardless, yeah, I couldn’t believe it when Gatsby got its seed round. It was a wild time.
Kyle is a great guy. Just to correct the timeline a little bit, I only created Fontsource after its predecessor, Typefaces (which was made by Kyle), was left abandoned when Gatsby took off.
I wouldn’t say he made Typefaces specifically for the Gatsby ecosystem, but he definitely had the hacker mindset for creating frontend tooling for a while.
Thank you for that correction! I had to google to find the name because I was fuzzy on it. Your last paragraph matches my recall. The point I was trying to make was that I appreciated that Typefaces wasn’t automatically part of Gatsby just because of Kyle’s affiliation.
> But the bigger lesson is bitterer. Frontend tooling isnt worth that much.
This is a modern oddity, as historically front end tooling was worth a lot.
During the 80s and 90s, multiple companies made a lot of money off of front end tooling. Even as late as 2009 or so, Silverlight tooling was bringing in money for Microsoft. But think of how popular Flash was and the empire that helped build. Prior to that. Visual Basic helped Microsoft take over the world. Go back another generation and Borland's Delphi dominated for years.
And, arguably, all of those systems were more productive than anything we have now. (A topic I've written about many times!) As an industry, we may indeed be getting exactly what we pay for.
I lived through the times when you had to pay lots of money for software tooling. As a kid from a third-world country, I don't share the same rosy sentiment towards those times.
It's too easy to take for granted, but modern-day free open-source tooling is a godsend for a lot of folks out there.
Historically software companies were smart enough to overlook piracy outside of their key markets. Plenty of poor American kids learned to program on pirated copies of visual studio.
Some point the company's got greedy and decided they want to crack down in all piracy. This shortsightedness first hit Adobe. I'd estimate that half the people who know photoshop learned it on a pirated copy. The harder Adobe makes piracy, the fewer kids teach themselves photoshop.
Microsoft, to their credit, made Visual Studio Community Edition, although IMHO they nerfed the first few releases too much.
You can view commercial software with overlooked piracy as a form of the rich subsidizing everyone else.
Again it is unfortunate that companies got greedy and tore the system down for a one time boost in revenue.
> Even as late as 2009 or so, Silverlight tooling was bringing in money for Microsoft
Huh. It always kinda seemed like a "Microsoft's version of <...>, because Microsoft always has to compete with everything, including <...>". In this case, <...> is "Adobe Flash"
I'm curious if people have examples of what it was used for?
Looking at the Wikipedia page [1] which says
"According to statowl.com, Microsoft Silverlight had a penetration of 64.2% in May 2011. Usage on July 2010 was 53.6%, whereas as of May 2011 market leader Adobe Flash was installed on 95.3% of browsers, and Java was supported on 76.5% of browsers.[10]"
That shocked me - what was this used for, anyways?
Wikipedia goes on to say
"Silverlight was used to provide video streaming for the NBC coverage of the 2008 Summer Olympics in Beijing,[11] the 2010 Winter Olympics in Vancouver,[12] and the 2008 conventions for both major United States political parties.[13] Silverlight was also used by Amazon Video and Netflix for their instant video streaming services"
If Silverlight was being used for Netflix I can see it being installed on 60%+ of browsers just from that.
Still, I'm curious - anybody have have examples of what else it was used for?
Silverlight's real usage was rapid internal corporate app development. Internal tools basically. It is hard to describe exactly how absurdly popular Silverlight was at the time within corporations.
Microsoft had a big internal political battle and did the stupidest thing possible and abandoned Silveright, which pissed off a LOT of companies, who then started building internal web apps instead. This lead to a slow migration off of Microsoft's technology stack within companies, and now basically Office is what is left.
For younger developers, it is hard to describe what life was like before.
So you'd go to work, and there was a custom C#, or possibly Visual Basic, time tracking app you logged into. Internal corporate web pages were written in ASP, or ASPX. Lots of internal databases were running on SQL server or just MS Access, and you directly talked to them through custom apps running on your machine.
Because the C#/VB development experience was so good, this was honestly easier than writing a website is now. Because apps only had to run on one platform (Windows) and mobile didn't exist yet, making UIs was easy-peasy. Microsoft made a ton of inroads into corporate because Bob from Accounting figured out he could setup a database running off of a local file share (MS Access) and write a simple GUI to keep track of vacation usage using some books he found in his local library, or maybe he even got ahold of some old MSDN CDs, which literally had higher quality documentation and examples than anything made in the last 15 years or so.
Silverlight was a continuation of that linage, super easy to write UIs in, super fast to develop. You could data bind a form to a backend database in a few minutes. You'd get full accessibility, hotkeys, everything, faster than you can debug a single CSS issue.
From what I understand (I was a very low level employee when it all went down) the OS org got pissed that the developer org was basically making the dominant UI framework, ripped it away from them and rewrote it as WinRT. Short of it is, Microsoft ended up losing mobile, they lost the trust of corporations, and they lost the trust of developers. After Silverlight died there aren't really anymore "Windows developers" as a career field. Everything moved to websites.
Good analysis. They really killed the golden goose, never understood it. But internal rivalry makes sense, the same thing that bankrupted Nokia.
I know a lot of developers that were really happy in that older Microsoft ecosystem, it was a semi permeable walled garden where you could walk 'the Microsoft way' and everything was kind of laid out before you, neat and cosy. At the dev conferences when javascript started to become unavoidable, there was still a period where they kind of pretended Microsoft invented the web and gave it a nice but small spot alongside all the other, more important technology with which Real Developers make Real Software.
You could have discussions on architecture, but nothing fundamental really, and you'd always follow the prescribed pathways that Microsoft thought out for you. These changed every couple of years, which gave everybody new goals, new certifications to reach, new rewrites to accomplish and get paid for. Anyone that was moderately skilled was quite productive, and it was very easy to get into.
When the web got more complicated than html + jquery in server side generated templates, these developers often had a very bad time and fully retreated into their 'backend' role. The most recent anti javascript stronghold is Blazor, not sure if that is still a viable way to avoid modern frontend tooling.
I never really understood why Microsoft abandoned desktop gui apps like they did and left their walled garden unattended. It was one of their strong points, even though I disliked it a lot.
I remember Access + SQL Server being popular, and ASP/ASPX being popular, and Visual Studio experience being easy + popular, and never quite understood why everyone switched to the web stack.
Silverlight legacy lives on in the form of https://opensilver.net. I don't have experience with it, but am going to assume that it's a shadow of the former self.
They do have a pretty cool demo project however: https://xaml.io
yes good point. ofc Unity/Unreal Engine today also makes great money.
i think those frontends you mention made money because they had defacto monopoly on a certain platform or kind of experience that was unavailable anywhere else. xcode is a piece of absolute crap but i still have to pay $100 a year or whatever for it.
perhaps the emergence of web standards - both JS and browser standards - killed frontend. when everyone can build their own tools that run everywhere, and the browser api's are often pretty good, then why buy instead of build, or pick the next one that is free and good enough.
> xcode is a piece of absolute crap but i still have to pay $100 a year or whatever for it.
You say xcode is horrible, but have you tried opening a project in Android Studio after 6 months and getting it to compile again?
It was funny, when I was at Microsoft, almost no one used Visual Studio because it wasn't able to handle code on the scale of MS's code bases. (I think things may be different now). That and it didn't support unusual build scenarios (which now it does.)
I wonder if it is the same case at Apple with xcode. Do OS engineers on MacOS actually use xcode to developer MacOS?
Astro is what I wanted and thought Gatsby would be. GraphQL was the wrong sized abstraction for a basic blog site like mine. And once Gatsby turned towards the cloud (which made sense as a business), everything just got so complicated. I was swept up by it too.
Cool insight on frontend ceilings -- deployment is king.
I think frontend tooling is valuable, but there’s so much good free out there that it’s hard to monetize.
Gatsby always seemed wildly overengineered to me. It’s like all the bad parts of react, with all the bad parts of complicated js tooling, and none of the upsides.
Is any tooling worth that much, really? I think the key is that backend tooling lends itself to selling hosted solutions, while frontend tooling is usually stuff you run locally or on CI to build artifacts. Sure, there are exceptions, but most people don't pay for developer-focused software anymore, at least not directly.
My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.
Remix is backed by Shopify, compared to Next.js being backed by Vercel. Does this influence any decision to take?
Today Next.js has a big advantage which is that they have already integrated most of the new React 19 rendering features and apis. I think it will take a while for Remix to catch up to that.
Other notable frameworks are community led Waku made by Daishi Kato from Pmdrs and TanStart made by Tanner from Tanstack.
Also there's Redwood.js betting on a more integrated experience.
Today I am using Nextjs because I don't think I can go back to not using RSCs, but when Remix catches up or Waku and TanStart get to v1, I sure will give them a serious try!
Shopify "backing it" means less to me than the maintainers themselves. The Remix maintainers are straight shooters and have been maintaining open source consistently for over a decade now.
how strongly do you believe this. because ive just read both docs and i think they have different goals/audiences (tho obviously same owner). i think react router will be a poorer project if it starts to require serverside components like it is looking
They made an announcement that they are merging the projects a little while back: https://remix.run/blog/merging-remix-and-react-router. Obviously things could change, but I think RR v7 will effectively be the next iteration of Remix.
Honestly, I hated Prisma for the longest time. Like, hated it. I tried to rip it out of projects multiple times. Why would you build a node library in Rust? (as one of many problems) But, I had a mental shift recently that helped me appreciate it more: I use Prisma only for features that fit neatly into an simple ORM (i.e. building a web page based on a bunch of joins). Anything else, I use raw SQL.
- If I want derived data, write views that encapsulate the transform. Prisma supports reading from views
- If I need something more complex, use DuckDB + python for analysis and write to the appropriate table.
- If I need to cache complex queries, just use a materialized view and read it as a prisma object
It's not perfect, but that let's me use prisma for what it's good at (Managing an ORM and deeply nested queries), then fall back into raw SQL for everything else.
Going straight to SQL has been a breath of fresh air, but, let's be honest, dealing with deeply nested joins really sucks when all you want to do is build a page that shows a company, all of it's people, and all of those people's relationships. ORMs are pretty handy for that last case, and I use SQL for everything else
I've looked into it a bit. I'm getting to the point where I either want to use a full ORM, or I want to write raw SQL and have it checked against the database.
Query builders are nice, but they sometimes end up in this middle ground where they have the worst parts of an ORM (needing to learn a new syntax and not getting access to all the DB features) and the worst parts of raw SQL (Unpacking relationships into objects w/ pointers is error prone boilerplate that sucks to write).
I love SqlAlchemy since it's still enough of an ORM to solve the main problem I want solved. Super curious to hear if you've had good experiences with Keysley and how it deals with transforming relationships into objects
Astro is fantastic. I initially used NextJS with MDX, and something simple like using relative markdown links to images was utterly impossible.
I remember going down a day long rabbit hole to understand why, and it boiled down to content layer, MDX and NextJS using different, incompatible module loaders, bundlers or transpilers of some kind[1][2][3]. Ridiculous. And don’t get me started on the image component.
In the end, Astro just works. No need for React (unless you want it), it’s simple, fast and produces a static site you can use without JavaScript.
Data fetching is also utterly trivial, so you can have a fully static site with “live” data pulled in at compile time.
My personal website was originally written this way. The compile and build script was about 20 lines of shell scripting (relying on pandoc), and could have probably been reduced further. It worked very well and I stuck with it for about 2 years before moving on to Hugo. It was a good experience to hand-roll all the components of a static site, and something every web dev should be required to do early in their career.
I don’t love js/ts but Astro is so nice. Don’t have to fiddle with react or graphql. Just upgraded to 5 beta and nothing broke. Really well managed project. Oh, and page load speed is insane.
If you don't love js/ts maybe you'd like Civet, which transpiles to js/ts and has Astro integration. (No relationship, I've just been looking at it myself.)
transpiling to JS that has if, if else structures instead of just early return if makes me not trust it (based on first "pattern matching" example on civet.dev site). I guess I have my prejudices.
I have heard great things about astro, but my experience with Gatsby keeps me away. I would much rather keep an SSR framework like Remix and handle whatever pipeline is needed myself. No magic.
I felt the same way! But I came around. Take a look at the source code for a component [1]. The .astro format is pretty much just TS, CSS, and HTML. I don't even need React anymore. Way less glue code and dependencies than with Gatsby. There is a configuration file and some abstractions for things like collections, but almost everything is opt-in.
There's not really any DSL. You just put some TS in the frontmatter for fetching/transforming at build time, TS in a script tab (if needed) and the html is just basic templating that takes props.
Fully concur with the points you made. I also just finished transitioning my personal website to Astro from an Eleventy setup that I got too lazy to maintain. I made a couple of landing pages for clients and my own projects with Astro and the maintenance experience was eye-opening.
Astro really is quite wondrous. If you don't stray too far from its opinionated route, it's almost magical. But some more advanced things do still take some tinkering. My sitemap and RSS with full text setups I wouldn't describe as the most elegant things in existence, but they do their job.
What I'm still lacking/wondering about is whether there's a CDN static site/serverless hosting provider like Netlify, Vercel or Cloudflare, but that isn't free or $20/mo. I'd like to pay for a good service that obviously has running costs, but I don't believe there's quite something like those.
Anyway, I like the website. It's easy on the eyes.
Thanks for sharing! I use Fireabse Hosting, which I guess gets grouped in with the other services you mentioned. It's free, has a lightweight devX, and integrates with CI via GitHub actions for preview and production builds [1].
Right, I didn't consider Google. The 360MB/day of free egress traffic (Spark plan) strike me as very peculiar. But at least it isn't Cloudflare's "unlimited" with secret limits in place, or Netlify's 100GB/month and then enormous costs on everything above.
Thanks for reminding me! I'll give Firebase a look.
By the way, very minor thing I noticed. Clicking on your photo on the homepage swaps backgrounds, but the timer-based swapping still runs on its fixed interval. Can look unpolished if you click it a bunch or in the wrong moment.
This looks lovely! I've been recently working on sth similar: building a custom pipeline from my Obsidian notes into a website (untested.sonnet.io).
I ended up using 11ty because I wanted to stick as close to the web platform as possible, but a part of me wishes I had tried Astro as well. Mainly because I feel that it strikes the right balance when it comes to flexibility and boilerplate. 11ty is lovely, but there was soooo much stuff I had to write from scratch. I feel like it paid off, but it took me much longer than I had hoped.
One surprising side effect: I noticed that the site worked faster online than served from localhost. 5 minutes of digging after I remembered that it's served via HTTP2 w. multiplexing. I'm not even interested in adding a bundler/minify step, just plain CSS/HTML and asset optimisation w. 11ty-image is enough.
Plus one for eleventy. Love its minimalism and flexibility, although it means that there isn't a clear guidance on assets management. It's a shame that the web still doesn't have a standard way of authoring components, and different frameworks and static-site generators, including eleventy, have to invent their own.
OK, so 11ty webc is pretty good and feels relatively low on abstraction. The only issue I've had with it was the developer UX (e.g. some components getting "stuck" during livereload, so I needed to manually restart 11ty to see the changes). Webc also supports bundles.
What 11ty lacks (assuming I don't add vite, keep things minimal), are components/composition, i.e. actually being able to compose templates without seeing them as templates but as DOM.
I recommend checking out some videos about .webc and progressive enhancement, there's a small paradigm shift from both React-like components map to a tree that maps to pixels and a more traditional old timey PHP-like string interpolation in templates. (I'm expressing this poorly as I'm in a rush, sorry!)
~4 years ago, redesign phase of our 50K a month public facing wordpress NGO website, agency strongly suggests moving to gatsby. We/I thought about it for 5 minutes and said no. I am still happy with that decision and I will push to take the same if/when another agency comes at us with Astro. Node CMS are autophagous.
Astro is great. I love that I can mix and match between markdown, plain HTML, and Svelte components as needed (and even intermix them within a page). Pretty much the sweet spot I always wanted for a blog or marketing site: 98% static stuff, 2% sprinkles of JS.
In early experiments it feels like Inertia.js be this same feeling but for Rails and Laravel.
I never got very far on the Gatsby train. It always felt so slow and fragile during local dev, and while GraphQL was cool it felt like total overkill for most of the data I needed to grab (like… markdown files from disk).
Not a full replacement in all scenarios. But for my personal website with a basic blog, Astro is by far the simpler and more maintainable option. I bet that is true for most people here who maintain their own personal website.
This is a bit misleading. You are only prevented from using UI libs that use a Provider/Context (like Mantine does) since Astro does not support Context.
Things like shadcn/ui work fine, even when statically rendered.
You could just slap on any library like Swup.js, Turbo, etc. and get SPA-like fast navigation out of a regular "MPA" Astro site. And that's true for any MPA, actually.
You can achieve SPA-like navigation in Astro with their transitions API, but if that’s what you’re after it’s better to use Next.js or Remix IMO.
(I helped build playboy.com/magazine with Astro, which uses the transitions API for this SPA-like behavior… as well as playboy.com/app (nsfw) with Next.js)
I spent the entire time building a business network platform with Astro instead of WordPress or other web frameworks because it is exactly what I need to easily manage UI components and provide a safer JSX-like environment.
In comparison to Ruby on Rails, Django, and Laravel, Astro stands on the same level but much less learning curve.
Astro is a step in the right direction. But I wonder why in 2024 we still have to deal with proprietary component languages? I would like something like Astro with web components. Perhaps with the help of lit.
With this the pure markdown content could be easily enriched with components.
This is my dream also. I much much prefer lit-html syntax to Astro’s.
I even found standard declarative shadow dom style components to be a pain in the ass in Astro which left a bad taste in my mouth since that’s literally just stock standard HTML.
Great write up, will be curious to see if Astro sticks around. It seems like all the static site gens last a few years then fade away - Jekyll, Hugo, Gatsby, etc.
Me too! The closer my framework is to raw HTML, JavaScript (really TypeScript nowadays), and CSS, the less lock-in I feel. Those 3 languages are continue to get better year over year. And we are get better framework abstractions every few years too. Astro feels like it hit the sweet spot, but maybe there is more to come.
keystatic supports editing mdx files. keystatic is basically a frontend to update files on github, so if e.g. you want to write a blog post from your phone it can let you do that kind of thing.
Gatsby gets shit on a lot - which I think is a but unfair. I find it to be a solid, well-documented platform. It has some rough spots, but show me a platform that doesn't.
The author also complains that:
> I couldn’t build the site locally or upgrade dependencies, leaving it outdated since 2019
This is true of many things in the javascript ecosystem. In react/node/js-land you HAVE to invest in maintenance (and re-writes) or be left with a legacy codebase that just might not work one day if npm install fails.
I am still not over the collapse of Gatsby (for reference i nearly joined the company in 2017, was saved only by my own character flaws).
They rode the highs - being the default docs tool for React, and building a massive ecosystem of integrations you could install out of the box. But too many abstractions, divided goals between cloud and OSS, and the better stewardship/design of Nextjs brought it down.
There were the simple lessons (https://swyx.io/a-world-without-plugins-cig). its easy to say in hindsight that graphql was too much for gatsby. i also believe the company went too hard for number of integrations over quality of them, an issue I had even in my interview. this was a poorer expression of the better insight that seb markbage had; just have a small api surface area bro (https://www.youtube.com/watch?v=4anAwXYqLG8)
But the bigger lesson is bitterer. Frontend tooling isnt worth that much. the fact that vercel is pretty much the only successful frontend startup of its generation makes it an exception to the rule (there are plenty of smaller companies that are thriving, like tailwind, but it is not a venture scale startup and thats fine). People dont pay for frontend tooling. they expect it to be free, expect it to do everything, get into internicine squabbles between frameworks when they are all basically doomed compared to just betting on React sponsored by Facebook and now Vercel (and a little bit of Shopify), or going back to fullstack frameworks like Django/Rails/Laravel. all frontend tooling, nextjs included, is just leadgen, loss leaders, while investors/salespeople patiently wait until you "grow up" by... building cloud backend/ci/cd services.
5 years ago i wrote about the "frontend ceiling" for individual developer careers (https://x.com/swyx/status/1682748872047886337) - i fear this is the "frontend ceiling" for companies.
I deeply admire Astro and hope they figure out a way to break the ceiling. Their recent cloud products have been encouraging.
I am for one surprised that the initial concept of Gatsby -- a static site generator with React, GraphQL and other hype words of late 2010s -- was actually able to raise $40+ million dollars to build a platform for what to me at the time seemed incredibly over-engineered stack for static html pages and an unproven founder.
It was truly a testament of times
RIP ZIRP. Kyle was cool and had the right attitude about a lot of things. He built some great frontend tooling e.g. fontsource, without locking it into his larger projects like Vercel did. That was very altruistic. Regardless, yeah, I couldn’t believe it when Gatsby got its seed round. It was a wild time.
Kyle is a great guy. Just to correct the timeline a little bit, I only created Fontsource after its predecessor, Typefaces (which was made by Kyle), was left abandoned when Gatsby took off.
I wouldn’t say he made Typefaces specifically for the Gatsby ecosystem, but he definitely had the hacker mindset for creating frontend tooling for a while.
Thank you for that correction! I had to google to find the name because I was fuzzy on it. Your last paragraph matches my recall. The point I was trying to make was that I appreciated that Typefaces wasn’t automatically part of Gatsby just because of Kyle’s affiliation.
we do live in a society
> But the bigger lesson is bitterer. Frontend tooling isnt worth that much.
This is a modern oddity, as historically front end tooling was worth a lot.
During the 80s and 90s, multiple companies made a lot of money off of front end tooling. Even as late as 2009 or so, Silverlight tooling was bringing in money for Microsoft. But think of how popular Flash was and the empire that helped build. Prior to that. Visual Basic helped Microsoft take over the world. Go back another generation and Borland's Delphi dominated for years.
And, arguably, all of those systems were more productive than anything we have now. (A topic I've written about many times!) As an industry, we may indeed be getting exactly what we pay for.
I lived through the times when you had to pay lots of money for software tooling. As a kid from a third-world country, I don't share the same rosy sentiment towards those times.
It's too easy to take for granted, but modern-day free open-source tooling is a godsend for a lot of folks out there.
Historically software companies were smart enough to overlook piracy outside of their key markets. Plenty of poor American kids learned to program on pirated copies of visual studio.
Some point the company's got greedy and decided they want to crack down in all piracy. This shortsightedness first hit Adobe. I'd estimate that half the people who know photoshop learned it on a pirated copy. The harder Adobe makes piracy, the fewer kids teach themselves photoshop.
Microsoft, to their credit, made Visual Studio Community Edition, although IMHO they nerfed the first few releases too much.
You can view commercial software with overlooked piracy as a form of the rich subsidizing everyone else.
Again it is unfortunate that companies got greedy and tore the system down for a one time boost in revenue.
until it goes unmaintained because nobody pays for it
> Even as late as 2009 or so, Silverlight tooling was bringing in money for Microsoft
Huh. It always kinda seemed like a "Microsoft's version of <...>, because Microsoft always has to compete with everything, including <...>". In this case, <...> is "Adobe Flash"
I'm curious if people have examples of what it was used for?
Looking at the Wikipedia page [1] which says
"According to statowl.com, Microsoft Silverlight had a penetration of 64.2% in May 2011. Usage on July 2010 was 53.6%, whereas as of May 2011 market leader Adobe Flash was installed on 95.3% of browsers, and Java was supported on 76.5% of browsers.[10]"
That shocked me - what was this used for, anyways?
Wikipedia goes on to say
"Silverlight was used to provide video streaming for the NBC coverage of the 2008 Summer Olympics in Beijing,[11] the 2010 Winter Olympics in Vancouver,[12] and the 2008 conventions for both major United States political parties.[13] Silverlight was also used by Amazon Video and Netflix for their instant video streaming services"
If Silverlight was being used for Netflix I can see it being installed on 60%+ of browsers just from that.
Still, I'm curious - anybody have have examples of what else it was used for?
[1] https://en.wikipedia.org/wiki/Microsoft_Silverlight
Silverlight's real usage was rapid internal corporate app development. Internal tools basically. It is hard to describe exactly how absurdly popular Silverlight was at the time within corporations.
Microsoft had a big internal political battle and did the stupidest thing possible and abandoned Silveright, which pissed off a LOT of companies, who then started building internal web apps instead. This lead to a slow migration off of Microsoft's technology stack within companies, and now basically Office is what is left.
For younger developers, it is hard to describe what life was like before.
So you'd go to work, and there was a custom C#, or possibly Visual Basic, time tracking app you logged into. Internal corporate web pages were written in ASP, or ASPX. Lots of internal databases were running on SQL server or just MS Access, and you directly talked to them through custom apps running on your machine.
Because the C#/VB development experience was so good, this was honestly easier than writing a website is now. Because apps only had to run on one platform (Windows) and mobile didn't exist yet, making UIs was easy-peasy. Microsoft made a ton of inroads into corporate because Bob from Accounting figured out he could setup a database running off of a local file share (MS Access) and write a simple GUI to keep track of vacation usage using some books he found in his local library, or maybe he even got ahold of some old MSDN CDs, which literally had higher quality documentation and examples than anything made in the last 15 years or so.
Silverlight was a continuation of that linage, super easy to write UIs in, super fast to develop. You could data bind a form to a backend database in a few minutes. You'd get full accessibility, hotkeys, everything, faster than you can debug a single CSS issue.
From what I understand (I was a very low level employee when it all went down) the OS org got pissed that the developer org was basically making the dominant UI framework, ripped it away from them and rewrote it as WinRT. Short of it is, Microsoft ended up losing mobile, they lost the trust of corporations, and they lost the trust of developers. After Silverlight died there aren't really anymore "Windows developers" as a career field. Everything moved to websites.
Good analysis. They really killed the golden goose, never understood it. But internal rivalry makes sense, the same thing that bankrupted Nokia.
I know a lot of developers that were really happy in that older Microsoft ecosystem, it was a semi permeable walled garden where you could walk 'the Microsoft way' and everything was kind of laid out before you, neat and cosy. At the dev conferences when javascript started to become unavoidable, there was still a period where they kind of pretended Microsoft invented the web and gave it a nice but small spot alongside all the other, more important technology with which Real Developers make Real Software.
You could have discussions on architecture, but nothing fundamental really, and you'd always follow the prescribed pathways that Microsoft thought out for you. These changed every couple of years, which gave everybody new goals, new certifications to reach, new rewrites to accomplish and get paid for. Anyone that was moderately skilled was quite productive, and it was very easy to get into.
When the web got more complicated than html + jquery in server side generated templates, these developers often had a very bad time and fully retreated into their 'backend' role. The most recent anti javascript stronghold is Blazor, not sure if that is still a viable way to avoid modern frontend tooling.
I never really understood why Microsoft abandoned desktop gui apps like they did and left their walled garden unattended. It was one of their strong points, even though I disliked it a lot.
Thanks for the reply! That was very illuminating!
I remember Access + SQL Server being popular, and ASP/ASPX being popular, and Visual Studio experience being easy + popular, and never quite understood why everyone switched to the web stack.
Silverlight legacy lives on in the form of https://opensilver.net. I don't have experience with it, but am going to assume that it's a shadow of the former self.
They do have a pretty cool demo project however: https://xaml.io
SAP used it for their CRM when they moved from desktop client to browser based clients.
we used it for a highly interactive scheduler UI in a commercial software project. The appeal was do Flash development with .Net developers.
yes good point. ofc Unity/Unreal Engine today also makes great money.
i think those frontends you mention made money because they had defacto monopoly on a certain platform or kind of experience that was unavailable anywhere else. xcode is a piece of absolute crap but i still have to pay $100 a year or whatever for it.
perhaps the emergence of web standards - both JS and browser standards - killed frontend. when everyone can build their own tools that run everywhere, and the browser api's are often pretty good, then why buy instead of build, or pick the next one that is free and good enough.
> xcode is a piece of absolute crap but i still have to pay $100 a year or whatever for it.
You say xcode is horrible, but have you tried opening a project in Android Studio after 6 months and getting it to compile again?
It was funny, when I was at Microsoft, almost no one used Visual Studio because it wasn't able to handle code on the scale of MS's code bases. (I think things may be different now). That and it didn't support unusual build scenarios (which now it does.)
I wonder if it is the same case at Apple with xcode. Do OS engineers on MacOS actually use xcode to developer MacOS?
I'd blame web browser model for productivity problem we are having now.
Graphql was what made me hate Gatsby to be honest.
I think Typescript's websites uses it (or used to), and I wanted to fix a bug in the website and holy hell if Gatsby made me dislike the experience..
Even as a massive GraphQL fan, the GraphQL layer is what made me migrate all my projects away from Gatsby. It just doesn’t portray it at its best.
(just saying hey andrew! love to see you are still on the graphql train)
Astro is what I wanted and thought Gatsby would be. GraphQL was the wrong sized abstraction for a basic blog site like mine. And once Gatsby turned towards the cloud (which made sense as a business), everything just got so complicated. I was swept up by it too.
Cool insight on frontend ceilings -- deployment is king.
I think frontend tooling is valuable, but there’s so much good free out there that it’s hard to monetize.
Gatsby always seemed wildly overengineered to me. It’s like all the bad parts of react, with all the bad parts of complicated js tooling, and none of the upsides.
Never made sense.
> Frontend tooling isnt worth that much.
Is any tooling worth that much, really? I think the key is that backend tooling lends itself to selling hosted solutions, while frontend tooling is usually stuff you run locally or on CI to build artifacts. Sure, there are exceptions, but most people don't pay for developer-focused software anymore, at least not directly.
Sure. There are several companies selling paid JVMs and corpos gladly pay them a lot of money.
My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.
Remix is backed by Shopify, compared to Next.js being backed by Vercel. Does this influence any decision to take?
Today Next.js has a big advantage which is that they have already integrated most of the new React 19 rendering features and apis. I think it will take a while for Remix to catch up to that.
Other notable frameworks are community led Waku made by Daishi Kato from Pmdrs and TanStart made by Tanner from Tanstack.
Also there's Redwood.js betting on a more integrated experience.
Today I am using Nextjs because I don't think I can go back to not using RSCs, but when Remix catches up or Waku and TanStart get to v1, I sure will give them a serious try!
Shopify "backing it" means less to me than the maintainers themselves. The Remix maintainers are straight shooters and have been maintaining open source consistently for over a decade now.
I also just like their API and design decisions.
> Remix is backed by Shopify
This makes me distrust it (slightly more than I distrust Next/Vercel).
Shopify's core business is not in making javascript frameworks. Remix is always one bad Shopify away from being ejected.
> which will eventually just be React Router
how strongly do you believe this. because ive just read both docs and i think they have different goals/audiences (tho obviously same owner). i think react router will be a poorer project if it starts to require serverside components like it is looking
They made an announcement that they are merging the projects a little while back: https://remix.run/blog/merging-remix-and-react-router. Obviously things could change, but I think RR v7 will effectively be the next iteration of Remix.
ah yeah. they didnt quite address my concerns in that post. but they know better than i.
I'm a huge remix fan. Remix, Shadcn, postgres, and Prisma have been great for rapid development
Agreed, minus the Primsa.
Honestly, I hated Prisma for the longest time. Like, hated it. I tried to rip it out of projects multiple times. Why would you build a node library in Rust? (as one of many problems) But, I had a mental shift recently that helped me appreciate it more: I use Prisma only for features that fit neatly into an simple ORM (i.e. building a web page based on a bunch of joins). Anything else, I use raw SQL.
They released TypedSql (https://www.prisma.io/docs/orm/prisma-client/using-raw-sql/t...) which is heavily inspired by PgTyped. That lets me write raw Postgres SQL that's converted into TypeScript. The other things I do:
- If I want derived data, write views that encapsulate the transform. Prisma supports reading from views - If I need something more complex, use DuckDB + python for analysis and write to the appropriate table. - If I need to cache complex queries, just use a materialized view and read it as a prisma object
It's not perfect, but that let's me use prisma for what it's good at (Managing an ORM and deeply nested queries), then fall back into raw SQL for everything else.
Going straight to SQL has been a breath of fresh air, but, let's be honest, dealing with deeply nested joins really sucks when all you want to do is build a page that shows a company, all of it's people, and all of those people's relationships. ORMs are pretty handy for that last case, and I use SQL for everything else
Check out Kysley: https://kysely.dev/
I've looked into it a bit. I'm getting to the point where I either want to use a full ORM, or I want to write raw SQL and have it checked against the database.
Query builders are nice, but they sometimes end up in this middle ground where they have the worst parts of an ORM (needing to learn a new syntax and not getting access to all the DB features) and the worst parts of raw SQL (Unpacking relationships into objects w/ pointers is error prone boilerplate that sucks to write).
I love SqlAlchemy since it's still enough of an ORM to solve the main problem I want solved. Super curious to hear if you've had good experiences with Keysley and how it deals with transforming relationships into objects
Is Vercel a frontend tooling startup?
I've always seen them as a AWS-wrapping hosting company, who funds some react projects on the side and will drop them at a moment's notice.
Netlify, who bought Gatsby on its decline, still seems to be going alright without being a frontend tooling company.
> etlify, who bought Gatsby on its decline, still seems to be going alright without being a frontend tooling company.
what makes you so sure :/
I'm probably a bit out of the loop her - but you referenced Gatsby's collapse?
Did something happen to them, in the community or project?
Googling, I saw that they were acquired by Netlify in early 2023 - but not much concrete beyond that?
Astro is fantastic. I initially used NextJS with MDX, and something simple like using relative markdown links to images was utterly impossible.
I remember going down a day long rabbit hole to understand why, and it boiled down to content layer, MDX and NextJS using different, incompatible module loaders, bundlers or transpilers of some kind[1][2][3]. Ridiculous. And don’t get me started on the image component.
In the end, Astro just works. No need for React (unless you want it), it’s simple, fast and produces a static site you can use without JavaScript.
Data fetching is also utterly trivial, so you can have a fully static site with “live” data pulled in at compile time.
I recommend it to anyone with frontend fatigue.
1. https://stackoverflow.com/questions/63957018/how-to-use-imag...
2. https://mmazzarolo.com/blog/2023-07-30-nextjs-mdx-image-sour...
3. https://github.com/contentlayerdev/contentlayer/issues/11
Nice summary! Any guides you’d suggest for someone new to all of this, in terms of getting a simple blog set up with Astro?
The getting started docs[1] are really good, I’d recommend starting there for sure.
Basically you just run a few commands and you’ve got a website. Edit the Astro files to put HTML in, don’t worry about any JavaScript.
Then try adding a simple “site header” component and using that.
1. https://docs.astro.build/en/tutorial/1-setup/2/
I don't know if it has its place here but for a minimalist static website, here is my approach:
- create a simple html template using simple.css [0]
- write markdown files
- wrap pandoc [1] in a simple bash script to manually convert markdown to html
- and that's it.
By minimalist, I mean: no script, no component, no database, no react, no SEO.
The result is a minimalist website that you write in markdown.
It's very limited compared to full-featured frameworks, but it can do the job for a simple website.
Here is mine: [2] (I'm not a web developer at all).
[0] https://github.com/kevquirk/simple.css
[1] https://pandoc.org/
[2] https://remipch.github.io/
My personal website was originally written this way. The compile and build script was about 20 lines of shell scripting (relying on pandoc), and could have probably been reduced further. It worked very well and I stuck with it for about 2 years before moving on to Hugo. It was a good experience to hand-roll all the components of a static site, and something every web dev should be required to do early in their career.
Idk if I’d call my setup minimalist, but I write blog posts in org, and use ox-Hugo to export them to hugo.
I like hugo.
Good tempting language and taxonomy features.
[dead]
I quite like your philosophy and approach
I don’t love js/ts but Astro is so nice. Don’t have to fiddle with react or graphql. Just upgraded to 5 beta and nothing broke. Really well managed project. Oh, and page load speed is insane.
If you don't love js/ts maybe you'd like Civet, which transpiles to js/ts and has Astro integration. (No relationship, I've just been looking at it myself.)
https://civet.dev
This does look nice (as a functional programmer - Elixir, elm, etc and fan of coffeescript back before modern js). Even has pipes!
transpiling to JS that has if, if else structures instead of just early return if makes me not trust it (based on first "pattern matching" example on civet.dev site). I guess I have my prejudices.
Yeah they really nailed the developer experience. There is very little magic to it.
I have heard great things about astro, but my experience with Gatsby keeps me away. I would much rather keep an SSR framework like Remix and handle whatever pipeline is needed myself. No magic.
I felt the same way! But I came around. Take a look at the source code for a component [1]. The .astro format is pretty much just TS, CSS, and HTML. I don't even need React anymore. Way less glue code and dependencies than with Gatsby. There is a configuration file and some abstractions for things like collections, but almost everything is opt-in.
[1] https://github.com/jwngr/jwn.gr/blob/master/src/components/b...
It looks great, but that's a DSL I must learn and re-use nowhere else.
There's not really any DSL. You just put some TS in the frontmatter for fetching/transforming at build time, TS in a script tab (if needed) and the html is just basic templating that takes props.
Fully concur with the points you made. I also just finished transitioning my personal website to Astro from an Eleventy setup that I got too lazy to maintain. I made a couple of landing pages for clients and my own projects with Astro and the maintenance experience was eye-opening.
Astro really is quite wondrous. If you don't stray too far from its opinionated route, it's almost magical. But some more advanced things do still take some tinkering. My sitemap and RSS with full text setups I wouldn't describe as the most elegant things in existence, but they do their job.
What I'm still lacking/wondering about is whether there's a CDN static site/serverless hosting provider like Netlify, Vercel or Cloudflare, but that isn't free or $20/mo. I'd like to pay for a good service that obviously has running costs, but I don't believe there's quite something like those.
Anyway, I like the website. It's easy on the eyes.
Thanks for sharing! I use Fireabse Hosting, which I guess gets grouped in with the other services you mentioned. It's free, has a lightweight devX, and integrates with CI via GitHub actions for preview and production builds [1].
[1] https://github.com/jwngr/jwn.gr/tree/master/.github/workflow...
Right, I didn't consider Google. The 360MB/day of free egress traffic (Spark plan) strike me as very peculiar. But at least it isn't Cloudflare's "unlimited" with secret limits in place, or Netlify's 100GB/month and then enormous costs on everything above.
Thanks for reminding me! I'll give Firebase a look.
By the way, very minor thing I noticed. Clicking on your photo on the homepage swaps backgrounds, but the timer-based swapping still runs on its fixed interval. Can look unpolished if you click it a bunch or in the wrong moment.
Oh, thanks for letting me know! Looks like I'm not properly clearing the interval. I'll get that fixed.
This looks lovely! I've been recently working on sth similar: building a custom pipeline from my Obsidian notes into a website (untested.sonnet.io).
I ended up using 11ty because I wanted to stick as close to the web platform as possible, but a part of me wishes I had tried Astro as well. Mainly because I feel that it strikes the right balance when it comes to flexibility and boilerplate. 11ty is lovely, but there was soooo much stuff I had to write from scratch. I feel like it paid off, but it took me much longer than I had hoped.
One surprising side effect: I noticed that the site worked faster online than served from localhost. 5 minutes of digging after I remembered that it's served via HTTP2 w. multiplexing. I'm not even interested in adding a bundler/minify step, just plain CSS/HTML and asset optimisation w. 11ty-image is enough.
Plus one for eleventy. Love its minimalism and flexibility, although it means that there isn't a clear guidance on assets management. It's a shame that the web still doesn't have a standard way of authoring components, and different frameworks and static-site generators, including eleventy, have to invent their own.
OK, so 11ty webc is pretty good and feels relatively low on abstraction. The only issue I've had with it was the developer UX (e.g. some components getting "stuck" during livereload, so I needed to manually restart 11ty to see the changes). Webc also supports bundles.
What 11ty lacks (assuming I don't add vite, keep things minimal), are components/composition, i.e. actually being able to compose templates without seeing them as templates but as DOM.
I recommend checking out some videos about .webc and progressive enhancement, there's a small paradigm shift from both React-like components map to a tree that maps to pixels and a more traditional old timey PHP-like string interpolation in templates. (I'm expressing this poorly as I'm in a rush, sorry!)
I missed out on hugo, gatsby and astro. Using 16 year old Jekyll in its fresh breath 4.3.4 manifestation from 2 weeks ago.
I hear that last comment, default export was a mistake IMO. named is just so much clearer especially refactoring.
~4 years ago, redesign phase of our 50K a month public facing wordpress NGO website, agency strongly suggests moving to gatsby. We/I thought about it for 5 minutes and said no. I am still happy with that decision and I will push to take the same if/when another agency comes at us with Astro. Node CMS are autophagous.
Astro is great. I love that I can mix and match between markdown, plain HTML, and Svelte components as needed (and even intermix them within a page). Pretty much the sweet spot I always wanted for a blog or marketing site: 98% static stuff, 2% sprinkles of JS.
In early experiments it feels like Inertia.js be this same feeling but for Rails and Laravel.
I never got very far on the Gatsby train. It always felt so slow and fragile during local dev, and while GraphQL was cool it felt like total overkill for most of the data I needed to grab (like… markdown files from disk).
Cannot use React UI lib with Astro such as Mantine. With Gatsby it was possible.
Astro is MPA while Gatsby provided SPA-like navigation.
That's why Astro is not really a replacement.
Not a full replacement in all scenarios. But for my personal website with a basic blog, Astro is by far the simpler and more maintainable option. I bet that is true for most people here who maintain their own personal website.
This is a bit misleading. You are only prevented from using UI libs that use a Provider/Context (like Mantine does) since Astro does not support Context.
Things like shadcn/ui work fine, even when statically rendered.
You could just slap on any library like Swup.js, Turbo, etc. and get SPA-like fast navigation out of a regular "MPA" Astro site. And that's true for any MPA, actually.
In addition, I believe Astro now has their own solution for this, though I haven't tried it personally: https://docs.astro.build/en/guides/view-transitions/
You can achieve SPA-like navigation in Astro with their transitions API, but if that’s what you’re after it’s better to use Next.js or Remix IMO.
(I helped build playboy.com/magazine with Astro, which uses the transitions API for this SPA-like behavior… as well as playboy.com/app (nsfw) with Next.js)
I spent the entire time building a business network platform with Astro instead of WordPress or other web frameworks because it is exactly what I need to easily manage UI components and provide a safer JSX-like environment.
In comparison to Ruby on Rails, Django, and Laravel, Astro stands on the same level but much less learning curve.
Astro is a step in the right direction. But I wonder why in 2024 we still have to deal with proprietary component languages? I would like something like Astro with web components. Perhaps with the help of lit. With this the pure markdown content could be easily enriched with components.
This is my dream also. I much much prefer lit-html syntax to Astro’s.
I even found standard declarative shadow dom style components to be a pain in the ass in Astro which left a bad taste in my mouth since that’s literally just stock standard HTML.
Astro is amazing! I use it for all my blogs, my personal website, and some of my landing pages (info in about).
It’s very easy to build a static website with zero js, or pick the desired framework you want to work with.
Pair it with TypeScript and you get almost 100% type safe templating and resulting websites.
> Astro is designed as a Multi-Page Application (MPA) by default, shipping minimal JavaScript and delivering static HTML via full page reloads.
So...a website. weary emoji
This is my feeling too. I’m never sure why React is the tool that is reached for in this situations (an entirely unreactive page?)
Great write up, will be curious to see if Astro sticks around. It seems like all the static site gens last a few years then fade away - Jekyll, Hugo, Gatsby, etc.
Me too! The closer my framework is to raw HTML, JavaScript (really TypeScript nowadays), and CSS, the less lock-in I feel. Those 3 languages are continue to get better year over year. And we are get better framework abstractions every few years too. Astro feels like it hit the sweet spot, but maybe there is more to come.
if you keep your site on github, i found keystatic to be a really nice authoring experience: https://github.com/Thinkmill/keystatic
Thanks for the link. I prefer the simplicity of .mdx files for now. My use case is very basic and Astro already handles it well.
keystatic supports editing mdx files. keystatic is basically a frontend to update files on github, so if e.g. you want to write a blog post from your phone it can let you do that kind of thing.
Oh cool, I see. Didn't get that impression when I first looked. I will check it out!
Gatsby gets shit on a lot - which I think is a but unfair. I find it to be a solid, well-documented platform. It has some rough spots, but show me a platform that doesn't.
The author also complains that:
> I couldn’t build the site locally or upgrade dependencies, leaving it outdated since 2019
This is true of many things in the javascript ecosystem. In react/node/js-land you HAVE to invest in maintenance (and re-writes) or be left with a legacy codebase that just might not work one day if npm install fails.