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.
It was truly a testament of times
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.
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.
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?
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.
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..
Cool insight on frontend ceilings -- deployment is king.
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.
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.
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!
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
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.
what makes you so sure :/
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?
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
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.
- 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).
I like hugo.
Good tempting language and taxonomy features.
[1] https://github.com/jwngr/jwn.gr/blob/master/src/components/b...
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.
[1] https://github.com/jwngr/jwn.gr/tree/master/.github/workflow...
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.
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.
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!)
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).
Astro is MPA while Gatsby provided SPA-like navigation.
That's why Astro is not really a replacement.
Things like shadcn/ui work fine, even when statically rendered.
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/
(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)
In comparison to Ruby on Rails, Django, and Laravel, Astro stands on the same level but much less learning curve.
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.
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.
So...a website. weary emoji
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.
