15 ms·

Astro: Ship Less JavaScript

369 points by feross 5y ago

fks 5y ago
:wave: Hey everyone, one of the Astro creators here! Happy to talk Astro or answer any questions you have about what we're building. Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro https://github.com/snowpackjs/astro
- exacube 5y ago
  Thanks for all the hard work and open sourcing it! Are there benchmarks/numbers for how Astro improves page load / page download size for a relatively complicated web app? I wasn't able to find it on the website or the README.
  - fks 5y ago
    No benchmarks yet, but I'll look into adding some. In the meantime there are a few sites in the wild already built with Astro that you can check out: - https://www.snowpack.dev/ https://www.snowpack.dev/ - https://divriots.com/ https://divriots.com/
- jacobsimon 5y ago
  Hey! Do you have any live demos or real(ish) apps made with Astro that we could check out?
  - fks 5y ago
    There are a few sites in the wild already built with Astro that you can check out: - https://www.snowpack.dev/ https://www.snowpack.dev/ - https://divriots.com/ https://divriots.com/
    - virgil_disgr4ce 5y ago
      That snowpack site is definitely pretty %*(&ing fast :D
    - najarvg 5y ago
      Wow snowpack.dev was blazing fast for me! Need to try this on one of our internal applications
    - replwoacause 5y ago
      The speed of snowpack is impressive. It's nearly as fast as loading plain text.
- qbasic_forever 5y ago
  How well do web components fit into astro pages? Do you get the same kind of partial hydration/load on first view semantics with them as it looks like you can do with React/Vue/Svelte components?
  - MatthewPhillips 5y ago
    Not yet, Lit has support for SSR in prerelease and we've experimented with supporting it. Once it's ready it will be included. In the meantime you can of course use web components (with any framework) like you normally would, just without SSR. Tracking issue for Lit support: https://github.com/snowpackjs/astro/issues/109 https://github.com/snowpackjs/astro/issues/109
    - qbasic_forever 5y ago
      Very cool! Yeah I wish SSR was more of a thing in the web component world. Someday soon hopefully!
      - MatthewPhillips 5y ago
        Stencil support is being worked on too: https://github.com/snowpackjs/astro/pull/266 https://github.com/snowpackjs/astro/pull/266
      - seanp2k2 5y ago
        Amusing to me to see the return to concepts that the dynamic web started with in the form of CGI, mod_perl, Cold Fusion, PHP, ASP.NET and all that. It’s the same, but different. Next we’ll be on to multi-tiered caching. What’s the difference conceptually between islands and e.g. Hole-punching in Varnish? The result in each case seems to be a site that is mostly static with some dynamic portions.
- zanethomas 5y ago
  very interesting, i'm going to try it out with a vue project soon
- superjan 5y ago
  Hi, looks like a great development for developers and users alike. But I am curious how you intend to make money from this. Or is this a not for profit initiative?
  - gmmeyer 5y ago
    it seems like it's just an OSS project no need to make money
- whelming_wave 5y ago
  How does this compare to Elder.js[1] which released a little while ago? You seem to have similar goals - mostly static site with small amounts of interactivity, minimum JS to achieve that - but Astro supports multiple frameworks, while Elder.js is restricted to Svelte. Are there any other big differences? [1]: https://elderguide.com/tech/elderjs/ https://elderguide.com/tech/elderjs/
  - fks 5y ago
    Elder is great! We're definitely fans. both Elder and Astro deliver Partial Hydration and the same "0kb JS by default" story. We wanted something less Svelte-specific and more pluggable, along with some other neat features mentioned in the README that couldn't fit in the launch post.
  - nickreese 5y ago
    Hey Elder.js author here. Only browsed their docs but here are the things that stand out in very quick read: - Framework agnostic but uses their own .astro language/filetype. Elder.js is Svelte only. - Both support partial hydration and they appear to offer similar options as Elder.js - Elder.js’ target isn’t building a small site but a large one. So data flow and making the data model pluggable via hooks and plugins really makes this possible in a way we haven’t seen other framework approach it. We’ve heavily dogfooded Elder.js for building major SEO assets. Fetch as the main way of getting external data in Astro where Elder.js leaves that up to you and gives you complete control allowing various database or filesystem sources. - Unclear on their build process. - Elder.js is express middleware (SSR) and a static site generator. Astro appears to just be a SSG. (Some of our sites are outgrowing SSG so the flexibility matters). - No shortcode support, hooks, or plugins. My take is that Astro might be a good fit for simpler use-cases but may stumble when you need more control or go against their model. Elder.js has similar opinions but tries to put you in full control. That comes at a complexity cost which Astro appears to do a good job of simplifying but I’d need to dig in deeper to see what tradeoffs were made in order to make things simpler. Happy to see more people taking partial hydration seriously. Edit: formatting
- camdenlock 5y ago
  Hi fks. Astro looks really compelling, but I’m already addicted to NextJS and deploying on Vercel. Any chance an Astro app will be deployable on Vercel or similar services?
  - fks 5y ago
    Yup, static site means you can pretty much deploy anywhere! Just configure Vercel to point to the final destination build directory when you set up your project.
- mwcampbell 5y ago
  Congrats on the release. For some reason when I heard of Astro, I thought it was a dynamic server-side rendering framework, not a static site builder. But I'm sure someone else will take on SSR with islands if they haven't already. Also: > Astro is and always will be free. It is an open source project released under the MIT license. > We care deeply about building a more sustainable future for open source software. At the same time, we need to support Astro's development long-term. This requires money (donations alone aren't enough.) Why make it harder for yourselves by choosing such a permissive license? Developers shouldn't be ashamed to not just ask for, but demand, compensation, for the software itself, by choosing a more restrictive license. Even if that means you can't call it free software or open source, e.g. a source-available license that requires payment for commercial use. By now we should be ready to accept that free software with no strings attached just isn't sustainable except for projects with big corporate backers.
  - nickreese 5y ago
    Elder.js supports Islands with SSR. It is also MIT. I released it as an SEO experiment as much as anything else. I’m enjoying the dev process and am committed to facilitating (myself or paying another) it’s maintenance for several years. I can do that because my prior successes can subsidize the cost. If I had to do it again, I’d probably pick another license. As a first time maintainer of a project that is hitting the pit of success it is amazing the number of for profit companies taking the framework and demanding changes to suit their narrow business cases. I literally LOL at some of the emails. I very much think the state of OSS isn’t sustainable. It has been an interesting rodeo.
    - freeopinion 5y ago
      > I very much think the state of OSS isn’t sustainable. I'm perplexed by this. You wrote that Elder.js was an experiment. I sense that the stress you are feeling now is a result of trying to make it work for everybody else. But it doesn't have to work for anybody else. OSS that is a slave to people who don't contribute may very well be unsustainable. OSS for the fun and use of it is perfectly sustainable. If Elder.js does what you need, that's great! If you're hoping it makes you the next DR Hipp or John Resig, maybe think about whether you really want that. If you do want that, that's fine, too. It just comes with a lot of demands.
- Kinrany 5y ago
  Since you're not shipping JS to the browser, you don't have to use it in the first place, right?
- iworshipfaangs2 5y ago
  Any plans to add asciidoc support? This projects looks great, but markdown has severe limitations when authoring content. I really wish it would stop being used for anything but plaintext email and READMEs.
- brainless 5y ago
  I have been using Skypack (and friends) as I am using Deno. Then I started getting interested in Snowpack. Today I read your first paragraph and I immediately felt there is something about Snowpack in here. Embracing the ESM* route and some concepts from Deno and other efforts will greatly simplify the build process. Right now I feel overwhelmed in large frontend projects which have custom Webpack and lots of loaders and stuff. Going HTML first and adding JS as needed is great, but I am curious if there is any way to not have a large chain of dependencies creep in. The moment a project has a decent developer size, this happens. How do you wish to tackle this?
- estaseuropano 5y ago
  Hi, thanks a lot for this work! A possibly naive question from someone that dabbles in tech/web only for pleasure while working in a completely different realm: I understand the how of using a site builder like yours, but not the why. I see you allow e.g. use of react or svelte - don't they already allow you to build static sites? And i know e.g. Hugo, Hexo & co that allow static site generation, but presumably don't need use of another framework. What is it that Astro does beyond or better than those tools? Why and who would benefit from spending time learning and using it? E.g. if I start to learn svelte what benefit will it bring me to learn also Astro and make my hobby project dependent on it? Could you give a few use cases where it would or would not add value to use Astro, to help less informed people like me? Thanks again!
- httgp 5y ago
  This looks super-exciting. Will you be building plugins or examples that show how to use this with other frameworks like Next.js/Nuxt.js?
- mcintyre1994 5y ago
  Does this handle anything serverside at all, like if you need auth or if you need to read data from a database at request time? Or would you fall back to something like Next if you needed that?
- cout 5y ago
  After reading the front page, I'm a little confused. How do you go from "compose your website using UI components from your favorite JavaScript web framework" to "a fully static website with all JavaScript removed from the final page" without losing functionality provided by those components? What's the purpose of using components without JavaScript?
  - ratorx 5y ago
    I don’t use this, but I do something similar for my personal blog. JSX (and components) is possibly the nicest templating language I’ve ever used. The problem with almost all others is that they are based on strings, so you lose type-safety (and more importantly completions) for the template parameters. However, the current ecosystem makes it really hard to use JSX for just templating. There are libraries that do exactly that, but you end up wanting compatibility with React, because there are a ton of pre-made components that basically output only HTML (for my use case, react-fontawesome), which you miss out on by using a different library.
    - gnrlst 5y ago
      I'm sorry, but how is JSX a good templating language? I much prefer Svelte's approach where you have native HTML and script/css tags within which lives native (scoped) code.
      - ratorx 5y ago
        Svelte being good doesn’t stop JSX from also being good. I haven’t used Svelte (but I’ve given it a brief look), so some of these might be wrong. Scoped CSS is nice but not a necessity by any means (I use Tailwind). Svelte is very restrictive, as it basically forces 1 component per file. Svelte also introduces new syntax to to handle conditional HTML and iterated HTML, which I personally don’t like. With JSX, everything is just Typescript. I’m a bit torn on slots, but I think I prefer JSX’s everything is a prop approach.
- akie 5y ago
  Hello, I get that you're trying to make websites faster, and it seems like you have some amazing technology, but I have to tell you in all honesty that you have a 1.5 Mb PNG on the linked page. If you want to optimize a website, then (as I'm sure you know) optimizing the images is about the first thing you need to do. With minimum effort and without apparent loss of quality I could reduce that image to a 0.4 Mb PNG (by uploading to https://imagecompressor.com/ https://imagecompressor.com/), if I'd be willing to change to JPG you can even get it down to 0.2 Mb (https://photoshop.adobe.com/compress https://photoshop.adobe.com/compress). That's a significant improvement that will really reduce page load times. For me, personally, I would really want to address this if you are positioning yourselves in the website optimization space. Cheers!
jypepin 5y ago
JS dev: I'm burnt out by having to keep up with all the tools that are releasing all the time! Also JS dev: Look, I've built another tool!
- wizzwizz4 5y ago
  This tool undoes a lot of harm of tool proliferation. It's one of the few JavaScript tools I'll actually approve of. If you're confused, perhaps try not lumping everybody into the homogenous “JS dev”.
  - sibeliuss 5y ago
    yeah in a way its kinda the anti-tool
ecmascript 5y ago
I read "how astro works" but I don't really get it. How can this work for dynamic content? Does it render every possible scenario? What if data changes?
- MatthewPhillips 5y ago
  Currently you build a static site like you do with Gatsby or Jekyll or any other static site generator. In the future it will support dynamic server rendering.
  - ecmascript 5y ago
    Ok so it is a static site generator. Wasn't really obvious from the landing page. Doesn't almost every large front end framework have a static site generator? I think Vue for example has it built in for example. Why would anyone use this over the already existing one in their current ecosystem?
    - MatthewPhillips 5y ago
      I can't speak for every frameworks' SSG tool but most of them load a full SPA on the client and have poor performance. Go pick out a random website for Gatsby's showcase page and see how much JS is loaded (spoiler: a lot). Astro focuses on partial hydration where you only load the JS for the specific components that need to run in the client. Very few tools and none of the framework SSG's that I'm aware of do this. There's also a variety of other features that Astro brings, the blog post talks about them.
      - ecmascript 5y ago
        Ok well it seems kind of cool, maybe I'll try it out. :)
- qbasic_forever 5y ago
  Check out the islands architecture info, or search around for info on partial hydration. It's similar to how things worked in the jQuery days--you serve up plain old HTML and have a JS function that runs on page load to attach all the event handlers (onclick, etc.) to your dynamic elements (i.e. 'hydrating' the static HTML into dynamic HTML + JS components). The thing with frameworks like Astro is that they try to automate and manage all of that hydration for you, which is nice because for complex sites with lots of different components it becomes a huge, error prone chore to manually wire things up. edit: Island architecture background info: https://jasonformat.com/islands-architecture/ https://jasonformat.com/islands-architecture/
nielsbot 5y ago
Wondering how this compares to Gatsby or other React-compatible static site generators...
- MatthewPhillips 5y ago
  Most of those tools are focused on giving you a full SPA on the client (and therefore load a lot of JS). Astro is focused on sites that are mostly static with "islands" of interactivity. To that end every component is server rendered only, by default, and you opt-in to client render when you need it (with different loading strategies).
m1117 5y ago
I want some demos. One demo=thousand readmes.
- fks 5y ago
  Run `npm create astro` in any directory to load one of 4 starter demos!
  - tchetwin 5y ago
    Suspect that should be `npm init astro` or `yarn create astro`. TIL: npm initializers, thanks!
hnal943 5y ago
This is neat. The last site I built in Next.js we turned off the SPA, but needed to then write all the client side js in a separate workflow. Seems like this could be progress.
kissgyorgy 5y ago
https://dayssincelastjavascriptframework.com/ https://dayssincelastjavascriptframework.com/
- bdibs 5y ago
  It's sort of ironic that page loads 213kB of JavaScript from 8(!) separate scripts to show a large 0.
  - jeroenhd 5y ago
    To be fair (but not too much), the devs did compress and minify their JS and host everything on the same domain, so with HTTP/2 the network impact should not be too high in comparison. In comparison to a "normal" web page that loads 213KiB of script that's not necessary because the HTML already shows the big zero regardless. At least the CSS is fairly minimal. The web is a terrible place. Google should rank Javascriptless websites higher in search results to push for less scripting, it's the only way I can see this situation improving.
krmmalik 5y ago
Templates for low coders like me?
r6203 5y ago
At the moment I'm using Gatsby but the client side js bundle turns me off. However, one thing I really like about Gatsby is the dynamic image component. Is there any way (or are there any plans) for generating responsive images when using Astro? As Astro is framework agnostic, I don't think so, right?
aligray 5y ago
New static site generator tool releases seem to have superseded new js framework releases. I like the direction things are moving.
- z3t4 5y ago
  Next biggest thing will be a framework for a static site to generate a React app, that generates a static site, inside a web worker.
  - pipework 5y ago
    Do you mean https://wasp-lang.dev/ https://wasp-lang.dev/ perhaps?
    - replwoacause 5y ago
      Every time I see this I get so excited until I realize again that I still have to know how to code in React, Node.js and Prisma.
  - contriban 5y ago
    If you have a whole is running in a web worker client-side that’s hardly “static” anymore. A site is static when the page is built beforehand and served from disk — or at most built JIT on the server and then cached.
- mmgutz 5y ago
  It's good times :) Next and Gatsby do too much for our use cases which are LOB applications. We've had to work around the idiosyncrasies of Next.js when we really don't need SSR nor its limited custom server support. Astro may be a closer fit for our needs. It's nice to see more esbuild-based frameworks, sveltekit, astro ... The edit-save-refresh cycle is almost instanteous even on large projects. Something I can't say for Next.js.
  - ttty2 5y ago
    Gatsby has a ton of magic... I use it but I rather skip it.
dasb 5y ago
Is it possible to achieve the same thing just with Svelte + SvelteKit and some configs?
- miltonsopus 5y ago
  Yes, with SvelteKit you can use the static adapter to generate static html files for your routes. It's also possible to control this on a page by page basis.
  - dasb 5y ago
    Thanks. What if only some components in my page require Javascript? Can the same "partial hydration" be achieved?
    - MatthewPhillips 5y ago
      No. Svelte are big proponents of the SPA pattern so I'm doubtful they would ever build something like this.
      - jiofih 5y ago
        Svelte by its nature only generates JS for the dynamic pieces of the page, if you’re using SSR it’s already “partially hydrated”. Vue3 can also ignore static parts which gives similar benefits.
0xbadcafebee 5y ago
> Of course, sometimes client-side JavaScript is inevitable. Image carousels, shopping carts wait, what? I've built shopping carts that didn't need javascript... but that was probably 15 years ago...
- asadlionpk 5y ago
  Those non-js carts reload the page when we add/remove anything from it. Not a great UX in post-AJAX world.
zx2391 5y ago
Sometimes I wonder what was wrong with a mostly static pages in the first place. Even http://mail.google.com/mail/h/ http://mail.google.com/mail/h/ works fine, even in a slower browser - and I would say 80% of the sites today are less complex than Gmail.
- killingtime74 5y ago
  Resume driven development maybe
- whoisthemachine 5y ago
  I forgot how great Gmail was before they started doing major redesigns to it, although I do hate to say it... but it could benefit from a little JS to dynamically update with new e-mails...
- pjmlp 5y ago
  They don't look good on candidates that use github driven resume applications.
andrewmcwatters 5y ago
I don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option, I use `"build": "npx babel --watch public/javascripts/src --out-dir public/javascripts/. --presets react-app/prod"` and that's it. I don't want create-react-app lock-in. Eject doesn't count. That's an illusion. My favorite process right now is a git repository that can be cloned into production, requires no build process, and works out of the box, to be statically served by any HTTP server. I commit my React builds. To me, this is the modern incarnation of Sublime Text and SFTP to my shared LAMP. Today, I use Ubuntu 20.04 LTS, with a minimal bootstrap.sh and do it on a lowendbox for under 11 USD/yr. I use CDNs. I don't use Amazon AWS because they aren't small business friendly. Which means I still write my own bootstrap.sh provisioning scripts, and deploy VPSs by hand. I don't want to use a JavaScript ecosystem with marketing. I would prefer that something came out and deterred all of the types of people, yes types of people that I don't want using the software I use. The type of person who thinks it's a good idea to use a technology for less than 10 years and eschews mastery and memorization. I want to do 1 hour of work for 10,000 USD. Not 40 hours for 4,000 USD. But you cannot do that type of work grinding away never learning and building exponentially on an existing corpus of knowledge. Less Docusaurus mentality, more man7.org. Edit: Apparently some people can't connect the dots here and don't see how this is relevant to Astro. So, I'll spell it out: This is another npm project that forces me to build, forces me to use npm, and forces me to use Astro-specific (whatever that is) knowledge to build web pages. I don't want that. All of the little details about those decisions ripple out into everything else I've just talked about. If I build, I'm probably .gitignoring my builds. So my repo out of the box is worthless. Because my repo is worthless, I can't deploy straight to my target environment. Because the author already thinks my target environment shouldn't be graced by something that works out of the box, they probably don't care about the resources of those boxes. They probably don't deploy software to VPSs at all. Maybe they use Heroku or think, "that's not my problem." I want technologies that understand the entire scope of what I'm trying to accomplish without trying to be the entire scope of what I'm trying to accomplish.
- kbenson 5y ago
  > don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option A few years back I chose Vue for supplementing the current little bit of web stuff I was doing because I could just include vue from a script to build a new page. The basic idea was <html> <head> <script src="https://cdn.jsdelivr.net/npm/vue@2.6.10/dist/vue.min.js"></script> </head> <body>  <script> // Vue page specific JS goes here </script> </body> </html> There was zero build process.
agrippanux 5y ago
I can't tell from the homepage or the blog post what this does and why it would make my life as a developer easier.
- azangru 5y ago
  > I can't tell from the homepage or the blog post what this does The passage below, on the linked page, is a dead giveaway of what it does, no? > - 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default. > - On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
  - didibus 5y ago
    Not really, I mean, it says No JS on one hand and then it says you can add JS, and you can even build your whole website using your favourite JS framework. So it is a little contradictory no? At least it does confuse me a little.
    - eyelidlessness 5y ago
      You can use your JS component library of choice, and decide whether a given component is rendered on the client or not (and certain conditions for what causes it to render). It doesn't render any of them on the client at all, by default.
    - DangitBobby 5y ago
      The idea is if you built your site using a js framework but it turns out you don't need that much js, it will make as much of it into static html as possible and the leave the bits that simply must be dynamic as js.
ilaksh 5y ago
Well.. I already have all my HTML in one file, and using plain JavaScript with actual template elements in this current application. But I do need some JavaScript. What I want is just an easy way to drop excess packages from the webpack bundle ("tree shaking"). Seems a little manual with the default webpack process for that.
eyelidlessness 5y ago
So excited to see this released, congrats! Astro is the closest thing to what I wanted (and a bunch more) when I started to get back into web dev and started building my personal site. While I haven’t contributed yet (besides a slew of comments on issues/PRs), I’m stoked to take another stab at a Solid renderer plugin. Really impressive work y’all. Can’t wait to see how it grows.
lesstenseflow 5y ago
Is Astro very different from using another SSG like Hugo, then adding JavaScript in places you need it like type ahead search box or an interactive map? Given that it’s possible to add JavaScript to an SSG made site already, I don’t get what Astro does that’s different.
- eyelidlessness 5y ago
  The biggest difference is that the DX is more like Next/Gatsby type frameworks, where you develop build/client with the same tooling and components, but unlike those frameworks most of your components don’t get bundled or run in the browser. A great use case is if you like to work with an isomorphic component library, but you’re building a mostly-static site (in the sense that it’s mostly non-interactive). Tools like Next etc provide that DX, but they bundle/run that static content twice per page load. Astro only bundles the stuff you specifically mark as interactive. This probably sounds trivial if you’re taking a more traditional approach to server/client responsibilities. But for anyone wanting to render on build and hydrate with the same component logic it’s a huge improvement over most of the current isomorphic approaches.
yewenjie 5y ago
How does it compare to SvelteKit which, AFAIK, also lets you ship no JS + hydration?
tak5651 5y ago
Would it work with typescript?
BiteCode_dev 5y ago
Alternatively, just don't write an SPA. Write a regular site, with just the few interactive elements you need. If you use react or vue, you can plug components precisely anywhere on the page, you don't need to take over the page entirely. In fact, with vue, you can even put the template in the HTML directly, and just hook the logic on to it, angularjs v1 style.
- oliv__ 5y ago
  > In fact, with vue, you can even put the template in the HTML directly, and just hook the logic on to it, angularjs v1 style. That's what I do, I love the simplicity of it and how it lets you render html pages server side, with the added JS for interactivity. Maybe not the cleanest architecture but extremely straightforward.
seanp2k2 5y ago
>” On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.” I see we’ve discovered the idea of DLLs for the web.
seanp2k2 5y ago
I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages. I remember a time when people here would cite http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ a lot. Modern browser APIs can do more than ever. I wonder if there’s a more recently-updated equivalent about how one might not need node tooling at all to build a static site.
- varrock 5y ago
  I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.
  - mro_name 5y ago
    have a link? I even do similar for a microblog: https://demo.mro.name/shaarligo https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).
  - pjmlp 5y ago
    My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available. While at work, it has been mostly Java JEE/ASP.NET since they exist. When I play around with WebGL, it is all JavaScript modules and script tags, nothing else. No babel, no webpack, no npm, nothing, just browser standard capabilities. Fully agree with your point of view.
    - bildung 5y ago
adreamingsoul 5y ago
Lately I’ve been going back to basics for some of my projects. Vanilla HTML, CSS and JavaScript. It has been refreshing and has brought some joy to my life.
yakshaving_jgt 5y ago
It seems a bit like a Phillips head screwdriver attachment for a hammer, because some people want to continue using their hammer to screw screws, rather than just learn to use a screwdriver.
wildpeaks 5y ago
I'm doing something similar because I was disappointed by the output of current static generators: everything gets prerendered to static markup, runtime JS only augments UX. In my case, the key breakthrough was reducing everything to arbitrary constrainted emitters with a topological sort. -- The build uses a GraphQL database to store the results (Prisma/Postgresql because it's great with Typescript). The whole site is defined by arbitrary Data Sources that read from 0+ other sources and write 1+ unit of data in the database. A source can do anything, the only constant is it must define at least one thing in the database. For example: - list of files generated by the webpack build of a specific runtime js - JSON version of a specific page - http response to serve when a specific url is requested --- A topological sort uses the constraints to deduce in which order to render data, for example: - a page showing the 5 most recent articles can't be rendered before the articles themselves - the french translation of an article cannot be rendered before the settings of the french website are defined --- This way, a specific page (or type of pages, or even every page of a site variant) can explicit state it needs a specific js runtime, and the build knows to bundle it before any page that needs it. Something like a cookie banner would be used by every page whereas a 3d model viewer webcomponent would only be used in specific pages. --- You end up with a static site as consequence of rendering the "http response to serve when X page is requested" sources, which in turn called all the other sources it required. The resulting database could even be available in production for dynamic pages that cannot be pre-rendered.
- Cthulhu_ 5y ago
  How does your solution compare to Gatsby?
  - wildpeaks 5y ago
    It fits my requirements, Gatsby didn't.
slver 5y ago
I see this tool as peak micro-intelligence and macro-stupidity of the whole web dev community. The tool itself is very interesting, and congrats to the authors. But needing this tool shows that in general we have no fucking clue what we're doing.
null4bl3 5y ago
I like how many comments mention "you don't need a framework" and then mention how they wrote there personal bloggers in pure whatever. Frameworks is not just some hyped up abstraction layer. Advanced frameworks offer advanced functionality for advanced projects. They really do. They have standardized certain ways of doing things, structuring complex web applications and solving problems. I completely agree about using a framework to build a personal blog is overkill in many ways, but don't blame the framework for that. Just like you shouldn't blame the saw for being bad at hammering in nails.

369 points by feross 5y ago

fks 5y ago

:wave: Hey everyone, one of the Astro creators here! Happy to talk Astro or answer any questions you have about what we're building. Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro https://github.com/snowpackjs/astro

exacube 5y ago
Thanks for all the hard work and open sourcing it! Are there benchmarks/numbers for how Astro improves page load / page download size for a relatively complicated web app? I wasn't able to find it on the website or the README.
- fks 5y ago
  No benchmarks yet, but I'll look into adding some. In the meantime there are a few sites in the wild already built with Astro that you can check out: - https://www.snowpack.dev/ https://www.snowpack.dev/ - https://divriots.com/ https://divriots.com/
jacobsimon 5y ago
Hey! Do you have any live demos or real(ish) apps made with Astro that we could check out?
- fks 5y ago
  There are a few sites in the wild already built with Astro that you can check out: - https://www.snowpack.dev/ https://www.snowpack.dev/ - https://divriots.com/ https://divriots.com/
  - virgil_disgr4ce 5y ago
    That snowpack site is definitely pretty %*(&ing fast :D
  - najarvg 5y ago
    Wow snowpack.dev was blazing fast for me! Need to try this on one of our internal applications
  - replwoacause 5y ago
    The speed of snowpack is impressive. It's nearly as fast as loading plain text.
qbasic_forever 5y ago
How well do web components fit into astro pages? Do you get the same kind of partial hydration/load on first view semantics with them as it looks like you can do with React/Vue/Svelte components?
- MatthewPhillips 5y ago
  Not yet, Lit has support for SSR in prerelease and we've experimented with supporting it. Once it's ready it will be included. In the meantime you can of course use web components (with any framework) like you normally would, just without SSR. Tracking issue for Lit support: https://github.com/snowpackjs/astro/issues/109 https://github.com/snowpackjs/astro/issues/109
  - qbasic_forever 5y ago
    Very cool! Yeah I wish SSR was more of a thing in the web component world. Someday soon hopefully!
    - MatthewPhillips 5y ago
      Stencil support is being worked on too: https://github.com/snowpackjs/astro/pull/266 https://github.com/snowpackjs/astro/pull/266
    - seanp2k2 5y ago
      Amusing to me to see the return to concepts that the dynamic web started with in the form of CGI, mod_perl, Cold Fusion, PHP, ASP.NET and all that. It’s the same, but different. Next we’ll be on to multi-tiered caching. What’s the difference conceptually between islands and e.g. Hole-punching in Varnish? The result in each case seems to be a site that is mostly static with some dynamic portions.
zanethomas 5y ago
very interesting, i'm going to try it out with a vue project soon
superjan 5y ago
Hi, looks like a great development for developers and users alike. But I am curious how you intend to make money from this. Or is this a not for profit initiative?
- gmmeyer 5y ago
  it seems like it's just an OSS project no need to make money
whelming_wave 5y ago
How does this compare to Elder.js[1] which released a little while ago? You seem to have similar goals - mostly static site with small amounts of interactivity, minimum JS to achieve that - but Astro supports multiple frameworks, while Elder.js is restricted to Svelte. Are there any other big differences? [1]: https://elderguide.com/tech/elderjs/ https://elderguide.com/tech/elderjs/
- fks 5y ago
  Elder is great! We're definitely fans. both Elder and Astro deliver Partial Hydration and the same "0kb JS by default" story. We wanted something less Svelte-specific and more pluggable, along with some other neat features mentioned in the README that couldn't fit in the launch post.
- nickreese 5y ago
  Hey Elder.js author here. Only browsed their docs but here are the things that stand out in very quick read: - Framework agnostic but uses their own .astro language/filetype. Elder.js is Svelte only. - Both support partial hydration and they appear to offer similar options as Elder.js - Elder.js’ target isn’t building a small site but a large one. So data flow and making the data model pluggable via hooks and plugins really makes this possible in a way we haven’t seen other framework approach it. We’ve heavily dogfooded Elder.js for building major SEO assets. Fetch as the main way of getting external data in Astro where Elder.js leaves that up to you and gives you complete control allowing various database or filesystem sources. - Unclear on their build process. - Elder.js is express middleware (SSR) and a static site generator. Astro appears to just be a SSG. (Some of our sites are outgrowing SSG so the flexibility matters). - No shortcode support, hooks, or plugins. My take is that Astro might be a good fit for simpler use-cases but may stumble when you need more control or go against their model. Elder.js has similar opinions but tries to put you in full control. That comes at a complexity cost which Astro appears to do a good job of simplifying but I’d need to dig in deeper to see what tradeoffs were made in order to make things simpler. Happy to see more people taking partial hydration seriously. Edit: formatting
camdenlock 5y ago
Hi fks. Astro looks really compelling, but I’m already addicted to NextJS and deploying on Vercel. Any chance an Astro app will be deployable on Vercel or similar services?
- fks 5y ago
  Yup, static site means you can pretty much deploy anywhere! Just configure Vercel to point to the final destination build directory when you set up your project.
mwcampbell 5y ago
Congrats on the release. For some reason when I heard of Astro, I thought it was a dynamic server-side rendering framework, not a static site builder. But I'm sure someone else will take on SSR with islands if they haven't already. Also: > Astro is and always will be free. It is an open source project released under the MIT license. > We care deeply about building a more sustainable future for open source software. At the same time, we need to support Astro's development long-term. This requires money (donations alone aren't enough.) Why make it harder for yourselves by choosing such a permissive license? Developers shouldn't be ashamed to not just ask for, but demand, compensation, for the software itself, by choosing a more restrictive license. Even if that means you can't call it free software or open source, e.g. a source-available license that requires payment for commercial use. By now we should be ready to accept that free software with no strings attached just isn't sustainable except for projects with big corporate backers.
- nickreese 5y ago
  Elder.js supports Islands with SSR. It is also MIT. I released it as an SEO experiment as much as anything else. I’m enjoying the dev process and am committed to facilitating (myself or paying another) it’s maintenance for several years. I can do that because my prior successes can subsidize the cost. If I had to do it again, I’d probably pick another license. As a first time maintainer of a project that is hitting the pit of success it is amazing the number of for profit companies taking the framework and demanding changes to suit their narrow business cases. I literally LOL at some of the emails. I very much think the state of OSS isn’t sustainable. It has been an interesting rodeo.
  - freeopinion 5y ago
    > I very much think the state of OSS isn’t sustainable. I'm perplexed by this. You wrote that Elder.js was an experiment. I sense that the stress you are feeling now is a result of trying to make it work for everybody else. But it doesn't have to work for anybody else. OSS that is a slave to people who don't contribute may very well be unsustainable. OSS for the fun and use of it is perfectly sustainable. If Elder.js does what you need, that's great! If you're hoping it makes you the next DR Hipp or John Resig, maybe think about whether you really want that. If you do want that, that's fine, too. It just comes with a lot of demands.
Kinrany 5y ago
Since you're not shipping JS to the browser, you don't have to use it in the first place, right?
iworshipfaangs2 5y ago
Any plans to add asciidoc support? This projects looks great, but markdown has severe limitations when authoring content. I really wish it would stop being used for anything but plaintext email and READMEs.
brainless 5y ago
I have been using Skypack (and friends) as I am using Deno. Then I started getting interested in Snowpack. Today I read your first paragraph and I immediately felt there is something about Snowpack in here. Embracing the ESM* route and some concepts from Deno and other efforts will greatly simplify the build process. Right now I feel overwhelmed in large frontend projects which have custom Webpack and lots of loaders and stuff. Going HTML first and adding JS as needed is great, but I am curious if there is any way to not have a large chain of dependencies creep in. The moment a project has a decent developer size, this happens. How do you wish to tackle this?
estaseuropano 5y ago
Hi, thanks a lot for this work! A possibly naive question from someone that dabbles in tech/web only for pleasure while working in a completely different realm: I understand the how of using a site builder like yours, but not the why. I see you allow e.g. use of react or svelte - don't they already allow you to build static sites? And i know e.g. Hugo, Hexo & co that allow static site generation, but presumably don't need use of another framework. What is it that Astro does beyond or better than those tools? Why and who would benefit from spending time learning and using it? E.g. if I start to learn svelte what benefit will it bring me to learn also Astro and make my hobby project dependent on it? Could you give a few use cases where it would or would not add value to use Astro, to help less informed people like me? Thanks again!
httgp 5y ago
This looks super-exciting. Will you be building plugins or examples that show how to use this with other frameworks like Next.js/Nuxt.js?
mcintyre1994 5y ago
Does this handle anything serverside at all, like if you need auth or if you need to read data from a database at request time? Or would you fall back to something like Next if you needed that?
cout 5y ago
After reading the front page, I'm a little confused. How do you go from "compose your website using UI components from your favorite JavaScript web framework" to "a fully static website with all JavaScript removed from the final page" without losing functionality provided by those components? What's the purpose of using components without JavaScript?
- ratorx 5y ago
  I don’t use this, but I do something similar for my personal blog. JSX (and components) is possibly the nicest templating language I’ve ever used. The problem with almost all others is that they are based on strings, so you lose type-safety (and more importantly completions) for the template parameters. However, the current ecosystem makes it really hard to use JSX for just templating. There are libraries that do exactly that, but you end up wanting compatibility with React, because there are a ton of pre-made components that basically output only HTML (for my use case, react-fontawesome), which you miss out on by using a different library.
  - gnrlst 5y ago
    I'm sorry, but how is JSX a good templating language? I much prefer Svelte's approach where you have native HTML and script/css tags within which lives native (scoped) code.
    - ratorx 5y ago
      Svelte being good doesn’t stop JSX from also being good. I haven’t used Svelte (but I’ve given it a brief look), so some of these might be wrong. Scoped CSS is nice but not a necessity by any means (I use Tailwind). Svelte is very restrictive, as it basically forces 1 component per file. Svelte also introduces new syntax to to handle conditional HTML and iterated HTML, which I personally don’t like. With JSX, everything is just Typescript. I’m a bit torn on slots, but I think I prefer JSX’s everything is a prop approach.
akie 5y ago
Hello, I get that you're trying to make websites faster, and it seems like you have some amazing technology, but I have to tell you in all honesty that you have a 1.5 Mb PNG on the linked page. If you want to optimize a website, then (as I'm sure you know) optimizing the images is about the first thing you need to do. With minimum effort and without apparent loss of quality I could reduce that image to a 0.4 Mb PNG (by uploading to https://imagecompressor.com/ https://imagecompressor.com/), if I'd be willing to change to JPG you can even get it down to 0.2 Mb (https://photoshop.adobe.com/compress https://photoshop.adobe.com/compress). That's a significant improvement that will really reduce page load times. For me, personally, I would really want to address this if you are positioning yourselves in the website optimization space. Cheers!

jypepin 5y ago

JS dev: I'm burnt out by having to keep up with all the tools that are releasing all the time! Also JS dev: Look, I've built another tool!

wizzwizz4 5y ago
This tool undoes a lot of harm of tool proliferation. It's one of the few JavaScript tools I'll actually approve of. If you're confused, perhaps try not lumping everybody into the homogenous “JS dev”.
- sibeliuss 5y ago
  yeah in a way its kinda the anti-tool

ecmascript 5y ago

I read "how astro works" but I don't really get it. How can this work for dynamic content? Does it render every possible scenario? What if data changes?

MatthewPhillips 5y ago
Currently you build a static site like you do with Gatsby or Jekyll or any other static site generator. In the future it will support dynamic server rendering.
- ecmascript 5y ago
  Ok so it is a static site generator. Wasn't really obvious from the landing page. Doesn't almost every large front end framework have a static site generator? I think Vue for example has it built in for example. Why would anyone use this over the already existing one in their current ecosystem?
  - MatthewPhillips 5y ago
    I can't speak for every frameworks' SSG tool but most of them load a full SPA on the client and have poor performance. Go pick out a random website for Gatsby's showcase page and see how much JS is loaded (spoiler: a lot). Astro focuses on partial hydration where you only load the JS for the specific components that need to run in the client. Very few tools and none of the framework SSG's that I'm aware of do this. There's also a variety of other features that Astro brings, the blog post talks about them.
    - ecmascript 5y ago
      Ok well it seems kind of cool, maybe I'll try it out. :)
qbasic_forever 5y ago
Check out the islands architecture info, or search around for info on partial hydration. It's similar to how things worked in the jQuery days--you serve up plain old HTML and have a JS function that runs on page load to attach all the event handlers (onclick, etc.) to your dynamic elements (i.e. 'hydrating' the static HTML into dynamic HTML + JS components). The thing with frameworks like Astro is that they try to automate and manage all of that hydration for you, which is nice because for complex sites with lots of different components it becomes a huge, error prone chore to manually wire things up. edit: Island architecture background info: https://jasonformat.com/islands-architecture/ https://jasonformat.com/islands-architecture/

nielsbot 5y ago

Wondering how this compares to Gatsby or other React-compatible static site generators...

MatthewPhillips 5y ago
Most of those tools are focused on giving you a full SPA on the client (and therefore load a lot of JS). Astro is focused on sites that are mostly static with "islands" of interactivity. To that end every component is server rendered only, by default, and you opt-in to client render when you need it (with different loading strategies).

m1117 5y ago

I want some demos. One demo=thousand readmes.

fks 5y ago
Run `npm create astro` in any directory to load one of 4 starter demos!
- tchetwin 5y ago
  Suspect that should be `npm init astro` or `yarn create astro`. TIL: npm initializers, thanks!

hnal943 5y ago

This is neat. The last site I built in Next.js we turned off the SPA, but needed to then write all the client side js in a separate workflow. Seems like this could be progress.

kissgyorgy 5y ago

https://dayssincelastjavascriptframework.com/ https://dayssincelastjavascriptframework.com/

bdibs 5y ago
It's sort of ironic that page loads 213kB of JavaScript from 8(!) separate scripts to show a large 0.
- jeroenhd 5y ago
  To be fair (but not too much), the devs did compress and minify their JS and host everything on the same domain, so with HTTP/2 the network impact should not be too high in comparison. In comparison to a "normal" web page that loads 213KiB of script that's not necessary because the HTML already shows the big zero regardless. At least the CSS is fairly minimal. The web is a terrible place. Google should rank Javascriptless websites higher in search results to push for less scripting, it's the only way I can see this situation improving.

krmmalik 5y ago

Templates for low coders like me?

r6203 5y ago

At the moment I'm using Gatsby but the client side js bundle turns me off. However, one thing I really like about Gatsby is the dynamic image component. Is there any way (or are there any plans) for generating responsive images when using Astro? As Astro is framework agnostic, I don't think so, right?

aligray 5y ago

New static site generator tool releases seem to have superseded new js framework releases. I like the direction things are moving.

z3t4 5y ago
Next biggest thing will be a framework for a static site to generate a React app, that generates a static site, inside a web worker.
- pipework 5y ago
  Do you mean https://wasp-lang.dev/ https://wasp-lang.dev/ perhaps?
  - replwoacause 5y ago
    Every time I see this I get so excited until I realize again that I still have to know how to code in React, Node.js and Prisma.
- contriban 5y ago
  If you have a whole is running in a web worker client-side that’s hardly “static” anymore. A site is static when the page is built beforehand and served from disk — or at most built JIT on the server and then cached.
mmgutz 5y ago
It's good times :) Next and Gatsby do too much for our use cases which are LOB applications. We've had to work around the idiosyncrasies of Next.js when we really don't need SSR nor its limited custom server support. Astro may be a closer fit for our needs. It's nice to see more esbuild-based frameworks, sveltekit, astro ... The edit-save-refresh cycle is almost instanteous even on large projects. Something I can't say for Next.js.
- ttty2 5y ago
  Gatsby has a ton of magic... I use it but I rather skip it.

dasb 5y ago

Is it possible to achieve the same thing just with Svelte + SvelteKit and some configs?

miltonsopus 5y ago
Yes, with SvelteKit you can use the static adapter to generate static html files for your routes. It's also possible to control this on a page by page basis.
- dasb 5y ago
  Thanks. What if only some components in my page require Javascript? Can the same "partial hydration" be achieved?
  - MatthewPhillips 5y ago
    No. Svelte are big proponents of the SPA pattern so I'm doubtful they would ever build something like this.
    - jiofih 5y ago
      Svelte by its nature only generates JS for the dynamic pieces of the page, if you’re using SSR it’s already “partially hydrated”. Vue3 can also ignore static parts which gives similar benefits.

0xbadcafebee 5y ago

> Of course, sometimes client-side JavaScript is inevitable. Image carousels, shopping carts wait, what? I've built shopping carts that didn't need javascript... but that was probably 15 years ago...

asadlionpk 5y ago
Those non-js carts reload the page when we add/remove anything from it. Not a great UX in post-AJAX world.

zx2391 5y ago

Sometimes I wonder what was wrong with a mostly static pages in the first place. Even http://mail.google.com/mail/h/ http://mail.google.com/mail/h/ works fine, even in a slower browser - and I would say 80% of the sites today are less complex than Gmail.

killingtime74 5y ago
Resume driven development maybe
whoisthemachine 5y ago
I forgot how great Gmail was before they started doing major redesigns to it, although I do hate to say it... but it could benefit from a little JS to dynamically update with new e-mails...
pjmlp 5y ago
They don't look good on candidates that use github driven resume applications.

andrewmcwatters 5y ago

I don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option, I use `"build": "npx babel --watch public/javascripts/src --out-dir public/javascripts/. --presets react-app/prod"` and that's it. I don't want create-react-app lock-in. Eject doesn't count. That's an illusion. My favorite process right now is a git repository that can be cloned into production, requires no build process, and works out of the box, to be statically served by any HTTP server. I commit my React builds. To me, this is the modern incarnation of Sublime Text and SFTP to my shared LAMP. Today, I use Ubuntu 20.04 LTS, with a minimal bootstrap.sh and do it on a lowendbox for under 11 USD/yr. I use CDNs. I don't use Amazon AWS because they aren't small business friendly. Which means I still write my own bootstrap.sh provisioning scripts, and deploy VPSs by hand. I don't want to use a JavaScript ecosystem with marketing. I would prefer that something came out and deterred all of the types of people, yes types of people that I don't want using the software I use. The type of person who thinks it's a good idea to use a technology for less than 10 years and eschews mastery and memorization. I want to do 1 hour of work for 10,000 USD. Not 40 hours for 4,000 USD. But you cannot do that type of work grinding away never learning and building exponentially on an existing corpus of knowledge. Less Docusaurus mentality, more man7.org. Edit: Apparently some people can't connect the dots here and don't see how this is relevant to Astro. So, I'll spell it out: This is another npm project that forces me to build, forces me to use npm, and forces me to use Astro-specific (whatever that is) knowledge to build web pages. I don't want that. All of the little details about those decisions ripple out into everything else I've just talked about. If I build, I'm probably .gitignoring my builds. So my repo out of the box is worthless. Because my repo is worthless, I can't deploy straight to my target environment. Because the author already thinks my target environment shouldn't be graced by something that works out of the box, they probably don't care about the resources of those boxes. They probably don't deploy software to VPSs at all. Maybe they use Heroku or think, "that's not my problem." I want technologies that understand the entire scope of what I'm trying to accomplish without trying to be the entire scope of what I'm trying to accomplish.

kbenson 5y ago
> don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option A few years back I chose Vue for supplementing the current little bit of web stuff I was doing because I could just include vue from a script to build a new page. The basic idea was <html> <head> <script src="https://cdn.jsdelivr.net/npm/vue@2.6.10/dist/vue.min.js"></script> </head> <body>  <script> // Vue page specific JS goes here </script> </body> </html> There was zero build process.

agrippanux 5y ago

I can't tell from the homepage or the blog post what this does and why it would make my life as a developer easier.

azangru 5y ago
> I can't tell from the homepage or the blog post what this does The passage below, on the linked page, is a dead giveaway of what it does, no? > - 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default. > - On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
- didibus 5y ago
  Not really, I mean, it says No JS on one hand and then it says you can add JS, and you can even build your whole website using your favourite JS framework. So it is a little contradictory no? At least it does confuse me a little.
  - eyelidlessness 5y ago
    You can use your JS component library of choice, and decide whether a given component is rendered on the client or not (and certain conditions for what causes it to render). It doesn't render any of them on the client at all, by default.
  - DangitBobby 5y ago
    The idea is if you built your site using a js framework but it turns out you don't need that much js, it will make as much of it into static html as possible and the leave the bits that simply must be dynamic as js.

ilaksh 5y ago

Well.. I already have all my HTML in one file, and using plain JavaScript with actual template elements in this current application. But I do need some JavaScript. What I want is just an easy way to drop excess packages from the webpack bundle ("tree shaking"). Seems a little manual with the default webpack process for that.

eyelidlessness 5y ago

So excited to see this released, congrats! Astro is the closest thing to what I wanted (and a bunch more) when I started to get back into web dev and started building my personal site. While I haven’t contributed yet (besides a slew of comments on issues/PRs), I’m stoked to take another stab at a Solid renderer plugin. Really impressive work y’all. Can’t wait to see how it grows.

lesstenseflow 5y ago

Is Astro very different from using another SSG like Hugo, then adding JavaScript in places you need it like type ahead search box or an interactive map? Given that it’s possible to add JavaScript to an SSG made site already, I don’t get what Astro does that’s different.

eyelidlessness 5y ago
The biggest difference is that the DX is more like Next/Gatsby type frameworks, where you develop build/client with the same tooling and components, but unlike those frameworks most of your components don’t get bundled or run in the browser. A great use case is if you like to work with an isomorphic component library, but you’re building a mostly-static site (in the sense that it’s mostly non-interactive). Tools like Next etc provide that DX, but they bundle/run that static content twice per page load. Astro only bundles the stuff you specifically mark as interactive. This probably sounds trivial if you’re taking a more traditional approach to server/client responsibilities. But for anyone wanting to render on build and hydrate with the same component logic it’s a huge improvement over most of the current isomorphic approaches.

yewenjie 5y ago

How does it compare to SvelteKit which, AFAIK, also lets you ship no JS + hydration?

tak5651 5y ago

Would it work with typescript?

BiteCode_dev 5y ago

Alternatively, just don't write an SPA. Write a regular site, with just the few interactive elements you need. If you use react or vue, you can plug components precisely anywhere on the page, you don't need to take over the page entirely. In fact, with vue, you can even put the template in the HTML directly, and just hook the logic on to it, angularjs v1 style.

oliv__ 5y ago
> In fact, with vue, you can even put the template in the HTML directly, and just hook the logic on to it, angularjs v1 style. That's what I do, I love the simplicity of it and how it lets you render html pages server side, with the added JS for interactivity. Maybe not the cleanest architecture but extremely straightforward.

seanp2k2 5y ago

>” On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.” I see we’ve discovered the idea of DLLs for the web.

seanp2k2 5y ago

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages. I remember a time when people here would cite http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ a lot. Modern browser APIs can do more than ever. I wonder if there’s a more recently-updated equivalent about how one might not need node tooling at all to build a static site.

varrock 5y ago
I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.
- mro_name 5y ago
  have a link? I even do similar for a microblog: https://demo.mro.name/shaarligo https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).
- pjmlp 5y ago
  My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available. While at work, it has been mostly Java JEE/ASP.NET since they exist. When I play around with WebGL, it is all JavaScript modules and script tags, nothing else. No babel, no webpack, no npm, nothing, just browser standard capabilities. Fully agree with your point of view.
  - bildung 5y ago

adreamingsoul 5y ago

Lately I’ve been going back to basics for some of my projects. Vanilla HTML, CSS and JavaScript. It has been refreshing and has brought some joy to my life.

yakshaving_jgt 5y ago

It seems a bit like a Phillips head screwdriver attachment for a hammer, because some people want to continue using their hammer to screw screws, rather than just learn to use a screwdriver.

wildpeaks 5y ago

I'm doing something similar because I was disappointed by the output of current static generators: everything gets prerendered to static markup, runtime JS only augments UX. In my case, the key breakthrough was reducing everything to arbitrary constrainted emitters with a topological sort. -- The build uses a GraphQL database to store the results (Prisma/Postgresql because it's great with Typescript). The whole site is defined by arbitrary Data Sources that read from 0+ other sources and write 1+ unit of data in the database. A source can do anything, the only constant is it must define at least one thing in the database. For example: - list of files generated by the webpack build of a specific runtime js - JSON version of a specific page - http response to serve when a specific url is requested --- A topological sort uses the constraints to deduce in which order to render data, for example: - a page showing the 5 most recent articles can't be rendered before the articles themselves - the french translation of an article cannot be rendered before the settings of the french website are defined --- This way, a specific page (or type of pages, or even every page of a site variant) can explicit state it needs a specific js runtime, and the build knows to bundle it before any page that needs it. Something like a cookie banner would be used by every page whereas a 3d model viewer webcomponent would only be used in specific pages. --- You end up with a static site as consequence of rendering the "http response to serve when X page is requested" sources, which in turn called all the other sources it required. The resulting database could even be available in production for dynamic pages that cannot be pre-rendered.

Cthulhu_ 5y ago
How does your solution compare to Gatsby?
- wildpeaks 5y ago
  It fits my requirements, Gatsby didn't.

slver 5y ago

I see this tool as peak micro-intelligence and macro-stupidity of the whole web dev community. The tool itself is very interesting, and congrats to the authors. But needing this tool shows that in general we have no fucking clue what we're doing.

null4bl3 5y ago

I like how many comments mention "you don't need a framework" and then mention how they wrote there personal bloggers in pure whatever. Frameworks is not just some hyped up abstraction layer. Advanced frameworks offer advanced functionality for advanced projects. They really do. They have standardized certain ways of doing things, structuring complex web applications and solving problems. I completely agree about using a framework to build a personal blog is overkill in many ways, but don't blame the framework for that. Just like you shouldn't blame the saw for being bad at hammering in nails.