Angular VS astro

The new https://angular.dev site: docs, tutorials, guides…

Angular updated to v17, new docs site

You can get proficient in Angular using the new docs in https://angular.dev I think I can say the same thing for React https://react.dev

Angular, developed and maintained by Google, is a comprehensive, opinionated framework that comes with everything you need to build robust and scalable applications. It uses TypeScript, a superset of JavaScript, providing static typing for enhanced code quality.

Angular recently introduced the Standalone Components, which is a new way to write Angular components without the need to create a module. Angular team created a migration script that does this automatically, and it's using the Typescript Compiler API.

Rest Endpoints Feature Request

[^1]: That’s AngularJS 1.18, the original[^2], not Angular 16.9

Angular - A popular web application framework maintained by Google. Website: https://angular.io/

blocks for providing conditional rendering and rendering the items of a collection (RFC): these are alternatives for the NgIf, NgFor, and NgSwitch directives

I made some contributions and I'm working on three Angular Issues, take a look:

I was creating a Astro component MastodonStatus, something like:

A whole project might be released as a server or framework. Frameworks like fresh, and astro) both have had things deep within them that I've wanted to reuse, within fresh it's the esbuild configuration, and islands functionality, and within astro it's the rendering of astro files themselves.

I would very highly recommend Astro [0]. Astro lets you write React-style components that compile to plain HTML/CSS (unless you _actually_ need JavaScript). My personal site and blog [1] is built with Astro

Here's their tutorial on building a blog with Astro: https://docs.astro.build/en/tutorial/0-introduction/

[0]: https://astro.build/

[1]: https://sjer.red/ source at https://github.com/shepherdjerred/shepherdjerred.com

Astro

As my website is just a bunch of static content, with only few interactive components, I chose Astro. And if I need to add something fancy, I won't have troubles adding it. For example, "Share" button is a Preact component (even if it didn’t have to be).

Local CMSs are the ones that are mostly file-based (like Statamic or Astro). This means that you can edit everything locally and deploy the data. This way, our CMS is more secure, but on the downside, you have to have a local server working, and you might experience more conflicts, especially when two people will work on the same article (although Git might save you from many of those). It also means that there is a higher learning curve. A remote CMS works somewhere on a server, and most users don't care how.

I've recently decided to recentralize all my articles on my own blog instead of publishing them to Hashnode (nothing wrong with Hashnode, just something that I had wanted to do for a while) and since I have a wondeful brand new personal site built with astro I decided to take advantage of their collection system and the new experimental (at least at the time of writing this article) view transitions api to build something a bit more tailored to what I like. Here's how it went.

I've previously written about Service Worker Side Rendering (SWSR) in this blog, when I was exploring running Astro in a Service Worker.

Astro is my personal favorite: https://astro.build/

It's like an SSG where you can write templates with modern components frameworks, and write content in MD / MDX. No JS is shipped by default, but you can opt in to it for interactivity.

There are many high-quality templates, but making your own custom styling and layouts is easy, and you can write CSS in whatever way you like.

MkDocs and Jekyll are more for docs in my opinion, but Hugo is pretty good if you hate javascript.

I would recommend Astro over 11ty 100% of the time, though. Both are JS, with slower build times etc than with Hugo, but Astro integrates better with the rest of the ecosystem.

Gatsby has apparently fallen off a cliff, wouldn't even consider it.

Congrats on the GitHub program! Very cool.

I just had a fresh read of the docs and htmx is refreshingly, gloriously simple. So natural, self-documenting, and well thought out. It _does_ feel like a natural extension of html.

To me, the only "missing" piece of htmx is a component model, but for anyone looking for that, htmx would pair amazingly well with Astro[1] which allows you to define and use html components without the runtime overhead of say Vue or React.

[1] http://astro.build