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

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

​@@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

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.

@@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

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)

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

@@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.

​@@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

@@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?

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

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

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

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

@@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.

@@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 ?

@@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.

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

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?

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

​@@kylerjohnson988 Exactly

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?

Useless comment

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