After many months of development and testing, we're excited to announce the 1.0 release of AnalogJS! The 1.0
release includes many features that help developers ship websites and applications, faster, with Angular.
This release marks the first major release of Analog, giving developers a more stable starting point to build with Analog. We will continue getting feedback from developers that helps us continue to improve and innovate on the project.
Features āļø
Analog is the meta-framework built on top of Angular, powered by Vite, a next generation open-source build tool, and Nitro, an open-source server engine framework. Here are some of its features, including:
- First-class support for the Vite ecosystem (Vitest, Playwright, Cypress, and more)
- Filesystem-based routing
- Support for markdown pages and blogs
- Support for API/server routes
- Hybrid SSR/SSG with sitemap and RSS feed support
- Supports Angular CLI/Nx workspaces
- Integration with tRPC for type-safe server interactions
- Server and deployment support
- And more!
Contributions and Community š¤
AnalogJS would not be where it is without a team of core contributors and collaborators.
Robin Goetz
Marko StanimiroviÄ
Luis Castro
Chau Tran
Joshua Morony
AndrƩs Villanueva
Also, thanks to the 80+ contributors to the project, whether through code, documentation, tests, or even just trying out the project.
The project already has surpassed 2000 stars on GitHub, 500+ members on Discord, 1000+ followers on Twitter/X, and was accepted into the first GitHub Accelerator Cohort.
If you'd like to take Analog for a spin, check out this blog post on Building a Blog with Analog and Angular. If you want to get involved in the project, check out the GitHub repo.
What's Next
We are continuing to make building fullstack websites and application with Analog and Angular as seamless as possible, and extending the Angular ecosystem through integrations with Astro, Nx, Vitest, Storybook, and more.
We have also introduced a new Single File Component format in Analog for authoring components and directives.
Below is an example of a hello.analog
file:
<script lang="ts">
import { signal } from '@angular/core';
const count = signal(0);
function increment() {
count.update(total => ++total);
}
</script>
<template>
<h2>Hello Analog</h2>
Count: {{ count() }}
<button (click)="increment()">
Increment
</button>
</template>
<style>
h2 {
color: red;
}
</style>
What started as a .ng
file extension for components and directives using Angular has evolved into the Analog SFC, along with features including support for auto-imports, inline markdown templates, page routes, and more. We are continuing to iterate on this approach, and exploring options to enable this format in Angular applications as the future of Analog progresses.
We've already received very positive feedback, and even further development on supporting this format, including an IDEA Plugin for the Analog SFC that's available in the EAP version of WebStorm. Thanks to Jan-Niklas Wortmann and Piotr Tomiak from the JetBrains team for the initial development of the plugin. You can also contribute to the plugin on GitHub.
Partner with Analog š¤
We are looking for companies to partner with on the Analog project to support development of the project. Thanks to Snyder Technologies for being an early adopter and promoter of Analog, Nx for joining us as a sponsor, House of Angular, and many other backers of the project.
Find out more information on our partnership opportunities or reach out directly to sponsor[at]analogjs.org.
Join the Community š„
- Visit and Star the GitHub Repo
- Join the Discord
- Follow us on Twitter
If you enjoyed this post, click the ā¤ļø so other people will see it. Follow AnalogJS and me on Twitter/X, and subscribe to my YouTube Channel for more content!
Top comments (28)
Congrats
Thanks Ben
coool š
Congrats!
Thanks Nick!
Congratulations šš I'm excited where this goes š„³
Thanks Konadu š„³
Congrats!š„³
What are the issues the AnalogJS solves? Is Angular really that bad?
I fully understand that poeple where not happy with what the web provides natively. Using only HTML and CSS gives you strong limitations. As nobody was able to build a better system that runs natively in the browser, they built some "frameworks" to add all the missing features. This was powerful, but partly bulky and overcomplicated. And many frameworks solved one issue by adding two new issues. Finally, things got more complicated than they have been before.
So, what is the clue in building meta-Frameworks? IsnĀ“t this building a castle on a weak foundation?
The web fundamentals are powerful but just difficult to build complex systems without a level of abstraction...in much the same way that C abstracts something like assembly.
Meta-frameworks are just an extra level of abstraction so we don't have to reinvent the wheel and they can evolve separately and avoid release coupling with the underlying framework (Angular in this case).
React and Angular are not a "web fundamental", they where created about 15 years ago ontop of CSS/JS to add a new level of abstraction to make handeling complexity easier. But as we know, they both do the job, but add their very own level of complexity. And often enough you have to deal with the quirks of the foundation anyway.
Angular brings a lot of overhead (technically and mental) which pays back on large projects (hopefully). But trying to abstact away the complexity of these Frameworks by adding a next level seems to be the wrong way. If Angular does not fit your needs, why not use Svelte or Vue instead?
How easy is it (or will be) to migrate an existing Angular app to this?
Also - will it be possible to use .ng in an existing Angular app with incremental adoptions without changing the way you deploy and serve your app?
Congratulations!
What does "Filesystem-based routing" mean?
"Routing" refers to the application displaying things based on the URL. For example, it might display a
<shopping-cart>
component for the URL path/shopping-cart
(we're glossing over some details here but this is what it comes down to). To be able to do this, the application needs a definition of how it should respond when it detects a specific URL. The part of the framework responsible for this detection and taking action based on it is called a "router". It uses a concept called "routes", which define what the router should do for a given URL path.Without filesystem-based routing, you have to define routes manually. You can read more about how this is done in Angular here: angular.dev/guide/routing/router-t....
With filesystem-based routing, the tooling (Analog in this case) will generate these routes for you based on a structuring and naming convention according to which you structure and name the directories and files in your project. You can read about Ananalog's conventions here: analogjs.org/docs/features/routing....
The main advantage of filesystem-based routing is reduced complexity for the majority of cases. Removing the need to define routes manually for every page (or other "routable" piece of UI) takes away some friction by reducing the amount of steps you need to take to get the result of your code on the screen. Defining routes manually can be an error prone process, and keeping the way routes (especially dynamic ones) are defined consistent over time can be difficult especially with multiple contributors.
IsnĀ“t this what most web servers do by default? If I setup Apache on XAMPP, my files are located in
C:\xampp\htdocs
, which is the root directory by default. Any subdirectory is just routed according to the file structure, soC:\xampp\htdocs\test
can be reached at myserver/test.One disadvantage of simply exposing your file structure is, that you are limited to just that structure. What happens to external ressources? Assume you set up some data on a headless CMS, you would not want the user to see all the details.
So, maybe Analog is just going "back to the routes"?
Well, not really. You need to configure your server properly. The reason why you can just put your files in that path is because server (Apache) has been configured to index whole directory.
Exposing the whole tree would be to allow whole directory to be accessed by anyone, which is what is typically done by servers that are just serving files for download - otherwise yes, it would be a security risk and is not recommended. In most cases we use more granular approach, and allow serving files only from a single directory (typically called assets, static, public or something like that).
Sorry, I misunderstood the concept. But even after reading the description I have no clue what the advantage is...
Well, the advantage is that you don't need to write some code to define routes but they're automatically generated by analyzing file structure - this also means finding a file for certain route is easier. I personally like the approach of defining routes explicitly, but to each their own.
Nice bro keep coding
nice