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 he...
For further actions, you may consider blocking this person and/or reporting abuse
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
Congrats
Well, if there's one thing we need more of, it's JavaScript frameworks.
Why, why, the same file... bad things from ReactJS
Congrats
Looks very promising!
Congratulations
👍🏼👍🏼
cool