[HN Gopher] From Gatsby gridlock to Astro bliss: my personal sit...
___________________________________________________________________
From Gatsby gridlock to Astro bliss: my personal site redesign
Author : jwngr
Score : 96 points
Date : 2024-09-26 17:47 UTC (5 hours ago)
(HTM) web link (jwn.gr)
(TXT) w3m dump (jwn.gr)
| schpet wrote:
| if you keep your site on github, i found keystatic to be a really
| nice authoring experience: https://github.com/Thinkmill/keystatic
| jwngr wrote:
| 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.
| schpet wrote:
| 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.
| jwngr wrote:
| Oh cool, I see. Didn't get that impression when I first
| looked. I will check it out!
| cpursley wrote:
| 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.
| jwngr wrote:
| Yeah they really nailed the developer experience. There is very
| little magic to it.
| garyrob wrote:
| 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
| cpursley wrote:
| This does look nice (as a functional programmer - Elixir,
| elm, etc and fan of coffeescript back before modern js). Even
| has pipes!
| bryanrasmussen wrote:
| 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.
| abeisgreat wrote:
| 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.
| jwngr wrote:
| 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.
| swyx wrote:
| 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.
| epolanski wrote:
| 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..
| andrewingram wrote:
| 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.
| jwngr wrote:
| 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.
| mmckelvy wrote:
| 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.
| swyx wrote:
| > 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
| mmckelvy wrote:
| 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.
| swyx wrote:
| ah yeah. they didnt quite address my concerns in that
| post. but they know better than i.
| mind-blight wrote:
| I'm a huge remix fan. Remix, Shadcn, postgres, and Prisma
| have been great for rapid development
| soufianee wrote:
| 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!
| madeofpalk wrote:
| > 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.
| vladgur wrote:
| 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
| swyx wrote:
| we do live in a society
| com2kid wrote:
| > 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.
| swyx wrote:
| 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.
| com2kid wrote:
| > 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?
| MikeTheGreat wrote:
| > 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
| skeeter2020 wrote:
| we used it for a highly interactive scheduler UI in a
| commercial software project. The appeal was do Flash
| development with .Net developers.
| mirchiseth wrote:
| SAP used it for their CRM when they moved from desktop
| client to browser based clients.
| com2kid wrote:
| 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.
| neonsunset wrote:
| 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
| yen223 wrote:
| 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.
| dartos wrote:
| 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.
| madeofpalk wrote:
| 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.
| dimitrisnl wrote:
| 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.
| jwngr wrote:
| 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...
| dimitrisnl wrote:
| It looks great, but that's a DSL I must learn and re-use
| nowhere else.
| cpursley wrote:
| 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.
| ulrischa wrote:
| 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.
| mdhb wrote:
| 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.
| toinewx wrote:
| 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.
| jwngr wrote:
| 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.
| jaredcwhite wrote:
| 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/
| cmgriffing wrote:
| 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.
| kcrwfrd_ wrote:
| 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 with Next.js)
| dceddia wrote:
| 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).
| rpastuszak wrote:
| 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.
| azangru wrote:
| 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.
| skwee357 wrote:
| 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.
| orf wrote:
| 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
| indigodaddy wrote:
| 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?
| orf wrote:
| 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/
| remipch wrote:
| 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/
| syndicatedjelly wrote:
| 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.
| indigodaddy wrote:
| I quite like your philosophy and approach
| dartos wrote:
| 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.
| todotask wrote:
| 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.
| jama_ wrote:
| 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.
| jwngr wrote:
| 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...
| jama_ wrote:
| 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.
| jwngr wrote:
| Oh, thanks for letting me know! Looks like I'm not properly
| clearing the interval. I'll get that fixed.
| SrslyJosh wrote:
| > 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_
___________________________________________________________________
(page generated 2024-09-26 23:01 UTC)