A "simplified" approach to Angular components? 

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

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.

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

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.

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

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.

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.

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

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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 :)

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.

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.

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.

would love to see that!

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

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

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.

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.

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

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)

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

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.

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

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

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.

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?

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

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.

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

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

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.

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

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?

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

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

polymer is resurrected?

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 👍

5) optional to angular

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.

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

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

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

Like svelte?

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.

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

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.

2. Seems like a nice option for smaller components.

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

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

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

that is just jsx with extra...

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

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 😅

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

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?

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

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

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.

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

2 it should be an optional feature.

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

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

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?

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.

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

3. Less boilerplate.

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

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

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?

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.

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

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.

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

2

3.)

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.

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

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.

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

#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

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

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.

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

3.

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

3

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

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

It will look like Vue - like shit

1) completely useless in my opinion. Angular should stay with classes