A "simplified" approach to Angular components?

[@JoshuaMorony]

POLL: Please do not reply to this comment directly, post a new comment beginning with your pick and then any comments you want to make (e.g. "1 - stay away from my classes") 1) This format should NOT be pursued at all 2) This format should be pursued, but only as something OPTIONAL through AnalogJS 3) This format should be pursued, and it should eventually become the DEFAULT for Angular itself 4) I don't know/I'm not bothered either way

[@Daranix]

2- I think it could be a good syntax to attract people who use Svelte or Vue.js, you feel that what is inside the script tags is "a single execution to define all the logic of my component" and the mind thinks more in working in a declarative and not so imperative way, but at the same time I think that having things like metadata that appear in a "magical" way can be confusing, I think that one of the main benefits of annotations is that that metadata can be typed , and without having to go to the documentation you can know what options you have to add to the metadata, something similar happens with lifecycle hooks. I have mixed feelings XD

[@JoshuaMorony]

@@Daranix there has been some progress in this regard already, instead of exporting metadata the currently implementation now uses a defineMetadata({}) call that has typing

[@sulaimantriarjo8097]

2 - this is way great, it brings back developer to vanillajs-like. But, I think it should only be in analogJS. because analogJS is metadata framework for angular that can consist backend as well (cmiiw). this way looks cleaner and simpler. But I wonder how about the implementation of life cycle hooks, services, etc in this style.

[@georgivasilev3417]

2. especially if u are used to the old way of creating components. and lets be honest about it. most of the time you would use ng g c rather than creating it from 0 .

[@AllanLange]

2 - when first transitioning to Angular two and half year ago I found the amount of boilerplate and setup intimidating. I came from a company that used Aurelia and as I recall, it was a bit more simple than Angular, however not to the degree of this format. I definitely think this format would help the adoption of Angular to grow as it makes it a lot simpler.

[@joshuadc316]

2 - Keep my ts/js, css and html separate, I prefer it this way. It follows the principle I like best which is, each file has a single purpose or responsibility. This kind of clutters them together, which really bothers my OCD lol

[@codearmadillo]

Well like in Vue, you could just import CSS. To be honest as an Angular developer, it just becomes cumbersome after some time

[@nahuelleiva8460]

I would go for 2. I like the idea that Svelte/Vue and Angular devs can (potentially) have the possibility to switch from one framework to another without too many complications. This can improve Angular's learning process for new devs, I like this.

[@antjones2281]

1 - I don't see the improvement. As it is when I generate a component I get an html file which is just html and my ts file looks the same as your new ts file minus the template tag. I agree for sfc's writing raw html is better than having to use a template string though. but I prefer to keep my templates separate anyway.

[@deefdragon]

2. as someone who prefers seperation of responsibility, this looks like a terrible alternative, but I also respect people who prefer this style getting to try it out.

[@ImperiumLibertas]

One of the greatest benefits of Angular is the strict adherence to separation of concerns. The class based approach, specifically the component selector and component logic existing in a separate file from the template offers massive advantages while maintaining code. Trying to make Angular templates more like React/JSX isn't going to help developers. I see this as arguing that we need to make Angular similar to other frameworks/libraries to appeal to more people without any other major benefit. We can explore ways to reduce boilerplate code which seems to be the main concern without losing one of the greatest features of Angular. If you want Angular features in React, go add them to React. Don't try to change what Angular is at it's core just to make it more like other frameworks.

[@Karamuto]

I agree. I already hate it when style/template/typescript are not divided into different files.

[@JoshuaMorony]

This is one of the sentiments I strongly disagree on - the idea that Angular at it's core is about its ability to separate logic/template/styles into separate files. I get that being a feature people like (personally I use SFC in Angular anyway, and preference it partially for the DX of the authoring experience and partially because I think it encourages better architecture). But I don't think that is the key part of this proposal anyway - it's not the plan at the moment but technically the new proposal *could* allow for separating code type by file. If that were the case, would you still not like the idea?

[@bullettime2808]

Completely disagree, separating UI and logic was common in the old MVC days but this is not how a component-based framework should behave. In component-based frameworks, UI is derived from the logic which makes them highly related and should be placed together

[@ImperiumLibertas]

@@bullettime2808 they are tightly coupled but not derived.

[@ImperiumLibertas]

@@JoshuaMorony I work in a large enterprise environment with dozens of teams working on a single project. It would be a nightmare to get some of the less experienced developers to adhere to a separation of concerns pattern.

[@chaos_monster]

I would like to quote Jay "I don't hate the angular authoring format. I can see why some want it changed or think it can be improved (everything can be improved!), I am just focused on other things. On the list of things that slows us down (generally) the authoring doesn't even register." This fits perfectly

[@JoshuaMorony]

I don't disagree with Jay, but it's also not how I view the motivation for this. I see the main goal of this to make the framework more appealing/approachable/marketable to new devs, not improve the productivity of existing Angular devs (although personally I feel like I would be more productive with the new format, but that's a much more marginal kind of benefit)

[@chaos_monster]

​@@JoshuaMorony "to make the framework more appealing/approachable/marketable to new devs" you are not the first one with this argument. And as long as I do not see evidence (I am data-driven guy, so representative surveys in this case - not my "friends agree with me") for this I don't think it holds IMHO. Many of the "we need to improve Angular" topics (like this) stem from exactly this argument, but again I wonder where that comes from

[@JoshuaMorony]

​@@chaos_monster I think getting good data on this would be difficult - I do think it stands to reason though If we consider the target audience existing FE devs, then I think it's reasonable to assume most would prefer the syntax that is the same as/similar to basically every other popular FE framework right now If we consider complete beginners, then I think it's reasonable to assume they will find the syntax that basically looks like basic HTML/CSS/JS more approachable versus needing to understand the role of the class and the concept of a decorator Even if we consider backend/Java devs which would be a prime candidate for preferring the class approach, I doubt they are going to be confused/intimidated by the Svelte style Then we also have anecdotally the discourse about Angular (outside of Angular devs) which often centres around it being old/legacy/complicated. I think the component authoring has a lot to do with that perception (and yes, I know "I think" statements are not hard data)

[@chaos_monster]

​@@JoshuaMorony here is where I strongly disagree with your chain of arguments. First all your statements are assumption, and I get that getting good data is hard, but you ignore the reason some frameworks have chosen certain ways and ignores the fact of compilation totally. You ignore that not even the popular frameworks share a common approach (vue and others vs jsx based vs function based components and so on). So which one is the "right" one? Secondly the current authoring format has a HTML and a CSS file, let's be generous and consider the TS file a JS file, so your only "problem" is the decorator (which by compilation is actually an annotation) and the class approach. I do agree that we could improve the metadata annotation, maybe with conventions. But the argument against the class approach is kind of weird as the custom element (a native JS API) is exactly the same...

[@darwinwatterson1732]

I would go for 1. If AnalogJS is focusing on providing a better DX for new developers, I think new developers should start learning Angular by learning Angular, not AnalogJS. If you use AnalogJS is because you already know Angular (at least the basics) but I don’t think it is a good idea to start learning Angular using AnalogJS, because if you want to work as an Angular dev you need to know the Angular syntax, so eventually you will still need to learn the Angular syntax, so you will have to learn 2 different syntaxes, it is easier to learn first the Angular syntax, and then learn the AnalogJS syntax if you want for a personal project or something like that.

[@JoshuaMorony]

In the 2 days since I filmed this video massive progress has already been made here (including some changes to what was shown in the video) - it looks like this format is likely going to be added to AnalogJS (still no guarantees), join the discussion here: github.com/analogjs/analog/discussions/824

[@DavidSchmidt07]

3. I love angulars architecture and sveltes component authoring and this seems like combining both would be a big win IMO

[@TomOliverTurtle]

How do the lifecycle-hooks work with the script-tag approach?

[@JoshuaMorony]

Currently it supports supplying an onInit() and onDestroy() hook, and you can also import things like afterRender/afterNextRender as normal - I believe the view with this approach is that everything else becomes unnecessary with signals

[@sajon_]

I am going with 2. If people prefer it, then this will give them a way to use it, but for my personal preference I like the current way Angular keeps the template and style files separate by default. I always disliked how Vue and react has all their HTML and JS/TS and sometimes styles in the same file. I would really hate it if Angular goes this direction.

[@BrandonRobertsDev]

What if Angular changed the default to be inline styles and template? Having separate files will always still be an option

[@sajon_]

@@BrandonRobertsDev Same, would hate it if that happens. Obviously I can setup a project with different files for templates if that is an option, the problem will come when working with others. I personally like that there is very little variability in project to project in Angular.

[@kaydenmiller8156]

4 - only because there isn't a 5, I would be fine for this to be an option within core angular I just don't think it should be the default behavior when creating a component. I think it is a much simpler syntax for when working with small components but with larger HTML blocks I would prefer working in a separate file.

[@pankudev]

I want to say 3, but I also love my separation of concerns. It's one of my favorite things of Angular.

[@Netrole]

1 - The clear seperation of code into HTML/TS/CSS/Tests has always been one of the key strengths of angular in my view. It helps keep large projects organized and clean even with juniors and inexperienced devs on the team and under time pressure. React on the other hand is the exact opposite, html and JS are mixed together and it takes a lot of conscious effort to keep it clean as projects grow. Then throw in inexperienced devs and some time pressure, and you start getting absolute spagetthi. This isn't as bad as the chaos in React, but it is a step in this direction, and i see no benefit to it. It is a bit less boilerplate code, that is generated by scripts anyway, and it might look neat in these small demo components, or small components like single buttons or core UI elements. But for large layout controlling components i can't imagine this to work out well. You could argue to switch between the styles based on the type of component and limit this to small basic components, but at that point I'd rather be consistent across the board and use the same style for all components. Same reasoning as with the seperate HTML file for me. Might be overkill on small components with 15 lines of HTML, but i rather keep it consistent across the project and i want the seperation on big components

[@paulh6933]

3, maybe this isn't the final iteration of the new format, but it is a good start. Changes have already been made for standalone (which should be the default and only opt out if needed), template syntax (if, else, defer). So the journey has already started into making ng part of the crowd, not something that sits by itself. Ng already has it's distinguishing features, syntax does not need to one of them. Also one last comment, by making it optional, all we do is making the code base bigger.

[@jaredwilliams8621]

1. The separate template and js files are one of my favorite things about Angular. I also feel like Angular doesn't need to be looking at another dramatic shift how it does things. At work, my team juggles around a dozen smaller Angular apps. We don't have time to update to use the latest template syntax, or switch over to use the newest revolutionary Angular feature. Rather than chasing after the next shiny thing, I would really appreciate if Angular slowed down and focused on more incremental upgrades. I would love to see more focus on supporting more ways to serve and deploy Angular code (ie allow more versatility in where files can be hosted, or allow for angular components to be added to non-Angular pages). I feel that there is a lot more value in these behind the scenes features than trying to make Angular feel more like React.

[@MonaCodeLisa]

2) This format should be pursued, but only as something OPTIONAL through AnalogJS For people that have not used Angular - yes this probably will be a cool improvement and might make it easier for them. For those of us that have been using Angular for a while - maybe chilling for a bit would be nicer, taking the time to get used to all the current changes before considering the addition of even more changes... Dynamic is cool, until it gets a bit too dynamic... There are still plenty of Angular developers adjusting to v16 and v17... The video is very nice :)

[@JoshuaMorony]

I appreciate the "can we just chill for a minute" sentiment lol - but any chance of this (or something similar) landing in Angular any time within the next year is slim to none imo. Still good to know if people want it to be in Angular itself, but for now if it's anywhere it's definitely just going to be AnalogJS

[@drsunshine5615]

@@JoshuaMorony Check out the latest post in the official Angular Blog about the Angular Developer Survey 2023 results. Looks like the Angular team will continue focusing on the component authoring format in 2024.

[@MonaCodeLisa]

@@JoshuaMorony thank you, good :) glad to hear, it does seem like a good idea - for later on :)

[@CodeZakk]

Also in the .ts file you can't use angular service extension in vscode which leads to not knowing how to interpret html auto complete on the .ts file of angular.that's why i don't use analogjs. May be the .ng file will solve this problem❤?

[@paragateoslo]

For the simple example shown here i definately agree that a script tag and template below is better. However the component decorator has quite a lot of config options, like onPush changeDetection, multiple css imports, selector name etc. So for a better discussion on if just scripts tags are better, we would first need to see solutions on how these configs options would work.

[@JoshuaMorony]

At the moment for any metadata that does need to be supplied you make a defineMetadata call within the script section - e.g. defineMetadata({ selector: 'p[highlight]' })

[@giniedp]

I'm going with 3. Love the ease of svelte and dependency injection of angular. Actually something in between 2 and 3. It may not be the default for angular but still an option within angular core.

[@xingfucoder2627]

I would like to maintain both options and only the 2) option OPTIONAL with AnalogJS. But seems like another framework is trying to remove TypeScript ???? And Joshua, what is your opinion about the standard we should follow to test this kind of new approach?

[@alexx855]

would love to see that!

[@sebuzz17]

4 - I'm used to the Angular class declaration thing, it has become natural but I really love the simplicity of Svelte so either way I'd be ok with it. Now as you said, it's more about the new devs so I guess the Svelte-type experience would be a plus.

[@peased22]

2 - while I’m not huge on too much logic and template code in 1 file, this forces moving logic into services which is architecturally proper in my opinion but hated by some. Also being able to use effect outside a constructor feels so much cleaner this way. You’ve convinced me I’m trying it tonight

[@AbhinavKulshreshtha]

I would love the .ng file for creating simpler UI components. This kind of component file is reason why I loved vue and svelte over react.

[@toxaq]

I’ve always appreciated the separation of concerns of the angular way. I think having two ways to do things is more confusing than beneficial. I appreciate the “new dev” argument but in the time of AI writing code and talk of needing less developers, is lower the barrier to entry down that low a net gain for the industry?

[@artyomnomnom]

Going with 3. I have a huge expecrience with Svelte and Vue and I really like the format.

[@blanktenshii_9554]

I don't really like mixing HTML and logic in a single file, it makes it harder to read and maintain both

[@WanderingCrow]

2 - I thought about 3, but I think making it optional would avoid frictions with people really against it. But I definitely like such approach, which resonate more with me, as I've known the early structure of web pages (which is why Svelte and Vue tend to appeal to me too)

[@TayambaMwanza]

Can you put 5, that the Angular tean adopts it as an optional format, its a pipe dream but good to know the sentiment.

[@JoshuaMorony]

I wanted to avoid too many option, my thinking here was that the "optional" approach is through AnalogJS i.e. that if you want to use this approach you use AnalogJS, whereas Angular remains as is. Hypothetically (big hypothetically lol) if the Angular team did adopt this, I think it would go like everything else we have seen recently - it will be optional since that is how the Angular team approaches backward compatibility, but it would probably become the default (otherwise they probably wouldn't pursue it in the first place)

[@nicoscarpa]

That's a nice idea to lower the barriers for new Angular developers and for semplifying the construction of simple apps. It would be interesting to see how a "real life" component would look like with this approach. Though, I do like the structure Angular "suggests" (impose) for building components, since it forces the developer to organize the code in clearly defined building blocks, hence promoting discipline (which is very important in large-scale projects). I think that the classical approach might still be preferable for enterprise/highly-complex applications, but I can see this new approach fit into some areas of a large-scale app or being used for fairly simple components.

[@DerHerrGammler]

2 - I think it could be, as you already mentioned, a good starting point for new angular devs but I also think that its only veryn good usable for simple components. If you start writing bigger componnents where I like to also plit them up in ts/html/scss file I prefer the original Angular way of keep things in their own files. But when it is ready to use in analogjs at some point I will try it out to get a better image if how it looks and feels to write components in that way

[@JakeArefyev]

polymer is resurrected?

[@boris8983]

2 - I really struggle with this approach since the separation of CSS, HTML and TS (logic) is a huge DX improvement for me. Now imagine this new approach with tailwind and a really big and complex component -> 1000+ lines of horror incoming You mentioned in one of your videos about declarative code that it looks more complex at first in little projects but at a bigger scale it shines (and i totally agree). IMHO this looks cool for small components but a soon as things get bigger the DX gets worse.

[@JoshuaMorony]

I don't see this aspect as a problem though (I already use SFC currently with Angular) - to me if a component feels too large as a SFC it implies that the component is doing too much and would be a good candidate for breaking it down into smaller parts (e.g. if you had hundreds of lines of tailwind classes it's probably a good idea to break that thing up into one or more separate ui components)

[@Kanexxable]

I'm pro 3). SFC's make it easier to do do compilation then classes do. It could lead to the point where people never have to do double imports ( Which is one of the great burdens of using the framework ). People don't have to be good OOP users to use the framework they can structure their logic the way they want.

[@jhadesdev9576]

I hope this goes forward, and hope that there will eventually be a CLI migration go convert to this format.

[@user-dq3zg6or2n]

Yes I'm with it. It is a welcome development. Much more intuitive with regards to new learners.

[@tanishqmanuja]

3 - Feeling excited about this much simpler syntax. But this should happen only after all the API's become functional (inputs etc etc) and Zoneless is introduced.

[@alexpablo90]

4. I don't have a defined idea. I think is good for new devs and it becames easier for them but, maybe it'll lost the kind of 'structure'(not sure if it ttge best word). Also, having two different ways could be more complicated to migrate and keep it in a medium/long time. Summary: I need more info and experience with it. Great video 👍

[@darthvader4899]

Like svelte?

[@Justjames283]

3) I don't know about becoming the default in Angular but class based and this new format should both be supported in Angular core

[@marflage]

I would go for option 4. In my opinion, if there is a way to achieve separation of concerns by utilizing separate files for each responsibility then this syntax is the way to go. However, if separate file creation can not be achieved with this syntax, then this should not be introduced at all. I need more information on this. If the code for any of the .html, .ts, .css files increases, maintainability will become very difficult. Scalability is a real issue and should be accounted for every time a change is proposed. SFCs are already possible because of the meta data in the decorators. I believe the Angular team should focus on reducing the TypeScript code required for creating a component rather than merging the .ts, .html, and .css files' code. I do like the simpler syntax, but I can see the its limitations.

[@habibhadi]

Main reason why I use angular because of separation of concerns which means html, styles and logics are in separate files. Also, class based component allows implement oop as well. This code looks like just react, vue. I have no hatred against them but I think only angular allows developers to use several design principles. They should keep it that way.

[@RodrigoSalesSilva]

1 - I considered option 2, but there isn't enough reason to pursue this approach. I genuinely don't see a 'problem' that needs solving or a real improvement by adopting this approach, apart from just introducing another way to accomplish the same task. This would undermine the goal of 'simplification' because new users would encounter 2 or 3 different methods to achieve the same outcome, making everything more complicated.

[@elcocodriloazul]

If you are going to do this, you may as well switch to javascript/react.. 3:35 My biggest worry is CSS...is it going to be separated in a file or mixed with the code...It could be an improvement if the separation of CSS is achieved. An example of another method also within the code? Also why put "script" open and close tags. Not needed extras me think...I want to see several methods and how they get called and how the CSS is separated. I am all for improvement....

[@aravindmuthu5748]

vue or svelte, react is different

[@JoshuaMorony]

I have seen this a lot, but I really don't see why people say it (that a change like this would basically turn Angular into React/Svelte/Vue/etc). Let's assume Svelte/Vue instead since this format more closely resembles that, but even so the particular approach to component authoring is such a tiny fraction of what the framework provides overall. This change would make Angular like 1% more like Svelte/Vue.

[@lukebennett3189]

@@JoshuaMoronyfrom my perspective this seems like change for the sake of change, but I’m also a lover of OOP so I quite like the current syntax as it more closely fits the mental model I have around c# which is my preferred language. All the new improvements are nice but if this were to become the new default for angular then there is going to be a lot of waste / rework needed on older angular applications if all new devs only learn this “simplified” style

[@ImperiumLibertas]

​@@JoshuaMorony if you don't see why people say it then you need to look further into what makes Angular, Angular and why it's better/different from other frameworks. Changing something for the sole benefit of being similar to other things isn't a virtue. Angular components are superior because they offer something the others don't; separation of concerns.

[@ImperiumLibertas]

I love that you mentioned CSS. I've had conversations with developers in the past about HTML/CSS/JS and why each are separated into their own units. It's not just a language consideration since HTML can embed all of them. Separating the functional, view, and style code into their own parts defines clear responsibilities for each which is exactly what the components/template approach provides in Angular. It is the primary reason I dislike JSX based libraries like React. It's already difficult enough to try to get engineers in an enterprise setting to put code in the appropriate places let alone having everything share a single file.

[@djbeallable]

3 - I always liked/envied this approach in Vue and Svelte

[@JPeetjuh]

I like the new syntax, but the one thing that stops me from being thrilled about it is UNIT TESTING. With Svelte, it's cumbersome *at best* to unit test components. Most articles/videos demonstrate unit testing by rendering the DOM, which is not UNIT testing. I want to call functions directly on my component. If this new Angular syntax supports this, then let's go. Until that time, I'm a class-syntax fan.

[@JoshuaMorony]

I don't think this will change anything in this regard - would need confirmation on that but this format works by converting the contents of the .ng file to a normal Angular component, so I assume you could just "import MyComponent from './wherever'" in your test and do whatever you usually do

[@fahadgaliwango4502]

5) optional to angular

[@Maestro14Maiya]

I will go with option 2. The current angular implementation is fine

[@michaelsmall97]

2. Seems like a nice option for smaller components.

[@adambickford8720]

I already code in java so angular becoming a 'late to the party w/a jankier offering than everyone else' framework feels poetic if not pre-ordained.

[@Oelpfanne]

Back to html-javascript/typescript-mix again :D

[@endlacer]

mh tbh, does anybody really write their components themselves? I only use cli commands for generating components services ect

[@ankurdutta3277]

I love svelte for this syntax and it is my go-to to build personal projects but I don't want it in Angular. At work we don't want to hire devs and teach them our way of doing things. We choose Angular for main production projects because you don't do things in 100 different ways. It helps a lot in maintaining big projects. Even if it does get approved in the future, I hope there is a configuration flag that allows me to disable it.

[@mfpears]

I'd like Astro-like syntax. Just separate them with a `---`. No need for indents

[@JoshuaMorony]

Interesting thought - haven't considered that, but my initial reaction is that I like it. It seems more "honest" in a sense (e.g. the script tag isn't serving an actual function in the end result). One argument I do find convincing about having a tag though is the potential to use it to specify other formats (e.g. ) - not sure if Astro or others have a convention for that sort of thing. Another potential though is using a separate naming convention for markdown (e.g. .ngx instead of .ng) Anyway, probably worth raising in the GitHub discussion if you're interested.

[@boian-inavov]

Imo (3) is the most valid. As you mentioned it strips down the massive barrier to entry for newer devs, as until this point Angular has seemed as the big and chunky framework only enterprise uses, which shouldn’t be the case. I love the revival that it has had over the past few years and I hope that it can be brought back in alignment with all the rest modern front end frameworks. Funnily enough, this also means that Svelte was right all along 😅

[@ImperiumLibertas]

Why should Angular strive to be like other languages? Why can't Angular be it's own thing especially if there are benefits like clear separation of concerns when using the separate tempalte/component?

[@jerrytab4276]

Angular just got really renaissance and now is the new Vue/Svelte 😂

[@tofraley]

I've never really understood or agreed that the html, css and ts parts of a component can each constitute a single-responsibility. I feel like that's a hold-over from MVC frameworks (that often keep them in separate folders, yuck!). It's all a component. It's tightly coupled. I see two major downsides to keeping them separate: - It makes working on the component more of a hassle. - It low-key encourages devs to make bigger components that, ironically, have more than a single-responsibility. It seems to me like you should start with everything in a single file, and only move to multiple files if it gets too big and you can't justify splitting the component in some way. I strongly lean towards 3, but more options is good in this case, so I'll say 2.

[@RaniLink]

Discarding separation of concerns just so that some beginners could feel a bit less "intimidated" is crazy to me

[@JoshuaMorony]

I don't think that is the key aspect here (and personally I don't view separation of code by type to be the same thing as separation of concerns) because technically this approach *could* allow for multiple files. If that were the case, is there anything else about the existing approach you prefer?

[@spencereaston8292]

But I already learned how to do it the hard way...

[@neociber24]

So don't change much to do it in a simplier way

[@lucaslevandoski2946]

that is just jsx with extra...

[@sebastianpaduch2527]

I believe that option 3 is the most valid choice, but retaining the possibility of splitting components into styles/template/logic could still be beneficial. In my opinion, the class approach tends to create more confusion than clarity.

[@yexiaorain]

Definitely 2. As someone who has spent some time writing .vue, for really less code writing it in one file is going to be cleaner, but can actually lead to disaster, most notably when used alongside git, and when using search text. And for the syntax of whether or not it's a class, preferring brevity, the experience of just writing 'this' would be poor, but it should be noted that if you go for brevity to 'make new concepts' is something that should be stopped, as in the case of react there are still all sorts of newbies who will be triggering multiple times by 2023 only needing to trigger code that triggers once. I don't want angular to have "problems that don't occur in other frameworks".

[@Edgars82]

I don't like it. 1. Use schemantics to generate whatever you need and you don't have to write boilerplate on your own. 2. I prefer template(html) and ts(all the logic) file to be separate files.

[@NoName-1337]

This would be very nice if Angular would implement it. Would love it. (Yes, i know, its like svelte. BUT, why shoulden't we implement such a low boilerplate code-style?)

[@ImperiumLibertas]

If we can lower the boiler plate while keeping the separation of concerns that would be great but this approach ruins that. Think it's difficult to explain that view goes in one file component goes into another? Now please explain that view and component logic need to be separate but in the same file. God what a nightmare managing templates would become when a junior dev writes a component with everything directly coupled.

[@NoName-1337]

@@ImperiumLibertas For this: You could just put the content into one file (without the script-tag), the content into the style file (without the style-tag) and the rest into the template file. Would work, in my opinion. And the relation can be determined by the filename (like in the current state of angular). We could have some default configuration for changedetection and so on, so we do not need to add this option to every component. There are many thinks, which could lead to less boilerplate code.

[@radvilardian740]

so 'metadata' becomes a reserved keyword ? please try again..

[@JoshuaMorony]

Current implementation uses 'defineMetadata()' now

[@AmrouBouaziz]

2 it should be an optional feature.

[@returncode0000]

#2 because I need a framework which has no additional burden build in like React/Next.js. Keep AnalogJS seperately. There really is a need for clarity in the Angular landscape were companies can rely on. Look what happened to React/Next.js, you meanwhile need npx create-vite to build a pure client side React app without Next.js. In my opinion the Angular product team currently creates Angular 3 and all the discussions (e.g. functional vs OO) are really annoying. There is a big Java/Spring/Spring Boot community who are feeling very familiar with all the existing concepts in Angular (DI, OO, classes, decorators etc.), this community should be the target for new Angular developers. Keep things seperated. Angular 2.5 is ok but I don't need a completely new framework. Developers should choose Svelte/SvelteKit, there is no need to jump on this boat if there already exists a framework/library who has basically that kind of syntax.

[@bartekaszczuk5201]

I don't see the improvement, quite the opposite. Now code is nicely separated from each other. One file is responsible for html and second for component logic - single responsibility principle. With this new approach everything would be in one cauldron.

[@ImperiumLibertas]

I think we should go one step forward. We need to remove the separation of html, css, and js. Why not? Less boiler plate. We can have everything in html anyway. It's simpler and therefor better right?

[@martinlesko1521]

You can do separation of concerns in Vue component too. You can import CSS and JS in and tags using src="" attribute

[@bullettime2808]

Angular is a poor example of Single Responsibility Principle, in a component based framework the HTML and Logic are highly related and should be together, in component based frameworks the Single Responsibility Principle is applied to the components, React, Flutter, Swift UI and others did it right

[@mfpears]

HTML and JavaScript are not separate responsibilities/concerns.

[@darkopz]

It depends on the use cases. There are quite a number of cases where this would simplify things greatly. Overused and abused it can make the code harder to follow.

[@altaron]

It's amazing how often my brain stumbles over your line numbers. I routinely stop following whatever you are narrating while my brain tries to understand your line numbers until it eventuelly goes "Oh yeah, they are relative to the current line which keeps its original line number. got it. is that at all useful?" and then it's off on its own tangent pondering (and so far failing to find any) possible benefits. Why do you use that? What are the benefits?

[@JoshuaMorony]

haha I can see that being distracting - its for jumping around with vim motions, so if I want to jump to a specific point I can easily see that it is 10 lines up from where I am currently so I can just type "10k" to move there (which just feels a bit better to me than hitting say ":68")

[@altaron]

@@JoshuaMorony ah of course, with vim (bindings) it makes a lot more sense. Thanks for clarifying!

[@sircharlesross537]

Everyone here’s like “segregate my ts/html files, I don’t want no filthy file mixing!”, I say do it. It will allow us to compound the view and logic into one easily portable file that can be used when we need small components with only a few lines of code. Like, do we really need four files and a whole-ass folder for a footer component? Can’t we just leave the .ng and testing file?

[@StephenRayner]

I hate single file components, hate it. Forces me down a design pattern path which doesn’t help but hinders.

[@JoshuaMorony]

How would you feel about this proposal if it also allowed for separating code by type?

[@o_glethorpe]

angular is used considerably more in companies with large projects, business like projects, lots of cruds, etc... why is that? its because the way things get organized. every time they push something to look more like svelte, react, they will not bring more people, they will lose the user base

[@JoshuaMorony]

I've seen comments similar to this, e.g that the class/decorator approach is more organised, but what organisation would you be losing here (unless you are using OOP features for components which isn't particularly common)? In my view, all the big reasons why Angular is great at scale are still there with this format.

[@o_glethorpe]

Hi, thank you for responding, this is one more "feature" in a pool of features that imo is not good for angular, like for instance, single components, what are your experience using it so far? for me is not doing so great, the tooling is very bad, is like, every time, the intent was I imagine, was to apply the experience when creating a component in react, but is far inferior to tsx. I dont know man, I liked angular because of the "mvc" approach. I know I still can do the "old" ways, but it is clear that sooner or latter that will end. @@JoshuaMorony

[@JoshuaMorony]

​@@o_glethorpe not sure if you mean single file components or standalone components but either way I like/prefer both of those - the aspect of being averse to adding more things/options I can understand. Personally, I'm glad Angular is adding all of the things it has been adding, but as well as they have addressed backward compatibility there is no getting around the fact that having multiple ways to do things is awkward/confusing. If that is the objection I can understand that, but for the sake of argument what if we switch the situation - say we already have the Svelte/Vue style and there is a proposal to switch to the class/decorator style. In this scenario, do you want to stick with the Svelte/Vue style to avoid adding in more options/features? or is there some specific benefit that the class/decorator approach provides that you want?

[@o_glethorpe]

I would like that a framework would not change the way you should use it, particularly when is soo far from the way it was supposed to be used when it was conceived. If it was the other way around like you pointed out, I'd still think it is a mistake. I guess time will tell. @@JoshuaMorony

[@dimitrisdrosos245]

3. Less boilerplate.

[@TheSqdf]

2

[@koles32]

According to the heresy Josh says in the last videos, this is goning to be react channel very soon and i dont like that

[@lokukkendare3641]

3, standalone components would be great but the syntax is trash in my opinion and something like this would definitely improve the dev experience.

3.)

[@zero14111990]

2) This format should be pursued, but only as something OPTIONAL through AnalogJS. angular need to be angular. yes some times can be dificult to learm the syntax but this is how TS work. change the syntax will be a hard hit to the people. learn from scratch in a framework isnt good. the people need to learn the basics of the lenguaje before to start learning a framework.

[@otonielguajardo]

3. Everything Angular has being doing is perfect, and this component authoring strategy is the missing piece

[@attoumak]

I hope to never see something like this happening! Someone can create another framework for this approach but not transforming angular !

[@mac.ignacio]

Let me make this clear. There are many new junior devs that more focus on the syntax than learning how things works. Those devs will soon realize DX is only 1% of the problem when it comes to software development. 99% of your will be going on problem solving, reading docs and managing existing code.

[@niklasravnsborg]

2 - but maybe Angular could even provide support for JSX/TSX. This would be the most ergonomic development experience in my opinion.

[@tibsou]

1) This format should NOT be pursued at all Not to mention the separation of concerns (which is already critical), the Angular framework has always been highly opinionated. There's generally an Angular way of coding things, and every Angular developer is capable of quickly adapting to any Angular project since they'll be familiar with common practices (which is particularly appreciated by large companies). It's for this very reason that NestJS is gaining in popularity among Angular developers for the backend. I don't understand why we need to change this way of doing things if it's just to conform to competing frontend frameworks. The concepts of classes and decorators are basic in programming, and if they scare young developers, it seems to me very worrying about their motivations, especially as this framework is generally chosen for complex business projects. Angular has already evolved a lot recently (standalone components, signals, new control flow...) and there's still a lot of work to be done to modernize it, but this proposal seems counterproductive to me. By the way, how can this component be used in another standalone component if it doesn't export any class?

[@michaelrentmeister7693]

I had the same thoughts as well about using the components within other components..

[@user-ey2sw8wx7e]

1) split code, html, css is much better way.

[@Dorchwoods]

#3. This new format is SO MUCH BETTER. They really should strive to make that the default. Although I feel like there would be a lot of breaking changes potentially, and the upgrade path could be rough

[@additionaddict5524]

I get kind of annoyed how every time someone explores these ideas the there's a small but vocal group bashing the idea of exploring this in the first place

[@chaos_monster]

2:50 your example is (on purpose?) overly complicated, as it fully ignores the CLI and instead of saying a component contains a ts file a html file and a css file you make it sound complicated

[@JoshuaMorony]

I've picked a scenario (yes on purpose because I'm trying to highlight where I think this is particularly relevant) where describing what is happening is awkward/complicated. In this sort of scenario (some kind of live coding demo/podcast interview/whatever introducing the framework) the component would typically be built out from scratch instead of using the CLI to generate it. Even if the CLI was used and you are just explaining what is happening in the .ts file its still more complicated than the alternative imo

[@ToJak91]

Please tell me, why is it that people hate `this` ? I truly loves it, as it is a clear indication that something is related to my current scope, without being in my scope. Without this, it can either be in my current scope, which i should be able to find very easily, or it can be ANYWHERE in a globally exported field/function.

[@PauloSantos-yu1tn]

Why people want to remove something that gives structure and good code? Angular always was an enterprise solution, if someone wants to use something from almost no knowledge, use a simpler tool. To me this is not an improvement. When angular removes the class components i will switch to another tool, a modern one.

[@3pleFly]

This format should NOT be pursued at all. I've seen how messy vue can look and it's not pretty. I think the class approach is the most organized

[@JoshuaMorony]

In what way is it more organised?

[@adambickford8720]

We're already trending back towards PHP, why not jQuery too?

[@g-luu]

3.

[@user-yv5vw8wc8q]

1) This format should NOT be pursued at all I don't feel Angular's class-based components are really a problem, especially now the standalone APIs have reduced the need for module boilerplate. It's not that I dislike the hypothetical format - it's just that I don't see the value in changing it. And I definitely don't think it's worth the effort to make everyone migrate from one to the other.

[@coolguy0]

3

[@knuppelwuppel]

i mean..sure wh not :D not a game changer imo

[@VinitNeogi]

3) This format should be pursued, and it should eventually become the DEFAULT for Angular itself

[@John69]

It will look like Vue - like shit

[@tomasbird]

3 - let's get rid of classes all together, everytime I think about using inheritance with angular i end up shooting myself in the foot anyway