I have watched the latest ng-conf and saw Brad Green says Angular2 now weight 45K, and angular1 is 56K. I try to understand what those number represent, but without success.
I also saw this gist that list Angular1 and 2 frameworks by size. And there are completely different numbers there.
The ng-conf YouTube link (it's in 57:10).
The relevant slide:
I understand well your question ;-) In fact, it's after packaging your application and using tree shaking. The latter is a technique that leverages modules to only keep what is used in the application (apply to third party libraries as well).
I think these two links could help you:
http://blog.mgechev.com/2016/06/26/tree-shaking-angular2-production-build-rollup-javascript/
https://medium.com/#Rich_Harris/tree-shaking-versus-dead-code-elimination-d3765df85c80#.6s0vcyv49
The presentation was about offline template compiler that is currently experimental, that eliminates loading Angular2 parser and compiler into the browser by processing the templates and converting all declarative bindings to JS at compile time.
This allows to reduce the Angular2 package code size that actually needs to be loaded into the browser.
If one requires solutions like demonstrated in How to realize website with hundreds of pages in Angular2 the parser and compiler would be required to be loaded into the browser and lose this size benefit.
Related
I have serious performance issues when my angularjs 1.0.7 webapp loads for first time all translation files with angular-translate.
The point is we have only one huge translation file for each language. At the moment with more than 3000 translation lines each. So, if you debug the loading times it takes up to 3 or 4 seconds to load.
I have made some tests and noticed if we use small files with a few translations the performance improves.
I have read a bit about angular-translate and I see there is some partial loading feature, that can load one translation file per each view which maybe is a better approach. I have also read about namespaces that maybe improve performance too.
However, I don´t know if this functionality is working with my angularjs 1.0.7 version because I don´t see anything in the angular-translate docs. I would like to confirm which is the latest angular-translate version that is compatible with my angularjs app and check if there is a feature that can fix this problem.
To migrate angularjs is not an option at this moment.
Do you think it´s possible to use partial files with this angular version, or otherwise is there any other approach to improve this performance issue?
I have seen many articles regarding the changes in Angular2 . But I can't find much advantage in using Angular2. Can some one point out some new things that can be done using Angular2 which can't be done using the previous versions.
I know there are changes like $scope changed to this. I'm not asking for changes. I'm asking for new features that is in Angular2.
The TL;DR Version
Because ES6 is important to pick up, so no need for a custom dependency management system anymore. ES6 and Angular 1 together get ugly fast, as they together introduce a bajillion coding styles :(
Although the library is overall heavier, the architecture it uses (all component based) is a lot faster, lighter, and modular for a scalable application. See http://info.meteor.com/blog/comparing-performance-of-blaze-react-angular-meteor-and-angular-2-with-meteor
You receive (upcoming) Server Side Rendering, which enables fast initial load time and Search Engine Optimization (Yay!) See: https://github.com/angular/universal
You receive WebWorker friendliness, which makes your application able to "multi-task". See: https://github.com/angular/angular/blob/master/modules/angular2/docs/web_workers/web_workers.md
Shadow DOM is not fully inherited by Angular 2 yet, but I'm sure it will be. It has some support right now.
The whole concept of $scope is gone. You receive two way data binding with anything you put in your ES6/TypeScript class, but anything more you need to create a Observable or promise. Unfortunately, you can't just shove anything into the scope, digest, and WALAH! anymore.
And of course, all the cool stuff they mention on their website: https://angular.io/features.html
Hope that helps!
Support for different languages TypeScript, Dart, ES5, ES6.
Change detection is much more effective
Support for isomorphic applications where the same code can run on the server, the browser and a WebWorker in the browser
Moves more work to build time to reduce the time for the initial page load.
Simplified binding syntax
Improved DI
There are also lots of mostly smaller and tiny features that Angular2 doesn't (yet?) support which Angular 1.x does.
I'm looking for dock layout engine for angularjs written in typescript. I found Dockspawn but it is written in DART and it's not compatible with the rest of my project. Does somebody know any dock layout engine (even paid ones) for angularjs in typescript?
I think your real problem is that dockspawn was abandoned. This is something I built at my company (which, sorry, we don't sell software)and it turns out that Angular is the worst thing you could use to build a layout engine like this.
Managing scope chains among components that are constantly changing positions, opening/closing, resizing, and floating is entirely too complicated for this type of project. You will end up with 15 step bug reports everywhere, and unless you have a perfect algorithm set in place before ever developing anything you will end up spending weeks re-writing code.
Solution (and not the one you want to hear): drop it. Web design is meant for developing pages within the browser, not for developing windows with tabs within your browser window which is full of tabs. The control and flexibility is very nice, but there is always a way to provide the user with just as much control by setting up panels on the page in the positions in which they will be consistently used the most.
Sooner or later someone will develop what you are looking for and release it, but it probably won't be in Angular and it's definitely going to cost money.
You should be able to use Dockspawn because at runtime DART is JavaScript, so as TypeScript. You just need to find a way to make TypeScript aware of Dockspawn and you can do that using a Type definition file.
The types definition file for Dockspawn is available online.
You can install this kind of files using a tool known as tsd. You can find a basic example here.
I have few queries on selecting Ionic framework for our Hybrid app project. Since I have not used Ionic before, few queries may seem idiotic. But i would request all to share their thoughts.
Q1. How easy it is to customize any ionic components as per project requirement in both JavaScript and CSS level?
Q2. How much overhead ionic components create in terms of DOM, Memory usage?
Q3. In case of collection-repeat, say i want to display 10 items out of 1000 items at a time. So at any point in time only say, will there be only 10 divs and will only new data be injected in the previous created divs?
Q4. Say, I have selected Ionic for our project but don't need all the UI or other components in it. So does Ionic gives the flexibility to exclude those components from the framework itself and use the rest?
Q5. How easy it is to include an external library into Ionic if required?
Q6. How easy to debug and Ionic app and the tools available?
Q1. Since Ionic is based on SCSS, it's really easy to customize the visual aspects. I did a video about working with scss and Ionic. As for the javascript side of things, if you know how to work with directives, you should be good.
Q2. Ionic aims to the keep the DOM nice and lean, and not change the DOM like you would with jQuery. As far as memory usage, that really depends on the code you write. You still need to write good code to make sure there aren't memory leaks any where.
Q3. Collection-Repeat doesn't really work that way. Plus when you start dealing with different screen heights, it's not going to be easy to deal with. The best why that we've come up with to deal with that is to just render how ever many it will take to fill the view.
Q4. At the moment no, if you start a project with the CLI, you get the whole bundle. Down the road we're thinking about breaking things into external components, but it's not set up yet.
Q5. It's Angular, so if you have another angular directive that you want to include, the process is really simple. Just include the script tag and inject the module as a dependency. If it's not an angular module, then it's a bit more work to wrap it in a directive, but there are plenty of tutorials out there to help.
Q6. The best thing to remember is that we're dealing with a webview, so you can do a lot of debugging right from chrome on desktop. If you need more debugging once you're on a device, iOS lets you debug right from safari on desktop, and android 4.4+ let's you debug app on a device with chrome.
I'm working on a project which has the luxury of using ECMA 6 on the latest browsers for a product that will be shipped in 1.5 years. So we thought why not use Web Components now that Angular 2 isn't available (which is going to be ECMA 6). And while we are at it, can we replace Angular altogether without having to go back to stone age?
How to replace Angular?
There's this site called youmightnotneedjquery.com which is basically about how modern browsers actually have most of the stuff that jQuery was traditionally used for. I'm interested to see something like that for Angular.
We mainly use four Angular features. What are my options for replacing them?
Angular Directives --> Web Components
Angular Modules --> ECMA 6 Modules (not exactly the same thing)
Angular Routes --> ???
Angular 2-way databinding --> ???
PS. We don't want to replace Angular with something similar like Backbone or Ember. We want to replace it with standard web technologies but if we have to use small tools to fill the gap, we'll consider it.
I've been researching in the past 3 weeks and turns out many people are thinking about an alternative after Angular took a drastic change path. Fortunately the upcomming W3C Web Components standard actually has all we need and it works right now with polyfills from the Polymer project. So to answer the question:
Angular Directives --> Web Components use the polyfill until all browsers support it.
Angular Modules --> ECMA 6 Modules part of the problem is solved with HTML imports. But you can also use Traceur until the browsers support it.
Angular Routes --> There's a component for that™ use <app-router>.
Angular 2-way databinding --> Polymer adds a "magic" layer on top of the plain standard web components. This includes many features including data-binding.
+Plus More
If you're wondering about the build process for concatenating files in order to reduce the number of HTTP requests, take a look at Addy Osmani's post about Vulcanize. Spoiler: you may not need it with the upcoming HTTP 2 optimizations.
Many Angular projects use Twitter Bootstrap for the layout. Polymer can do that plus it plays nicely with Google's Paper elements (totally optional but superbly awesome).
If you want to make yourself familiar with web components in general, here is a bunch of nice articles: http://webcomponents.org/articles/
And here is a wealth of web components: http://customelements.io/ I don't know if it's going to be a new NPM, but the list components is pretty impressive and growing.
It's relatively complicated to expose an API for an Angular component. People have come up with all sorts of methods from link function to emitting events. In Web Components, however, it's really easy to make your component interact with the world outside and indeed the API and events you expose aren't much different from standard HTML tags like <audio>.
Just like Angular, you can use Polymer with Dart as well.
Conclusion
Overall, I don't see any reason to use Angular except if:
You have a huge source code investment in angular and don't want to port everything to standard web. (Angular 2.0 will deprecate your code anyway, so you're stuck with Angular 1.*)
Your team is too lazy to learn a new technology (in that case web might not be the right platform for this attitude anyway).
Angular was good for what it was doing and had its own Hype cycle. Web components solve many of the issues Angular was trying to address. Probably Angular had a role as a proof of concept for the Web components. But now it's time to move on. Web is reinventing itself everyday and it's inevitable to moves someone's cheese.
I'm not saying that Polymer is the ultimate answer to everything. At best it's another Angular which will render useless in a couple of years, but now it's a good time to learn and use it. The W3C standards don't die easily though, and Polymer tends to be much closer to them.
There's an element for that™ is the new There's an app for that™
TLDR: seriously consider writing an almost Angular 2.0-compatable Angular 1.3 app before rolling your own framework
It seems as if you've identified that Angular does a lot of things the right way and that's why you're attempting to replicate it, so basically you're going to roll your own by combining a hodgepodge of libraries. Unless you have an enormous investment of Engineering hours, the framework you build will likely be:
Lightly documented
A cross-browser maintenance nightmare and (worst of all)
Difficult for new hires to learn
If there wasn't a framework out there that did what you want to do already, I think rolling your own makes sense, but by trying to recreate Angular you're:
Taking on a lot of Engineering work that has already been done by a dedicated team, that could have been spent on building product
Made it MUCH more difficult to onboard new employees because you have to:
Find candidates that are willing to use a home-grown framework instead of growing their skills at an open source framework they could use elsewhere
Train these employees to use your framework (and good luck unless your documentation is mature)
I know your question asks how to replace Angular, but I've seen too many companies go the route of rolling their own and paying for it down the road. Again, if your budget includes a ton of core resources to build out (and document, and maintain) the framework and you don't think there is any chance corners will get cut when push comes to shove later if timelines get tight, then rolling your own might make sense. However, I think you should seriously consider reading up on how to write Angular 1.3 apps so that they're easy to port to Angular 2.0 and go the Angular route. Just look at the size of the community you're missing out on:
http://www.airpair.com/js/javascript-framework-comparison