[HN Gopher] Astro 1.0 - a web framework for building fast, conte...
___________________________________________________________________
Astro 1.0 - a web framework for building fast, content-focused
websites
Author : danielskogly
Score : 216 points
Date : 2022-08-09 17:41 UTC (5 hours ago)
(HTM) web link (astro.build)
(TXT) w3m dump (astro.build)
| shodan757 wrote:
| Not to be "that guy", but could you please put the language in
| the title when posting stuff like this? We all have our language
| preferences, and I'd rather not have to go digging just to figure
| out if a project is relevant to me.
| SamBam wrote:
| It says it's a "web framework" in the title. That generally
| means it's going to have some kind of templating system, plus
| html, css, JavaScript, and probably support for other things
| like markdown and json. Which of these did you want in the
| title?
|
| Or if you mean what was astro itself written in, I think this
| post is aimed at _users_ of the system, not potential
| contributors. Personally I dislike it when when a post says
| something like "Hugo, a static site generator (Golang)"
| because it incorrectly implies you need to write Go in order to
| develop with it.
| yoyohello13 wrote:
| When I see "web framework" I think Phoenix, Django, Spring,
| etc. Which do all require you to write in the associated
| language. If you said "Static Site Generator" then yes that
| doesn't imply you need write in a specific language.
| jsdevtom wrote:
| We've built multiple websites with Astro.js, including customer
| facing ones such as bustinger.com, and love it.
|
| Simple to use, blazing fast results. JSX. Use another framework
| you like inside it (e.g. React, svelte).
| cube2222 wrote:
| This look very cool overall!
|
| Could you please explain the tradeoffs vs tools like Hugo and
| Docusaurus?
| brycewray wrote:
| https://docs.astro.build/en/comparing-astro-vs-other-tools/
| fareesh wrote:
| I used a static site generator for all of these benefits in the
| past, but the rebuilding process is a total nightmare.
|
| The site has about 20 categories, and each category has about 100
| images. Every time the team adds a new image or category, the
| deployment/building task clones the repo and then the build
| process generates all the optimally sized images again and then
| re-uploads multiple gigabytes to the host. Is there a way around
| this type of problem with static site generators?
| naet wrote:
| You might need ISR (incremental static regeneration). IIRC
| there are a couple standard SSG frameworks that support
| something like it. Usually only worth investing in if you are
| operating at a large enough content scale though.
| butz wrote:
| Offload image optimization to separate service?
| biztos wrote:
| > What People are Saying
|
| > Astro works with the tools you already love, but this requires
| a lot of effort to get right. Luckily, Astro is supported by some
| amazing partners across the industry who support our vision for a
| faster web.
|
| Fast/easy content-focused websites are a subject dear to my heart
| but far from my day-jobs, so I'm always happy to hear about
| people making the thing I never quite finish making.
|
| But the above quote is... weird?
|
| The first thing "people" are saying about Astro is it's a pain in
| the butt, however "luckily" you can spend money on companies to
| make it less so?
| rcarr wrote:
| Been using this the last week to convert an 11ty website and
| really enjoying it so far. Very cool to just be able to use
| whatever JS framework you want for a component and just drop it
| in.
| ryansolid wrote:
| So excited for this. SSR with Astro is a gamechanger which opens
| up its usage to so many different avenues. Great strides with
| framework interop too. Named Slots really closing the gaps.
|
| And of course any framework where SolidJS can shine so bright is
| going to be the top of my list.
|
| Congratulations on an amazing release.
| oxff wrote:
| Why does it feel like there are million solutions and wheel
| reinventions like this. Why can't they converge on 1-2 solutions?
| jaywalk wrote:
| https://xkcd.com/927/
| jlarky2012 wrote:
| Congrats guys. Astro+SolidJS is the future :)
| avivo wrote:
| I'm curious if Astro supports git-backed visual editing? I can't
| seem to find that, but it would rather useful if so! (ala
| tinacms.io , stackbit, etc.)
| gherkinnn wrote:
| Excited to see where this goes. For me it fills the niche of
| simple md -> html with lots of room to expand.
|
| I like working with TS, JSX is fab, and I never enjoyed Hugo or
| Jekyl. Next.js is nice but too much for this case. Gatsby is not
| nice and doesn't do much. Astro sounds just about right.
| CharlesW wrote:
| I'm looking at https://docs.astro.build/en/concepts/why-astro/
| and I still can't tell what's interesting and unique about this
| as compared to other options in this space.
|
| I acknowledge that this might be a PEBKAC situation, but I'd love
| to hear thoughts from people who used Next.js, Remix, or whatever
| and found Astro to be a revelation.
|
| It seems like Astro's creators believe "content-focused" is a
| differentiator, but I find that confusing since content-focused
| sites are a popular use case for web frameworks that are also
| suitable for more complex apps.
| ggregoire wrote:
| The core concept and main difference is described here I think:
| https://docs.astro.build/en/concepts/islands
|
| There is also this page comparing it with other tools:
| https://docs.astro.build/en/comparing-astro-vs-other-tools
| sesm wrote:
| Comparison with alternative solutions is the first thing I
| look for in the docs. Great that they have it!
| eKIK wrote:
| While Astro has a lot of impressive features I found that it
| was the "developer experience" (god I hate that term) that was
| superior compared to everything I've tried before.
|
| With Hugo and Jekyll I always needed to go revisit the docs
| whenever I hadn't worked with it for a while. I never got to
| the "oh, I get this tool now" phase, where the content
| generation could just flow without issues.
|
| Publii was cool, but trying to shoehorn everything into fitting
| in the "Blog" model never quite worked out for me. Also being
| forced to work in a new IDE wasn't to my liking either.
|
| Here are some of the things I love about Astro:
|
| - The docs are great. You can read through them all really
| quickly. I tend to prefer systems that are simple to grok, and
| Astro is just that.
|
| - The lightweight Astro components
| (https://docs.astro.build/en/core-concepts/astro-components/)
| were great for me, because they delivered on being able to
| create reusable pieces of code very easily (without having to
| touch React).
|
| - Being able to generate part of your site from markdown and
| part of it from precisely crafted HTML is a great way to be
| able to handle both repetitive and unique content.
|
| - The Astro themes (https://astro.build/themes/) are a great
| way to start. Find something that's somewhat similar to what
| you want to build and study how they did it.
|
| This is obviously very subjective, but for me Astro was the
| first SSG that I really enjoy using, and that I didn't feel
| like I had to fight against.
| vosper wrote:
| > "developer experience" (god I hate that term)
|
| Why do you hate it? It's useful to have a term to
| differentiate between the experience of the person using the
| output of the tool (user experience) versus that of the
| people developing with the tool (developer experience).
|
| Honestly we need more DX improvements in this industry.
| Especially look at DevOps - the user experience of Chef's
| output (I'm picking on Chef here, it's hardly the only
| offender) is servers and services, and the users (other
| engineers) consuming those outputs can have a nice time. The
| DX of using Chef, though, can be ughh....
| jackconsidine wrote:
| For me it's the pre-rendering. I've used Next.js, Nuxt.js,
| Remix etc and they all _server-render_ great. But for deploying
| SPAs to file-hosting (S3 + Cloud Front or Firebase Hosting)
| without a server runtime, you end up with empty HTML on request
| which is worse for SEO, social previews etc. There are
| solutions to pre-rendering for these stacks but they 're more
| focused on deploying to Vercel or Netlify functions, or having
| a post-build script which opens the site in Puppeteer and saves
| the HTML into your build file! With Astro, all this is out of
| the box immediately. Try putting together an Astro site and
| look in your build directory; you'll see even for React
| components the HTML is already there
| ta-run wrote:
| I can just do a `nuxt generate` and put it on CF+S3 as well,
| right? how is that any different to what Astro does?
| nawgz wrote:
| Looks the same to me after a quick read as someone who has
| never used an SSG BEFORE
| azangru wrote:
| As far as I can tell, Astro is zero-js on the client by
| default, while both Next and Remix are very much the opposite.
|
| Plus, both Next and Remix are tightly coupled with React,
| whereas Astro is trying to be more agnostic in that regard.
| dirheist wrote:
| The one thing I like about Astro is the component island UI.
| With react you would need to re-render the entire UI on a UI
| change while in Astro you can signify which portions of your
| website are static and which dynamically should re-render upon
| data fetching or whatever.
|
| It's just a faster way to build UI's that don't need the full
| complexity of a SPA and also don't need to come bundled with
| the entirety of react from what I've seen and used it for.
| GrahamL wrote:
| It's interesting their blog post doesn't mention some of the
| benefits. Neither does the doc page you linked--at least it
| doesn't do it succinctly.
|
| Essentially Astro lets you build sites using a JS framework
| like React or Vue without requiring that framework to be loaded
| on the frontend. By default, components are just HTML content.
| Super nice for building very fast static sites using a
| technology you may already be fluent in.
|
| You can still add interactivity to components if you'd like--
| just tag components that require interactivity and Astro will
| bundle the requisite JS for the client.
| tannhaeuser wrote:
| Not getting it tbh. Why would you go nuclear and develop a
| React or Vue app and then not actually use it on the browser
| side? For content-oriented websites there are much simpler
| workflows based on SGML and other classic markup processing
| and content management practices. I mean the point of
| "content-oriented" and web sites in general really is that an
| expert in the field, rather than a web developer, can achieve
| useful results as an author.
| cercatrova wrote:
| Developer experience writing React is much nicer than using
| other markup languages. That's why I use it at least, the
| fact that it spits out a fully JS-free website at the end
| is the icing on the top.
| chasingtheflow wrote:
| You get the speed of SSR but can sprinkle interactivity
| into the app using the same SPA style frameworks via
| isolated "islands".
| reilly3000 wrote:
| Their homepage https://astro.build has a nice summary of its
| approach and benefits.
| ksec wrote:
| So they have moved all the previously frontend stuff to
| backend and output Hot-wired / Liveview / Livewire instead?
| mwcampbell wrote:
| I wish. AFAIK it's just classic server-side rendering with
| full-page navigation. Mind you, that's the optimal solution
| in many cases. But a full-stack JavaScript web framework
| with something like Phoenix's channels and LiveView built
| in would be a killer combination.
| Existenceblinks wrote:
| > using a technology you may already be fluent in.
|
| I think this is the only selling point, given the "content-
| focused". It's not different than just writing HTML and
| vanilla js for some interactivity.
| qbasic_forever wrote:
| If you look at the project structure it uses that might help
| make it more clear the capabilities:
| https://docs.astro.build/en/core-concepts/project-structure/
| Content-focused seems to highlight that you can just dump
| markdown files into it and spit out rendered pages, very much
| like content focused static site generators (hugo, jekyll,
| etc.). But in addition to that static content it has all kinds
| of hooks and capabilities to add dynamic components or even
| pages, kind of like more modern web application platforms like
| next.js.
| gavinray wrote:
| Serious question: Why does Astro need a custom file format?
|
| The format looks identical to MDX
| MatthewPhillips wrote:
| It uses it to know what JS is needed for the client. If it sees
| <Section /> that means that no-JS is needed. But if it sees
| <Counter client:load /> it knows to build + bundle the Counter
| component and attach its JS to the page.
| gavinray wrote:
| That's just a property on an element tag, you can access
| "client:load" under the ".properties" key of the element
|
| Open your browser devtools, pick a random tag on the page,
| add "client:load" to it, and then
| "console.log(yourEl.properties)"
|
| I dunno why you need an entire custom filetype for behavior
| and semantics that are MDX with a few extra preprocessor
| rules
| MatthewPhillips wrote:
| The reason why you don't know is that you've decided in
| advance that it's not actually needed.
|
| .astro is not actually like MDX at all. MDX extends
| Markdown, Astro does not, it extends HTML. MDX is a variant
| of JSX, Astro is not, it supports things that JSX does not
| like void elements. Astro supports text inside of script
| and style tags, JSX does not.
|
| If you think you can rebuild Astro with "a few extra
| preprocessor rules", then by all means go for it. But
| you're going to fail.
| swyx wrote:
| it -is- MDX https://www.brycewray.com/posts/2022/07/astro-move-
| to-mdx/
| gavinray wrote:
| Then it's just for vanity, lol?
| brycewray wrote:
| No, `.astro` is more than that. What I wrote about was their
| emphasizing MDX rather than generic Markdown.
| dfabulich wrote:
| Here's the link to their "Astro vs. X" page.
| https://docs.astro.build/en/comparing-astro-vs-other-tools/
|
| They compare Astro to Docusaurus, Elder.js, Eleventy, Gatsby,
| Hugo, Jekyll, SvelteKit, Next.js, Nuxt, Remix, VuePress, and
| Zola.
|
| (For some reason, this page doesn't appear linked anywhere from
| their documentation's table of contents, and isn't even linked
| from the "Why Astro?" page. It's almost like they're trying to
| hide it or something!)
|
| https://docs.astro.build/en/concepts/why-astro/
| robertakarobin wrote:
| After having tried and given up on so, so many SSG frameworks,
| I'm loving Astro. In particular:
|
| - Templates are plain HTML/Javascript, instead of some other
| templating language (e.g. Jekyll/Liquid)
|
| - Typescript out of the box
|
| - SCSS out of the box
|
| - Easy remote builds on Netlify
|
| - Scoped stylesheets
|
| - No overcomplicated build process/customization (e.g. Webpack)
|
| - Supports Markdown, YAML, JSON, all the things
|
| - It builds really quickly
|
| And all of that is with virtually no additional configuration.
| It's great.
|
| Also a big bonus: the team is super friendly and very responsive!
| vosper wrote:
| Also out of the box:
|
| - Tailwind support
|
| - Optional choice of UI framework (React, SolidJS, Svelte
| etc...)
|
| - Partial hydration. Generates _actual HTML_ on the server-side
| rather than JS blobs (which is what some other frameworks call
| SSR).
|
| It really does work nicely. It's very fast, minimal config
| required.
| sbarre wrote:
| As someone who started building web pages in the 90s, the
| "islands architecture" (generating HTML server-side) of Astro
| and others makes me laugh because it's literally what we used
| to do with XMLHttpRequest in IE 5/6 20+ years ago.
|
| We generated page partials (or used static ones) and pulled
| them in with "Ajax" (for the oldies out there) and then
| inserted them in the right place on the page using innerHTML.
|
| There's nothing wrong with this coming back around, it worked
| quite well!
|
| It's just amusing how some things come full circle and are
| now considered innovative again. I'm sure there are
| advancements under the hood of course.
| tomnipotent wrote:
| And before Ajax you could use a hidden iframe and update
| the parent page with some JS.
| ijustwanttovote wrote:
| If you are trying to "flip" websites, SSG isn't the way to go. I
| created websites with my own SSG using Javascript, Eleventy,
| Nuxt, Next.
|
| But when I create a website now, I got to stick with Wordpress
| because they are easier to sell and non tech people can use it.
| [deleted]
| swyx wrote:
| congrats team on 1.0!!! huge milestone!
|
| inevitable question that always can use answering - what can you
| share about Astro's company business plan/business model at this
| time?
| mwcampbell wrote:
| > If your project falls into the second "application" camp, Astro
| might not be the right choice for your project...
|
| Plenty of applications in the second category (logged-in admin
| dashboards, to-do lists, etc.) have been developed using server-
| first frameworks, and some of us still prefer to develop web
| applications that way. Is Astro missing any key features for
| dynamic server-first applications, e.g. form submission and
| validation support? If not, I think the Astro developers might be
| selling Astro and MPAs short.
| eyelidlessness wrote:
| I agree some of their examples aren't great, but I think what
| they're saying is that Astro's benefits become less relevant
| for apps which are highly interactive in the client. You can
| certainly use Astro to build those, but in many cases you may
| be just as well served (if not better) by using a more
| established tool oriented toward whichever client
| framework/libraries you choose (eg Next.js or Nuxt or SvelteKit
| etc).
|
| That said, there's quite a lot of space between that extreme
| and the mostly-static "web site" extreme, and I agree Astro
| would be a better fit than they let on, for a large chunk of
| that space. My suspicion is that this is intentional, to keep
| their current focus and explicit use-case commitments narrower.
| And I wouldn't expect it to remain that narrow in the future.
| [deleted]
| scastiel wrote:
| Very nice! I was thinking about migrating my blog which has been
| running with Eleventy for the past few years. It might be the
| perfect opportunity :)
| azangru wrote:
| What do you find missing in Eleventy?
| scastiel wrote:
| To be honest, I miss React :)
| lloydatkinson wrote:
| You will definitely like Astro then! I wrote an article on
| using (P)react and Astro if you're interested!
| https://www.lloydatkinson.net/posts/2022/writing-a-fuzzy-
| sea...
| recroad wrote:
| Provide and migration path from Wordpress and I'm in!
| knowsuchagency wrote:
| How does Astro compare to QWIK
| https://qwik.builder.io/docs/overview ? Has anyone tried using
| both? It seems like they're both attempting to address the
| hydration problem from different angles
| stoicjumbotron wrote:
| Really excited for this release!
| oneplane wrote:
| Sometimes all the frameworks that re-invent MVC (but in a
| detached fashion) and tout "server side rendering" just feel like
| we've come full circle where we're just serving a static view
| cache that was generated from models and data using a controller.
|
| The big difference here (as with other JavaScript-based
| renderers) is of course the "use one tool/language for
| everything" aspect which to me is a bit of a 'meh'-benefit.
|
| At this point, while all the renderers get better and simpler,
| we're still in a situation where complexity or writing code
| hasn't really gone away, it just shifted around to new places.
| Perhaps at some point we get to the HTML + WebComponents stage
| again (kinda like MDX and React mixing), and classic Apache
| Server-Side Includes become the new hot thing again.
| thwrowaway wrote:
| It provides themes; as does Next.js/Versel, mui, etc. Are
| seasoned developers usually forking from these provided designs?
| What value do you guys ascribe to provided themes?
| itcrowd wrote:
| It always annoys me when I read something like:
| To try Astro on your local machine, run npm create astro@latest
| in any terminal.
|
| because it doesn't make it clear to me what to do before this
| command will actually do anything. No, running this command will
| _not work_ in any terminal.
| ksbrooksjr wrote:
| As long as you have npm installed it'll work. Npm create is an
| alias for the npm init command [1], which will look for a
| package with the prefix 'create-', install it, and run its bin
| file. It looks like this is the file that ends up being run: ht
| tps://github.com/withastro/astro/blob/main/packages/create....
|
| [1] https://docs.npmjs.com/cli/v8/commands/npm-init
| itcrowd wrote:
| > As long as you have npm installed it'll work.
|
| Exactly proving my original point.
| ksbrooksjr wrote:
| Well obviously you'll need npm to use a command that begins
| with npm. If someone gave you a terminal command to run
| that begins with curl, you'd be expected to have curl
| installed. This seems like pure pedantry.
|
| Take a look for example at the rust installation steps [1].
| They tell you to run the following command in your
| terminal: "curl --proto '=https' --tlsv1.2 -sSf
| https://sh.rustup.rs | sh". They don't tell you to first
| make sure you have curl installed (or sh for that matter).
|
| [1] https://www.rust-lang.org/learn/get-started
| brabel wrote:
| If you don't have npm installed, just stay as far as you
| can from this :D
|
| Seriously, JS static website generators are the worst...
| use something written in any compiled language so you just
| download and run a single binary, no messing around with
| npm and millions of dependencies.
|
| Take your pick here: https://jamstack.org/generators/
| azangru wrote:
| > in any terminal
|
| I agree; the "in any terminal" part is paternalistically
| redundant - any software developer who recognizes the npm
| command will know what to do with it.
| WorldMaker wrote:
| Because it is written in JS it assumes you have NodeJS
| installed. npm is the package manager bundled in with NodeJS.
| akmittal wrote:
| Can anyone explain if it's replacement of Next/remix to build
| complex sites or more like a SSG?
| azangru wrote:
| I believe the most complex use case they are targeting is an
| ecommerce site. Definitely not something as client-side-heavy
| as, say, Excalidraw, etc.
| pier25 wrote:
| It started as SSG only but they added SSR so yeah they're now
| in the same space as Next, Remix, SvelteKit, etc.
|
| In fact Solid's creator has said Astro is probably the best way
| to do SSR with it.
| j-pb wrote:
| Really interesting stuff especially for existing jam stack
| websites, but oh god
|
| > This vision of a better web is why Netlify is bullish on Astro
|
| can't this horrible stock market and crypto bro lingo stay in the
| casino bubble.
| lloydatkinson wrote:
| It's a really great tool I've been using since last year. I had
| previously attempted using Nuxt but that's a real mess and I
| never actually got to writing anything. Now I'm using Astro and
| I've got a few articles and it's a really pleasant developer
| experience. A lot of static site generators I have found needed
| more time configuring and writing code for leaving less time in
| the day for posts etc. I haven't found this with Astro.
|
| The ability to totally not send any JS at all apart from what you
| manually add such as framework specific components is really
| something.
| pembrook wrote:
| Is there a static site generator out there that doesn't require a
| ridiculous build process every time I do an update?
|
| Inevitably, when a new "hot" SSG comes on the scene, I try it,
| and then go back to compare it to the old "hot" SSG from 2 years
| ago. Yet, I can never get the old test site I set up running
| again without massive annoyances. This has happened multiple
| times.
|
| As far as I'm concerned, there's zero reason your landing pages
| and blog should require 3,000 dependencies to run.
|
| And like all SSGs, I see no mention of sane SEO defaults on the
| homepage. Let me guess--with Astro I'm going to have to set all
| of this up myself?
| jutanium wrote:
| Astro is that tool. It can output a server that can react
| immediately every time you do an update.
| onion2k wrote:
| _Yet, I can never get the old test site I set up running again
| without massive annoyances. This has happened multiple times._
|
| Pin your dependency versions and never suffer this problem
| again! Shrink-wrap your node modules and don't even download
| them again! Use Yarn's offline cache to share package tarballs
| between applications to save on disk space!
|
| There are many options for this problem. And that's just in the
| JS ecosystem. Use something Ruby or Go based and it's even
| better.
|
| _As far as I 'm concerned, there's zero reason your landing
| pages and blog should require 3,000 dependencies to run._
|
| Except there really, really is. A static site generator is
| really an optimizing compiler for 4 or 5 different languages
| (html, css, js, markdown, a template language, etc), with a
| build tool chain, and often image optimization, and a server
| for dev, and usually some sort of semi-opinionated structure
| that scans a directory tree and magically turns that into
| something you can just throw up to a web server and have a
| working website. They're complex systems pretending to be
| "simple and easy" because the output is essentially HTML with a
| few whistles.
|
| You certainly can build a site generator with far less code,
| but when people want a lot of flexibility just by tweaking a
| JSON config file that necessitates complexity. And in JS, that
| means more packages.
|
| The beauty of tooling is that there are lots of alternatives if
| you feel you want to optimize for dependencies instead.
| ARandomerDude wrote:
| I've been on the same Middleman template and pinned gemfile for
| 6 years now, with multiple production sites.
|
| If you don't want the trouble, don't chase the new hotness. Use
| what works until there's a compelling reason to switch.
| lucideer wrote:
| Repeating the Hugo recommendation.
|
| 1. I've not yet had issues building old sites
|
| 2. Just in case you anticipate such issues you can just check
| the binary into your repo
| rsolva wrote:
| > Is there a static site generator out there that doesn't
| require a ridiculous build process every time I do an update?
|
| I am experimenting with Caddy's template functionality [0] in
| my pursuit of making dependency-free and buildless websites.
| Caddy's templates are inspired by the Server Side Include (SSI)
| functionality in Apache and Nginx, except it uses Golang's
| syntax. I have made several websites in Hugo and find it
| pleasantly similar, only more bear-bones.
|
| Although Caddy is serving static sites to the browser, it is
| technically more like using a dynamic scripting language like
| PHP on the server. I guess Caddy templates outperform PHP by a
| large margin because it is written in Golang and compiled, but
| I have never tested this hypothesis.
|
| Funfact: Caddy's entire website is written with Caddy's
| template system and the source code is available [1] for those
| who want to take a look!
|
| [0]
| https://caddyserver.com/docs/modules/http.handlers.templates
|
| [1] https://github.com/caddyserver/website
| francislavoie wrote:
| To add onto this, we recently added plugin support for
| templates, so you can write your own template functions if
| you'd like! https://github.com/caddyserver/caddy/pull/4757
| infogulch wrote:
| Have you considered adding WASM / WAGI support?
| francislavoie wrote:
| Not really; it's already really easy to write plugins for
| Caddy in Go, so we haven't really seen the need. See
| here: https://caddyserver.com/docs/extending-caddy
|
| You could write your own plugin that calls out to your
| WASM layer if you want, but I'm not sure we need that
| built into Caddy. It would be extremely niche, I think.
| game-of-throws wrote:
| Use any SSG not written in javascript and you'll be fine. Hugo,
| Zola, Jekyll, etc. Though if I was starting from scratch I
| might avoid Jekyll just because of the Ruby dependency.
| gglitch wrote:
| Honest q: what's the problem with Ruby? Compile time? Gem
| management? I'm using Jekyll and sometimes wonder if I'm
| missing anything from the newer systems. My compile time is
| negligible, and once I figured out how to integrate Tailwind,
| I've had no issues.
| root_axis wrote:
| > _Use any SSG not written in javascript and you 'll be
| fine._
|
| Commonly stated but not actually true. For example:
|
| https://github.com/getzola/zola/blob/master/Cargo.lock
|
| https://github.com/gohugoio/hugo (scroll to the bottom of the
| README)
| IceWreck wrote:
| You don't need these deps to install it, just to compile
| it.
| weego wrote:
| To be fair in every day use Hugo is a single very portable
| binary
| procombo wrote:
| This. Makes everything so smooth. Serverless cloud
| providers love it too. (Cloudflare Pages, etc.)
| skrtskrt wrote:
| Yeah Hugo has the advantage that dep management for Go is
| 10000x simpler than JS, Ruby, Python, etc., particularly
| when you are someone who doesn't work in that language
| regularly.
|
| Plus as sibling comment says you usually don't do anything
| but install hugo, `hugo [command]`
| cjlm wrote:
| Check out Eleventy[0] - written in JavaScript but largely no-
| nonsense with (relatively) few dependencies.
|
| [0] https://www.11ty.dev/
| notpushkin wrote:
| We've used Eleventy on a project a year ago and it was super
| easy to get running. It is not tied to any frontend framework
| (but if you want an interactive part on the page, you will
| have to set it up yourself, in contrast to Astro's Islands
| [1]).
|
| My overall impression is: use 11ty for a first version, use
| Astro when you have more moving parts on the frontend.
|
| Little bonus for those coming from Python background (like
| me): 11ty uses Nunjucks, which is a JavaScript port of Jinja,
| so the templating system feels right at home.
|
| [1]: https://docs.astro.build/en/concepts/islands/
| bluehedgehog29 wrote:
| Not sure if you've heard of Publii?[0]
|
| It's a static blog generator type thing, bit of a different
| concept to the framework posted. I've tried it a few times
| casually and it seems ok for non-devs to get something simple
| up and running. Bit of dev work can update templates etc
|
| The SEO defaults aren't perfect but they're easy enough to
| change in the software.
|
| [0] https://getpublii.com
| unicornporn wrote:
| > Yet, I can never get the old test site I set up running again
| without massive annoyances.
|
| Use Zola or Hugo. They have zero dependencies.
| traverseda wrote:
| I like to use tup with jinja.
|
| https://gittup.org/tup/
|
| https://github.com/kolypto/j2cli
| crabmusket wrote:
| I believe m4 comes preinstalled on some Linuxes.
| orthecreedence wrote:
| Maybe it's too obscure, but I really like Metalsmith. Once it
| "clicks" it becomes ridiculously easy to make plugins and to
| operate, and it generally doesn't go out of date.
|
| That said, it may require a bit of javascript knowledge to get
| a more customized build running. It does have YAML
| configuration and a set of useful plugins you can use without
| touching code, from what I know.
| schemescape wrote:
| I liked Metalsmith because it was so simple that you could
| understand every single thing it did and why. Unfortunately,
| the dependency tree gets ridiculous quickly, especially since
| many of the plugins depend on different versions or
| implementations of libraries (e.g. path matching libraries).
| My site ended up with 200+ transitive dependencies.
| ASalazarMX wrote:
| Hugo (https://gohugo.io) maybe? I tried it for a small static
| site about internal documentation, and I'm very glad I did. The
| hardest part was reading the documentation, the installation,
| content generation and rebuilds were painless.
| kylecordes wrote:
| Hugo is interesting, has significant challenges.
|
| Much of the interesting and useful tooling today is in the
| JavaScript ecosystem, that you will still have a
| package.json, Node dependency, etc. Except they are not
| Hugo's problem, they arrived via a theme you are using, and
| they are your problem.
|
| Hugo itself is a pretty lean template system. That means it
| doesn't know much about building websites. All kinds of
| things you hope it will know about (SEO, how to plugin
| analytics systems, much much more), are sitting over in
| themes in the ecosystem... tangled up with the axis of what
| visual appearance you want.
|
| So the notion of swapping themes to swap appearance doesn't
| work, because the theme you picked provides a bunch of
| functionality in addition to appearance, and a different one
| will not have the same functionality.
|
| This isn't a complaint, it is a good piece of work with many
| well-thought-out ideas. But it is pretty far from what the
| poster was looking for.
| skrtskrt wrote:
| The hardest part of Hugo for me was creating my theme from
| scratch (docs are eh on this but I found some good 3rd party
| tutorials) but after that it's been an absolute breeze.
|
| After spending a little time understanding Go templating it
| is really beautiful
| powersnail wrote:
| Half way through customizing a Hugo theme, I suddenly
| realized that I don't need a theme at all. Hugo can be used
| themelessly, where you just write templates specifically
| for your site. Everything was so much easier from there.
| procombo wrote:
| That was my experience too. There is/was no formal
| standard for creating themes, just an empty dir (which
| they consider a feature). Even if they had one or two
| "official themes" that would have helped tremendously.
|
| Instead we spent a week researching how popular 3rd party
| themes did things, and made a hybrid. Then we moved away
| completely. I really wanted it to work for us and we were
| so close. Hugo is so fast and is brilliant on a couple of
| things.... but barely missed.
|
| I can't remember exactly but with what we were doing we
| were going to be heavily dependant on their Scratchpad,
| which felt like a hack. It's all just hacks, and they
| like it. Lack of solid conventions, and they LOVE it.
| skrtskrt wrote:
| wait do you have a repo example of this or some sort of
| link?
|
| My theme is so simple I think redoing it as themeless may
| be better
| powersnail wrote:
| Replace the themes directory with the "layouts" directory
| which contains all the templates. I do my blog this way.
| https://github.com/PowerSnail/PowerSnail.github.io
| skrtskrt wrote:
| OK I see, but even though it's themeless you still have
| to follow the Hugo theming structure (_default, partials,
| index.html, etc). Mine is the same as that, it's just
| nested into the themes directory.
|
| It's that theming structure that was a pain to figure out
| the first time for me
| powersnail wrote:
| Yeah, that template look-up hierarchy is unavoidable. The
| benefit of being themeless is mostly organizational: one
| config file, one asset directory, etc.
| e_i_pi_2 wrote:
| As a counterpoint - the big benefit I see from Astro isn't that
| it has minimal dependencies, it's mainly that it seems like a
| very flexible foundation to build from. So I'd agree a landing
| page doesn't need this, but "the best tool" for a landing page
| is probably too specialized for general use in larger
| applications.
| p4bl0 wrote:
| This is one of the reason I built Cigala [1], it's a single PHP
| script that let you build your website in the admin interface
| using a WYSIWYG editor (TinyMCE) that manipulates an SQLite
| database, and that produce static HTML pages for publishing. It
| only depends on PHP and SQLite which are available virtually
| everywhere for free (and in the worst case you can run it
| locally as the resulting static website can be copied to any
| static hosting).
|
| [1] https://code.up8.edu/pablo/cigala
| MatthewPhillips wrote:
| Here's a good SEO component:
| https://www.npmjs.com/package/simple-astro-seo
| malfist wrote:
| Have you checked out Hugo? It's builds are pretty fast, and it
| has a watch function for rapid dev work.
|
| Not sure how you'd get away from a build on updates though, it
| is called a static site __generator_. If you want to skip the
| build entirely, just write .html files and call it a day.
| Annatar wrote:
| 91edec wrote:
| Are you really complaining that people are trying to innovate
| and create new things? You are not forced to use it.
| Annatar wrote:
| How is inventing yet another complicated machinery to churn
| out some HTML and JavaScript innovation?
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| Annatar wrote:
| It's not a shallow dismissal, it's the scourge of our
| industry; I can't wait to retire so that I would never have
| to look at it again. Give it a rest with virtue signalling.
| dang wrote:
| X being a scourge does not make every X-comment deep. On
| the contrary, comments about scourges are often shallow and
| lame.
|
| Edit: I just took a look at your recent comment history,
| and ouch--that makes it painfully clear that you don't want
| to use HN as intended. I've therefore banned the account.
|
| If you don't want to be banned, you're welcome to email
| hn@ycombinator.com and give us reason to believe that
| you'll follow the rules in the future.
| jackconsidine wrote:
| I've used Astro my company's landing page for the past year or so
| [0]. We write blog posts in Notion and port them right to the
| site and the experience has been fantastic. There are a few
| understanding quirks with regard to using React etc within Astro
| (it's SSR'd unless you add the "client" attribute, and counter-
| intuitively the Component Lifecycle doesn't run the same). For
| client landing pages, we'll use Astro too- occasionally they'll
| want a CMS to write their own blog posts without a Git / commit
| pipeline. In those cases, Netlify CMS plugs in seamlessly and has
| a generous free tier.
|
| [0] https://koptional.com
| foofoobar wrote:
| Netlify recently changed their pricing structure, so if you are
| using Netlify CMS (or just Netlify Identity) with a private
| repo, every contributor to the repository (committer) will be
| charged as full pro seat. This can get really expensive if you
| have a few users working with the CMS (and thus committing
| content to the repository). We will move a few pages from
| Netlify now because of this change.
| eins1234 wrote:
| Also, found out the hard way that "Enterprise" pricing (i.e.
| call us and we'll charge you an opaque amount based on
| whatever we think you can afford pricing) starts at 7 users.
|
| Vercel is not much better at 10 users, and they hide it deep
| within their pricing table behind a tooltip so you're not
| likely to realize this until it's too late.
|
| Cloudflare Pages doesn't charge per user but limits
| concurrent builds which can get really painful.
|
| I honestly can't find a good option in this space anymore...
| What happened?
| zoover2020 wrote:
| +1, looking for answers too.
| pbowyer wrote:
| > I honestly can't find a good option in this space
| anymore... What happened?
|
| They took lots of VC money, got crazy valuations and picked
| up a few enterprise customers as the JamStack trend grew -
| and now have to try to generate a return.
| tomnipotent wrote:
| > and now have to try to generate a return
|
| Otherwise called running a business.
| tomnipotent wrote:
| Assuming that 7-10 users are FTE, the company is already
| spending more than $1M on salary and related costs. I
| imagine the annual Enterprise pricing for Vercel for that
| numbers of users would hover around 1/4 of an FTE's salary,
| which is reasonable considering the value provided.
| andrethegiant wrote:
| That pricing change only impacts private repos owned by
| organizations -- you can still have private repos on a
| personal account and not be charged.
| swyx wrote:
| netlify pricing changes for those who want the source
| https://www.netlify.com/blog/announcing-changes-to-
| netlify-p...
|
| and for private orgs https://www.netlify.com/pricing/private-
| org-repo-faq/
| bdn_ wrote:
| Interesting, how does the process of going from Notion to Astro
| work? Are you just exporting Markdown files, or is there an API
| integration in use?
___________________________________________________________________
(page generated 2022-08-09 23:00 UTC)