-
Notifications
You must be signed in to change notification settings - Fork 26.2k
Supporting a huge number of similar applications; Supporting software production lines (SPLs) #21352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@Nefcanto ... some thoughts on the base of your ideas:
|
Technically it's possible, I have a demo in https://trotyl.github.io/ng-component-loader-demo/ , for example https://trotyl.github.io/ng-standalone-components-demo/temperature.js is a single component and could be loaded directly. But doing so gets little benefit as |
@trotyl ... lol, you always surprise me. 😄 |
@Nefcanto Those are totally JavaScript. TypeScript is a superset of JavaScript, but these are the inherited JavaScript features. There're demos without using TypeScript like: https://github.com/shuhei/babel-angular2-app/blob/master/src/app.js, you'll find little difference. But without AOT support (which is highly based on TypeScript), it not performant in runtime. |
@tortyl, Angular has architecture, style guide, and everything a good clean codebase needs, but only for ONE project. Do you understand that? What if there is 100 projects and I need ALL of them to have the same set of dependencies? How to control or enforce that? How to prevent deviation in many projects? How to make sure that developer 1 uses the same version of say X, and developer 2 to 100 also use the same version? How do you manage that? What if I want to remove testing from all projects, cause we can't afford testing costs? What if I don't need that AOT fanciness and I'm cool and OK with the performance issues, because I gain business-value somewhere else? What if I want the TypeScript to be configured the same across ALL projects? You probably don't understand that, because you have not experienced it. Most developers work only on one project and can't perceive the context from the eyes of a company that has MORE than ONE simple single project. When it comes to discipline and corporate standards, Angular becomes a true pain in the ass, because it works in one and only one way. Change it and bugs start to appear. You can't centralize things easily. Like I'll give you an example. .NET projects are built using MSBuild and are configured via special XML files called We have a SPL on .NET platform, and we manage to run more than 100 applications, only using a team of less than 9 developers. That's competition. That's business-value right there. Yet to manage 100 web-apps using Angular, we probably need at least 25 developers. Do you know why? Because each developer in .NET can manage at least 20 application based on all the improvements and infrastructure that we have made in our SPL, yet we can't get the same things in Angular. |
@tortyl in Google I/O 2017 I heard them saying that we have more than 6 million applications both on Google Play and App Store. Can you believe that? 6 millions. That's not a joke anymore. Many companies are working in the field of creating low-cost applications in high-volumes for special type of customers. Let's think about WordPress for example. There are thousands of businesses out there which are OK if they have a website made with WordPress and they don't need to spend a huge amount of money to setup their own teams and create highly sophisticated and customized web sites. That's our business. We create applications (web, android and iOS) for these types of companies. Yet to make them happy, we need to reduce costs. To reduce costs, we need to extract similar functionalities from many projects and control them somehow from a central place. We need to follow don't repeat yourself pattern. That's possible in Android Studio via Android Modules and gradle build system. That's possible in Visual Studio via dll files and MSBuild configuration. Yet that's somehow impossible in Angular. If we could write angular in simple JavaScript terms in old fashion of web like including js files in head, etc, then we would benefit from it. The main reason we're moving to angular is because of the overall market trend. That's all. Developers are switching and it's getting harder to find developers for older technologies. Customers hear about it and get into the hype and ask for Material Design. And so many more factors that push us to go towards Angular. Yet it's not good at all for creating many many more applications with single standard. |
@Nefcanto You have severe misunderstanding between Angular and Angular CLI.
That's what Angular CLI provides (except Style Guide which is an abstract principle), if you want a custom project structure, you're welcomed to create your own, but Angular CLI is only designed for SPA usage only.
You could search for term "micro frontend", that's what you're looking for. |
@Nefcanto ... the more I think about it, the more I am convinced that Nwrl Nx Workspace (monorepo concept) is a concept that should interested you. Your arguments are exactly those reasons why it ever came into being. Generally the Nx Workspace concept is something what took much wider experiences from Google monorepo concepts that Google is applying internally for many years and on a lot of larger apps portfolio ... there are probably hundreds of apps, maybe thousands. They are fighting with the same types of problems but with hundreds and hundreds of developers around the world. |
@trotyl then why angular.io starts with Angular CLI? I searched and I couldn't find a section on how to create an Angular application without Angular CLI. I think the point you mentioned might be helpful. Can you guide me in the right direction on that? Is there examples on how to create an Angular app without Angular CLI? |
@mlc-mlapis I'm so thankful for the link you introduced and yeah, you're right. They have the same concerns. It's just that when it comes to business, law also comes into the scene. We try to somehow do what they've done, but with multiple repos. If we can't, we definitely give it a try cause as you said they are very close in mindset to what we need. |
@Nefcanto Some facts:
Angular CLI is here to save time and reducing the learning curve, but not for forbidding your creativity. You can find non-CLI example everywhere (https://github.com/angularclass/awesome-angular), but if you only want an out-of-box well-maintenance production-ready project template, then it will certainly be hard. Of course nx is a good example. |
This is a general topic which we are hoping to address in the futrue, but as such it is not really actionable. I am going to close this but do continue to have discussion here. |
@tortyl, based on your guideline that Angular is not Angular CLI, we've already started R&D to create our own infrastructure for Angular. Here's what we intend to do:
Of course we know that this path might not be feasible, or even if feasible we would definitely lose some benefits and Angular like AOT compilation, or flexibility of having multiple router-outlet for deep linking and similar scenarios. Yet the business-value we gain would be much more. |
By saying that I mean you should raise specific actionable feature request (for specific repo) rather than abstract support request like:
The official tooling won't be able to cover everyone's advanced requirements, but can still be made use of.
AOT and routing are feasible for individual build process (unless dropping TypeScript usage), but making custom AOT tooling support would indeed require knowledge about Angular compiler and JavaScript building tools, so it's depending on you whether it's worthy or not. |
@Nefcanto ...
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
I'm submitting a...
[x] Feature request
Current behavior
When you want to create one web app using Angular, everything is superb and excellent. But as soon as you start to use it to the benefit of a company that has a software production line (SPL), things get a little ugly.
For example, in AngularJS, the old school of web meant referencing JavaScript files directly in HTML head section, and lazy loading each HTML fragment (roughly equivalent to Angular Component) and its relevant JavaScript file. This could be reused and automated in a bigger context, with AngularJS truly serving a good role in the bigger picture and providing true business-value for the company.
Based on three reasons we decided to move to Angular:
However, we suffered tremendously to harness Angular's power for our own benefits. Because as soon as you start deviating from Angular's opinionated everything, you literally encounter tons of problems.
Here are some examples:
When we want to create 10 applications per month, and they are all in a similar business context, the very deeper concept of IoC in the field of configuration and preparation creates business value. Instead of each developer and each project controlling its configuration and preparation, we tend to configure them and prepare them all from a bigger context (SPL). For example, in AngularJS we would only ask a developer to create a simple folder, and then create HTML and JS files for features of that application immediately based on our OWN convention and without any extra step. Yet here in Angular as soon as we create a new project tens of configuration and preparation files are created (package.json, package-lock.json, tsconfig.json, tslint.json, karma.conf.js, polyfill.ts, ....) and they can easily deviate from the same files across projects, which is so expensive in the sense of an SPL.
For example we need to have one project.json file, that is somehow inherited across 500+ projects. One polyfill.ts file that is not even repeated across projects and developers won't see it.
We need to use our own file-system architecture, which is different from Angular's architecture. Folder naming, folder nesting, component naming and similar other things
We don't want to load an entire Module, rather we need to load each component separately. That is if you navigate to another route, we need to load that route's component on the fly and lazily. We don't want to create a module per component to load modules lazily
We don't want to use TypeScript as our first-citizen scripting language. It's bloated with boilerplate code (specially those imports at the top and all those decorators and exports at the end of each file and ...). We want to write the minimal JavaScript truly related to that component's logic very briefly.
We don't want to use Webpack. We want to load Angular from one CDN, load Material from another CDN, our shared components from yet another CDN to increase speed of loading, not a bloated huge big file created via Webpack that packs them all together per app.
Expected behavior
Angular being more flexible to the old school of web and old standards of writing web applications, and introducing new features only as additions, not replacements.
Minimal reproduction of the problem with instructions
Try to think about creating 500+ similar applications using Angular, with as lesser budget and dollars spent as you can imagine, so that you can reduce the end cost for customers through productivity. That means lesser configuration, lesser boilerplate code, lesser technologies involved, using old familiar tools and technologies, etc.
What is the motivation / use case for changing the behavior?
Business value is the one of the most important drives in the industry. Angular is so great when it comes to create ONE SINGLE ad-hoc application. TBH, I think it's the best for that scenario.
Yet its power can't be harnessed (or maybe we don't know how) to support frequency of production.
Angular version: 5
Thank you so much. If the given context is not clear, I would be glad to provide more details through examples and comparisons.
The text was updated successfully, but these errors were encountered: