What happened to Analog's experimental ".ng" format?

My Angular course: angularstart.com/
A little while ago we talked about Analog's experimental .ng format that allowed creating Angular components with a component authoring experience that more closely resembles something like Svelte or Vue
This video is a follow up to cover what ended up happening with the format.
3 months of WebStorm free: www.jetbrains.com/store/redeem/ (use code: K4UQV-BPUNF-K5B9S-CQF6V-A6BCA)
Analog Discord: chat.analogjs.org/
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Want to build mobile apps with Angular?: ionicstart.com
0:00 Introduction
1:06 Small changes
1:19 Multi-file components
1:42 Import attributes
1:58 Markdown support
3:14 WebStorm Plugin
3:41 ESBuild
3:58 Conclusion
#angular #analogjs
- More tutorials: modernangular.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

Join the newsletter: mobirony.ck.page/4a331b9076

[@hundvd_7]

3:15 The plugin is third-party-aka not JetBrains You can even see the warning popup at 3:22. And you can see (under the plugin's title) that the developer is not JetBrains s.r.o. or whatever

[@JoshuaMorony]

​@@hundvd_7 I don't know the specifics of the WebStorm plugin ecosystem/the early access program but it was built by Piotr Tomiak from the WebStorm team: twitter.com/PiotrekTomiak/status/1756960692203094274

[@darwinwatterson1732]

I don’t understand the need behind this. Why do you change the syntax to something different? I think that having to learn a new syntax just to do the same I can do with Angular but in a different way has no benefit for me

[@glimpsee7941]

We get better and better at reinventing the wheel

[@ChrisPerko]

Plugin is working on 2024.1 🎉 I'm loving this update, and working to update my website to using the new .analog files ❤

[@CptProv]

I just studied Vue and I love this! I love vue project structure approach but I was still missing some core Angular features like rxjs. This mightr take the best of both worlds, thanks!

[@Alex-vg4es]

You can always install the rxjs library in your vuejs project manually, but honestly I'm glad they never did. As soon as it gets more complicated, it will be hard to understand the workflow of the code.

[@CptProv]

@@Alex-vg4es yea, I tried but I didn't like how rxjs worked within Vue. I I want to create a more "reactive" way of looking at other methods execution I use watchers and If they are within a store create an onInit action to start the watchers in the store. But I'll be honest, RXJS and reactive programming as this channel teaches is great

[@estebanmurcia8451]

Man i was literally looking for more info on this yesterday

[@Abelfubu]

❤I love it! Analog is getting awesome!

[@danialcaraz5383]

The best part is to mix Angular and Markdown code, that's mind blowing.

[@Quxer0721]

This is interesting, but why bring syntax from another framework (Vue here) to Angular? Isn't going with that framework better instead? Getting support for markdown is neat, but other than that it seems like adding another layer of transformation for builder. Do you have any advantages with this format?

[@JoshuaMorony]

Because the component authoring syntax is not what defines the framework, in a sense the component authoring syntax is like the frontend/interface to the actual framework features - we could make the syntax almost exactly the same as Vue or Svelte or whatever else but it wouldn't make Angular the same as those frameworks. So, imo, if the Vue or Svelte approach is a more intuitive/less verbose way to achieve the same thing then it is compelling to go with that solely for the reason of simplifying the syntax (regardless of whether we get any other features/benefits on top of that)

[@ChauTran-xc4ld]

Some of us have more fun working with Angular now, so I guess it’s an advantage to us 😅

[@deefdragon]

@@JoshuaMorony "Because the component authoring syntax is not what defines the framework" I fundamentally disagree. The syntax is quite literally half of what makes a framework. The other half being how it pulls things tegother and passes data arround sure, but IMO the half that most people interact with on a day to day basis as they *read the code* is the syntax.

[@JoshuaMorony]

​@@deefdragon I agree that it's an important part, which is why I even care about this format in the first place, but in answer to e.g. "why not just use Vue/Svelte" if the Angular components look like Vue/Svelte, it's because the component syntax doesn't make it the same as those frameworks. And personally, I struggle to see how the Angular component authoring syntax specifically is a value add over other approaches apart from that it is familiar - i.e. that "@Component" and "export class" are what "define" Angular

[@Quxer0721]

@@JoshuaMorony I disagree with you. Syntax is a part of language/framework not some sugar on top. I prefer C# over java and one of the reasons is its syntax. I tried both at university and chose to purse a job with C# as primary language. Another thing is that most frameworks are so similar than even syntax is 95% comparable. For example when you have lifecycle for components: - svelte 5 - $effect - react - useEffect - vue - watchEffect - solid - createEffect Then few questions come to mind. If all of those frameworks are so similar, why would someone want to switch to another? If only syntax prevents new people from adopting angular in their projects, then why not get into another framework with prefered syntax? What does angular bring that other frameworks don't? Don't get me wrong, I'm not against changing anything behind framework. Without that we wouldn't change angularjs to angular. But we need to ask those questions to not lose existing adopters of a framework. As someone, who is more of a backend minded person I like structure of angular components. They are similar to what I have in a backend, so there is a little to no transition while switching. At the moment I work with react in my job and tracking, where what is is difficult and I need to adapt to differences. That is why most people could prefer existing structure. Currently I'm exploring different frameworks as my side project and I see an apeal of this vue/svelt like syntax. My only concern for adopting it in angular is getting swelled up at build or runtime stage. Other frameworks were design with those syntaxes in mind so they don't have to get another compiler step. Or maybe you can tell me if this new syntax would be placed instead of existing compiling step?

[@ThompsonEdolo]

Hey Joshua. Awesome video. I was wondering if you could talk about how you handle authentication and authorization in Analog.js.

[@karamuto1565]

I am actually pretty fine with the way angular can used right now. This looks pretty cluttered to be honest

[@chaos_monster]

0:30 It was not all because of the analog extension format. It was about the blaming of those who didn't like the suggested format as "greedy consultants" and more.

[@tibsou]

Whether it's a framework or history, they seem really good at rewriting things.

[@AbhinavKulshreshtha]

Personally I would like .analog format to become available as independent module. In my company, there is no way we would be allowed to replace company scaffold with analog, if there is an node module which would allow us to use .analog files within our own scaffold. It would be integrated quickly by us.

[@JoshuaMorony]

There is a decent chance of this being possible if the esbuild plugin mentioned toward the end of the video ends up happening

[@ChauTran-xc4ld]

@@JoshuaMoronyeven if the plugin is possible, it would still require a custom esbuild builder to use the plugin.

[@LarsRyeJeppesen]

It"a still there

[@sivuyilemagutywa5286]

I am personally not a fan of this format and is the reason why I use Angular, instead of other frameworks. But it's cool.

[@JoshuaMorony]

Of course if that's your preference that's cool, I am curious though what aspect(s) of the typical authoring experience in Angular it is that you prefer

[@sivuyilemagutywa5286]

@@JoshuaMorony To be fair, I also use Vuejs for small projects like chrome extensions and astrojs for static sites. but I don't like the syntax. In Angular I like the class based syntax, I hate SFC, Typescript is a first class citizen, Services, ReactiveForms, Routing, Http and the CLI. This for me is enough to keep using Angular. I also like rxjs, though signals are the greatest things added to angular. Thanks to your videos about rxjs, I was able to learn a lot of things.

[@JoshuaMorony]

@@sivuyilemagutywa5286 again not trying to change your preference here, just want to understand viewpoints - with the .analog format you can still have all of these things with the exception of "class based syntax", is there anything specific about using class based syntax you like versus ?

[@sivuyilemagutywa5286]

@@JoshuaMorony I just like the class based syntax since it's just a Typescript file. Besides I don't like having html and javascript in the same file, unless it's a small component. For small projects I can tolerate it. On a separate note, I've been following Analogjs with interest, though I haven't had a chance to use it yet.

[@TayambaMwanza]

​@@sivuyilemagutywa5286 I think this is the most reasonable take, we all have preferences.

[@TheSaceone]

The format no one asked for and no one needed

[@kylerjohnson988]

Many people have asked for a simpler, less verbose component authoring experience for years. There has been open issues about parts of the component experience since 2016. One of the most common complaints about Angular was its component authoring experience because it’s literally the most verbose of any modern front-end framework. Have you been living under a rock?

[@user-ed2zi5qp9g]

@@kylerjohnson988Well, then use React. We use Angular (me at least) because we really like to have logic/template/styles separated

[@jaybee6382]

​@@kylerjohnson988 Exactly

[@JoshuaMorony]

EDIT: Comment seems to have disappeared but this was in response to someone replying to use React because the ability to separate template/styles/logic is why they use Angular You can do this with this format as well, e.g: defineMetadata({ templateUrl: './my-template.html', styleUrl: './my-styles.css' }); Is there anything else you feel makes the standard Angular format more compelling?

[@HoNow222]

Meh.

[@BachiMjavanadze]

I like '.analog' format. Hope it will be default file format in Angular

[@dracula5752]

just use vue lmao only framework that use classes let's remove it

[@PauloSantos-yu1tn]

Useless format.

[@kylerjohnson988]

Useless comment

[@PauloSantos-yu1tn]

@@kylerjohnson988 just another syntax sugar will not solve anything. Js if full of this useless features. Sorry man. It's the true

[@EtoBARAKUDAvasa]

omg, why angular devs doing this? Angular views like a toy by this format, where OOP principe here? all in one file , view like shit for shits-cooding.