22 ms·
Angular 9.0
- theodorejb 7y agoI just updated my mid-size app from v8.2 to v9 with Ivy, and the total es2015 bundle size decreased from 973 KB to 669 KB. An over 31% improvement with no effort on my part!
- pier25 7y ago> 973 KB to 669 KB Is that minified and gzipped?
- theodorejb 7y agoJust minified. Gzipped size is now 225 KB.
- pjmlp 7y agoGreat!
- ehsankia 7y agoI would assume angular outputs minified code, but not gzipped. That being said, 973kb seems like large-sized rather than mid-sized to me.
- tmpz22 7y agoThats exceptional, I wonder if it was a really clever optimization they found or if it was a really lazy bloat they let into an earlier build. It reminds me of a great hack where game developers used to hide a large memory allocation early in the game development process and when they ran into memory constraints towards launch they'd just comment out the line and instantly save the day. Artificially constraining the memory caused intermediate development to be more frugal and ultimately allowed them to get where they needed to be by the end of it.
- mgechev 7y agoMost improvements come from the more compact JavaScript we generate from a template. We also worked on making the runtime tree-shakable, so in your final bundle you can get only what you use. Additionally, we made sure the code we generate compresses well with popular algorithms.
- pier25 7y agoWill be interesting to see how it fares in the Js Benchmarks: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- topspin 7y agoWhat happened to React? It's on the wrong end of almost all of those micro benchmarks. I know micro benchmarks don't tell the whole story, but when you consistently wind up on the slow end it's not a good look.
- foota 7y agoI'm also curious, in particular why is the swap rows benchmark so much slower?
- leeoniya 7y agobecause React's stance is that it's a rare enough case in their experience, so they don't spend time optimizing for it. that metric is slower in general because libs with simple reconciliation strategies will tend to do work for every row between the two swapped ones (2,998).
- ilrwbwrkhv 7y agoSo what's the benefit of more complex ones like react's?
- pier25 7y agoPopularity. The ecosystem is bigger and there are more devs available.
- ng12 7y agoBy choosing React I'm optimizing for my time. I'll always add a framework that adds a tiny performance overhead if it means I can develop and maintain features easier. That said -- performance characteristics like this are rarely interesting to me. The vast majority of "performance issues" I've encountered have to do with high-level architecture and/or network issues. I've never given up on a framework because it couldn't swap two DOM nodes fast enough.
- tashoecraft 7y agoHuge release with a lot of time and effort put into it. Congrats to the angular team. Couldn’t imagine another framework putting in the amount of work they did in order to insure Ivy goes well.
- mgechev 7y agoThank you! We're really excited to finally make Ivy generally available! ️
- qwerty456127 7y agoWhy is Angular so less popular than React?
- vips7L 7y agoProbably because its a larger learning curve and its a lot more "framework".
- treeman79 7y agoSaw a 2 man team that got features done in a couple of weeks on jquery move to angular and turn into a 15 man team that took months on each feature. Management was very happy with how modern the stack felt Sales came to a halt for 2 years since features came to a halt. Turns out Angular is freaky hard to do right.
- runawaybottle 7y agoI can believe this
- 1123581321 7y agoA family member works at a software company that’s worth ~100MM less than it should be right now because they let Angular get into too much of their app before they settled on Vue.
- jcheng 7y agoWas this AngularJS (i.e. Angular 1) or Angular 2+? I could believe it either way, just curious.
- treeman79 7y agoAngular 5-7
- rtpg 7y agoon the other side, we went from jquery messes with a bunch of state machine issues to being able to comfortably add client-side interactivity with a lot less worries when moving to Angular 1.x There were definitely Angular-related issues, but they were replacing a lot of "my state machine is out of sync" issues that just scopes and watching mostly solve (except for the prototype inheritence gotcha)
- grkg8tr 7y agoHow does Aurelia compare?
- DigitalSea 7y agoIn my opinion, Aurelia has always been the less complicated and lighter option of the two. Aurelia 1 had some design choices that made it harder to tree shake down, but Aurelia 2 is around the corner with AOT and numerous optimisations that looks like will put it at the top of the benchmarks again.
- tommyjepsen 7y agoI just upgraded and got 'Failed to load module script: The server responded with a non-JavaScript MIME type of "text/plain".' from my S3 through CloudFront. Seems like it's not adding 'type="text/javascript"' to <script> in index.html. When adding this manually, everything works. Just FYI if others upgrade and seem to get the same errors.
- jchw 7y agoNormally type=“text/javascript” is strictly unnecessary. You should try to configure whatever is uploading your site to S3 to set the Content-Type correctly as I believe that will also resolve your issue.
- mgechev 7y agoMy guess is you hit https://github.com/angular/angular/issues/30835 https://github.com/angular/angular/issues/30835. In version 8 we introduced differential loading to allow users on newer browsers to download smaller, modern bundles. Modules, however, enforce strict mime type checking. As the comment below suggests, you should make sure your static file hosting serves JavaScript with the correct mime type.
- tony 7y agoOne of the nice things that Angular has you don't see in the post is... very polite and courteous maintainers! https://github.com/angular/angular/pull/33717#issuecomment-553118863 https://github.com/angular/angular/pull/33717#issuecomment-5... This was a fast release cycle. It was back in November 2019 we were talking about 3.7, and now it's in. I'm not even thinking about Ivy. But it's nice to have all the nice comforts of typescript ready and working out of the box. (I mainly work in React, but dabble with angular/vue to stay up to date) And what a smooth update process (abbreviated): ng update @angular/cli @angular/core ** Executing migrations of package '@angular/cli' ** ** Executing migrations of package '@angular/core' ** Your project has been updated to Angular version 9! For more info, please see: https://v9.angular.io/guide/updating-to-version-9
- joshschreuder 7y agoIgor seems like a good dude. I used to follow his talks and stuff from back in the AngularJS days.
- kungito 7y agoIt may seem "smooth" but I've been developing some hobby apps from time to time and it was never smooth. From Angular 2.0 release to 8 I've always had to spend 1-2 days to fix some random bugs from undocumented contract changes every time I came back to my projects. I'm speaking just from my amateur experience with 50 file projects.
- no_wizard 7y agoAnyone know what the real world sizes of the bundles are now? Last I used Angular I couldn’t get a bundle smaller than like 250-300kb
- romanovcode 7y agoReal world e-commerce app without Ivy (Angular 8) is ~500kb gzipped
- dfsegoat 7y agoIs there still a clear path from angularjs 1.x onto angular 9.0? Anyone done it recently? Supporting a large 1.x codebase right now, and would love to start incrementally moving to angular.
- rawoke083600 7y agoNo there is no way to go from a donkey-cart to the Star ship USS Enterprise in a incremental way while still travelling forward. I've also had to do it. Just start from scratch. I'm a lot more productive with A6+ than I was with AJS
- vikingcaffiene 7y agoIn addition to being completely accurate, this is one of the funniest things I've read on this site in a long time. Thanks for the laugh.
- doitLP 7y agoThey are wholly incompatible. The choice of the Angular name for this new framework was just marketing, beyond some similar design choices. Probably there are better ways now but here’s how I did it: * Determine exactly how moving to a new framework will benefit your users. If it doesn’t, why are you doing it? It is going to be a lot of hard work and your users will not care you’re on a new framework. * evaluate if Angular really is the right choice to upgrade to * if it is, do not mix the code in one repo. Use two repos. * Migrate route by route, starting with lowest impact pages first. When user clicks on the route served by the new angular page it will point to the new app * to support this, you’ll need to build out foundational modules critical for the switching to happen, e.g. auth, common header, footer, menus etc * how the switch happens between routes is up to how your app is served. You will need to configure the domain to stay the same between serving the different apps. * update your deployment and testing strategies to account for two apps going out instead of one. * we took a bell curve approach, lowest impact routes first, then peaked with critical routes, then back to less and less important pages. This allowed a gradual ramp up to work out the kinks but at some point you will need to get your most important stuff moved over so you’re not building two systems. * get buy-in from stakeholders that this migration is going to add value for users. Get them excited so you are working together to get it all moved over. * allocate x% of Dev time to the transition. * agree on a date for each route and for the full transition so work can be prioritized. I’m sure there’s loads of blogs with more specifics. Just wanted to share my experience at a high level.
- rawoke083600 7y agoI've been running the RC's at least the last 6 months or more, upgrading usually within in day when the new one comes out. I've been impressed but what I've seen is that even though A9 is very good (Well done developers) when the real world hit you and your app. Its many times all the other nonsense you have to include in your app that makes it big and slow (GAnalytics,GAdsense, fb-pixel, crazyegg and and and) Still wouldn't want to code without it !:)
- gitgud 7y agoThe only thing I like about Angular is the dependency injection of services. Having "services" managed for you and just picking and choosing what you want is pretty nice. What I don't like is the verbosity and boilerplate... here's 2 examples: - Routing boilerplate is convoluted and time consuming. I think Nuxt.js has a much nicer implementation of SPA routing, where the filesystem is used to map the routes. - Angular modules are verbose, redundant and don't even truely encapsulate dependencies anyway. You can easily create implicit dependencies by relying on services instantiated in higher level modules.... which is bad I love using Typescript though!
- paulintrognon 7y agoThe great thing is nowadays you can use Typescript for React or Vue very easily :-)
- mattlondon 7y agoAnother benefit in my mind is that Angular is "batteries included" - you get everything you need in a single library, e.g. routing is a big one. From what I understand of React, you need to pick and chose the libraries (and versions of those libraries!) to use for your app, and then keep the versions of all the different libraries up-to-date and in sync with each other. Sounds like a maintenance nightmare.
- mojzu 7y agoIt has probably been improved since I last tried it but this is one of the reasons I picked Angular over React. Having a router, HTTP client, forms, i18n, etc. out of the box compared to having to find/evaluate/integrate/maintain the various libraries that build on React to get the same functionality was a great benefit. The other reason is the first class TypeScript and RxJS support.
- Vinnl 7y agoThen again, that is what might lead to the boilerplate. I've been out of Angular for a while, but was kind of following along around the release of v2, where they went through about four routers, I think. GP mentions mapping routes to the file system, but then how are you going to accommodate a route pointing to a modal inside another route, identified by its hash? By having one blessed implementation, they also feel forced to support every potential use case.
- radiKal07 7y agoWhat about AngularDart?
- Yuioup 7y agoI have a policy of only shipping "back-end" apps because I'm worried about performance, browser compatibility and SEO. I don't know if the situation has improved in Angular 9. Does anybody here use Angular for their customer facing websites?
- pjmlp 7y agoWe follow the pattern Java/.NET traditional BE stacks, Vue and Angular (on this order). So far I have only deployed Angular once in production for an IoT Dashboard. It was based on Material Dashboard, it was good enough for the monitoring use case, but it was for on-premises deployment.
- Yuioup 7y agoYeah exactly. I do something similar (Angular, .NET Core) and use Angular for apps that the customer never sees.
- jspash 7y agoHave a look at Phoenix Live View -> https://www.youtube.com/watch?v=8xJzHq8ru0M https://www.youtube.com/watch?v=8xJzHq8ru0M It is still early days, and isn't suitable for every use-case, but it could be the answer you're looking for. Continue to write back-end code only. But with the benefits of quick-response front-end app. I'm a total convert (evangelist) who has been increasingly put off by the evolution (devolution?) of front-end development over the past 5-10 years. This could be one way of the mess.
- Yuioup 7y agoIt's not Angular's architecture I have a problem with. As a former Delphi and current .NET developer, Angular fits like a glove, not to mention Typescript which was created by Anders Hejlsberg. It's the output I'm worried about. The HTML outputted by Angular pre-Ivy is verbose and runs very slow on old browsers (IE9, with polyfills). A customer facing website can be visited by anyone, from a tech savvy Linux user to your grandma which uses Internet Explorer and thinks Facebook is the internet. I don't want to face the wrath of clients who realize that their website is slow and non-optimized because I'm using Angular.
- DonHopkins 7y agoI've been going down the long road of learning Angular recently, and I love it and want to learn more, but I have a couple naive newbie questions whose answers I thought should be obvious, but I haven't been able to figure out: Is there a standard way to define local variables in an Angular template so you don't have to repeat the same redundant expression again and again (or so you can at least give an expression a self documenting variable name so it's not so mysterious)? Or do you have to define an instance variable on your component and figure out how to initialize it to the right value before the template gets executed, with no way to lazily (or repeatedly) evaluate it by putting the calculation inside conditionals (or loops) in the template so they're not run if they're not needed (or to calculate the local variables independently for every loop iteration)? Is there an angular hook or technique that's meant for that, and efficient, and hopefully doesn't involve much arbitrary non-JavaScript gobbledygook syntax, and is at least somewhat standard and well supported? Please don't tell me I shouldn't ever want to do that for some reason of ideological purity or separation of concerns (as if a templating language could ever be called "pure" or "elegant"). The common legitimate use case is ngIf="some expression is not null" then {{some expression}}, and also ngIf="some expressions" ... ngIf="not some expression". I googled for it, and the solutions of "abuse ngIf's special goofy syntax to name the result of the condition and pray to God it's truthy or don't bother" and "abuse ngFor to loop over an array of one item to give it a name" are not acceptable answers. There were also a few competing and possibly out-of-date "install this non-standard ngLet directive that I hacked up but don't support, but don't call it with an "ng" prefix because that's reserved for the Angular team" -- but isn't there a standard way of doing such a simple essential thing, that the Angular team already thought of and included, such that other people will have some clue what's going on when they see it? And it would be nice to be able to define more than one variable at once per begin/end tag, if you know what I mean. Maybe even without using any begin/end tags, perchance to dream? Also, is there a way to easily define simple light weight macros ("snippet reuse") so you can repeat the same pattern in one or more components, without defining a whole component in all its glory and splendor with multiple files that other multiple files need to import and declare? Or even a global file of shared macros that a bunch of other templates can import, like the globally shared css declarations you can include in local css files? I've seen "ng-template", but I am having a hard time getting my head around it, compared to the simplicity and power of Genshi's py:match, that's based on xpath, and py:def, that precisely follows Python function calling conventions and that you can easily call from any normal expression. And py:match is quite useful for defining concise custom tags (or xpath patterns) that can wrap embedded content. In comparison, ng-templates seems quite clumsy and limited, and confusing about calling and scoping and passing parameters and content, which is nothing like standard JavaScript calling conventions, and reminds me more of the abomination that is Zope METAL templates. https://zope.readthedocs.io/en/latest/zopebook/AppendixC.html#metal-overview https://zope.readthedocs.io/en/latest/zopebook/AppendixC.htm... https://en.wikipedia.org/wiki/Template_Attribute_Language#METAL https://en.wikipedia.org/wiki/Template_Attribute_Language#ME... https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates I've been using and loving Genshi with Python for more than a decade (and before that, Kid, which Genshi is almost the same as, and before that Zope page templates, TAL, and METAL templates, which inspired Kid and Genshi, but totally sucked), and I love its ability to drop into Python with <?python ... ?> to define some variables or import some functions locally in the template that you can use, with real honest to god multi-line indented Python "if" statements for logic (and Python comments for, err, commenting) instead of Christmas trees of deeply nested ternary ? : operators (or rather postfix conditional "foo if bar else baz" Python expressions). Genshi also has "with" for defining scoped local variables with tags, like <py:with vars="y=7; z=x+10">$x $y $z</py:with>. And I also love Genshi's py:def for making locally defined or libraries of includable imperative "code snippet" templates you can call just like Python functions (with glorious optional named defaulting args, etc), and py:match for declaring xpath pattern matching templates that can wrap html content as a parameter (so the macro can cherry-pick out and transform different parts of the passed content with xpath), as well as taking attribute parameters. Another nice feature of Genshi is that for all directives it supports both the attribute form like <div py:if="condition"> ... </div> attached to an element that you want to keep, or the element form that dissolves without leaving an element, like <py:if test="condition"> ... </py:if> . You can also attach multiple directive attributes to the same element, thanks to the way it executes them in a well defined ordered hierarchy that makes practical sense (like "for" above "if", so each iteration of the "for" loop can be conditionalized with its own "if" evaluation), and "def" above all else, so you can define a single tag macro that loops over something then conditionalizes each iteration, then sets attributes on and adds content to the included elements. It's quite concise and expressive! <div py:def="FizzBusted(count)" py:for="i in range(count)" py:if="i % 3" py:attrs="{'class': 'orange' if i % 7 < 2 else 'blue'}" py:content="['odd', 'even'][i%2]"/> https://genshi.edgewall.org/ https://genshi.edgewall.org/ https://genshi.edgewall.org/wiki/Documentation/xml-templates.html https://genshi.edgewall.org/wiki/Documentation/xml-templates... py:def https://genshi.edgewall.org/wiki/Documentation/xml-templates.html#id4 https://genshi.edgewall.org/wiki/Documentation/xml-templates... py:match https://genshi.edgewall.org/wiki/Documentation/xml-templates.html#id5 https://genshi.edgewall.org/wiki/Documentation/xml-templates... Processing order of multiple attributes (precedence rules you must remember, but they make practical sense, and at least Genshi is quite minimal and only has a few directives): py:def py:match py:when py:otherwise py:for py:if py:choose py:with py:replace py:content py:attrs py:strip https://genshi.edgewall.org/wiki/Documentation/xml-templates.html#processing-order https://genshi.edgewall.org/wiki/Documentation/xml-templates... These two features (local variables and code snippets) are so important to me, and I'm having such a hard time figuring out how to do them in Angular, that I feel like there's whole a chapter in the Angular templating manual that I missed somehow. Thanks for any tips on how to do this kind of stuff with Angular templates! I've written more opinions about Genshi and templating on hn before: https://news.ycombinator.com/item?id=8445252 https://news.ycombinator.com/item?id=8445252 https://news.ycombinator.com/item?id=10842990 https://news.ycombinator.com/item?id=10842990 https://news.ycombinator.com/item?id=12365442 https://news.ycombinator.com/item?id=12365442 https://news.ycombinator.com/item?id=12527839 https://news.ycombinator.com/item?id=12527839 https://news.ycombinator.com/item?id=16677520 https://news.ycombinator.com/item?id=16677520 https://news.ycombinator.com/item?id=20745676 https://news.ycombinator.com/item?id=20745676 https://news.ycombinator.com/item?id=10842902 https://news.ycombinator.com/item?id=10842902
- mnm1 7y agoHow often do they release major versions? It seems every few months there's a new major version update. Having been burned once with angular, combined with this aggressive release schedule, by themselves are enough to make me not even consider angular. It could be the greatest framework in the world and I still wouldn't consider it. Not everyone is building throwaway prototypes and garbage startup code. Many people need stable libraries and frameworks that last many years and don't need time consuming updates and migrations constantly. Angular is clearly not this.
- Phenix88be 7y agoAfter 2 years of Angular madness I will send my resignation and I hope I will never work with it again. My app is a big stack of workaround stuff that might break anytime. Because that is how angular work. Some stuff work in a context and doesn't in an other. Nobody's know why ! They have so much issue on Github that they need a bot to close them after a while. They hope the bug disappear by himself ?
- crubier 7y agoMeanwhile, the web apps I wrote in 2014 in react still work flawlessly. Join us, you’ll enjoy the ride!
- Phenix88be 7y agoThank you, but I m done for the frontend shit for a while. I will be perfectly happy throwing JSON to other frontend dev.
- matsemann 7y agoThe Angular1 apps I wrote around that time are still running as well. The question is about maintaining them. Did you try to actually upgrade the react version? Lots and lots of breaking changes in that time, some really major ones along the way. Especially when upgrading react also forced one to change router etc.
- stringyham 7y agoAre you suggesting that angular apps written in 2014 would not still be working?
- gridlockd 7y agoI don't think so, the point is that Angular breaks user code often, whereas React rarely does. An Angular 2+ app built in 2016 (when Angular 2 came out) wouldn't build anymore. An Angular 1 app didn't even need a build step, so that would probably still work fine.
- thallukrish 7y agoI have spent a lot of time in Angular 2 and later in Angular 6. I had later switched to plain java script and used requireJS to modularize. I have my own orchestrator to route events like a pub-sub. HTML5 + CSS + plain JS is good enough for most simple UI.
- projectileboy 7y agoThis is a (currently) under-rated approach that would apply well to many sites today.
- Cthulhu_ 7y agoWhile I want to agree, at the same time I'm afraid of people creating their own frameworks, re-inventing the wheel, etc. Mind you, Angular feels like a very heavyweight framework, so that would be the other side of the coin. Personally I wouldn't go for a vanilla JS application, not unless the script / application part of it are minimal.
- deleted 7y ago[deleted]
- NewLogic 7y agoThe answer in this case is to use Vue or Svelte. Super light weight and avoids the pitfalls of re-inventing the wheel.
- projectileboy 7y agoI should have been more clear - my point is not so much that people should use vanilla JS rather than a framework, it’s more that the majority of SPAs I’m forced to interact with could have been implemented just as well with HTML, CSS, and a relatively small amount of JavaScript - small enough to not beg for any kind of framework at all. If the nature of the app really truly demands a full-blown SPA, then by all means go all in on something like React.
- rawoke083600 7y ago
- annnoo 7y agoThere are no words on ESLint instead of the deprecated TSLint... :/ Would really like to do the switch, but official support by Angular is more important at my company.
- theodorejb 7y agoIt's on the roadmap for Angular 10: https://github.com/angular/angular-cli/issues/13732#issuecomment-573149865 https://github.com/angular/angular-cli/issues/13732#issuecom...
- doczoidberg 7y agoJust want to say that all the Angular React comparisons are dumb. It is comparing apples to oranges. Angular is a bigger framework for developing more complex stuff. Therefore of course there is a steeper learning curve. Here are comments like "react is so much more easier because it is just functions". Why not just using vanilla js because you have nothing to learn then? Or just use binary code? It is just 0 and 1.
- spaceribs 7y agoI wholeheartedly agree, this is a false equivalency. Angular was built specifically around avoiding an entirely different problem that the heavily debated issue here of overengineering: Multiple teams that build out complicated and feature laden systems in parallel need to make concessions to allow interoperability. If your organization is culturally flat, Angular prevents the core of your application from diverging in unmaintainable ways.
- ng12 7y agoI think the problem then is people not respecting YAGNI. The vast majority of web apps should be built using React ant only the true monoliths should be built using Angular. Also it's worth nothing that React and Vue scale. They work as well for small, scrappy projects as they do for large enterprise ones. I wouldn't say the same for Angular.
- orange8 7y agoThe comparisons are valid because for 99% of the web apps out there, the makers could have gone with either angular or react. Regardless of the underlying philosophies, the choice between React, Vue and Angular is a very real one businesses have to make everyday, so it makes sense to compare them.
- sgt 7y agoAngular 9 is out? The other day I thought version 4 was the latest one. It sure moves fast!
- eternalny1 7y agoI tried updating to Angular v9 from v8 and am getting an error regarding strict mode and a "with" statement. Anyone have any ideas? https://stackoverflow.com/questions/60114758/uncaught-syntaxerror-strict-mode-code-may-not-include-a-with-statement https://stackoverflow.com/questions/60114758/uncaught-syntax...
- 5cott0 7y agoWhat % of angular apps in production are <= 1.5?
- EGreg 7y agoCan someone here please do a serious overview comparing the latest: Angular React Web Components Things are changing so quickly, I just wanted to sort of have an overview for those of us who don’t work with these frameworks daily. https://blog.usejournal.com/web-components-will-replace-your-frontend-framework-3b17a580831c https://blog.usejournal.com/web-components-will-replace-your... Can Web Components pretty much do everything without a framework now? I think Ionic moved to it for example. If we already have our own code for loading and rendering components, using Handlebars templates, what would we need to do to make them into web components instead, or make all of ours compatible with the latest React or Angular? The specifics for anyone who cares: When we began our own framework, way before React and Angular, we built our own, kinda “sane” reusable component engine. We called them “tools”. One tool on an element is a component. But you could also add multiple tools on a component, to add or remove behaviors: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools Basically, we figured it would be easier to just let Templates, HTML, CSS and JS each do what they were intended for. HTML side 1. We had <div class=“Q_Tool Streams_chat_tool” data-streams-chat=‘{“foo”: bar, ...}’> easily exporting json from php or templating engines, very readable and completely standard (no JSX or custom components). It was just slightly longer to write but provided useful metadata. It used to be called microformats back in the day. Multiple tools can be added on same element this way. The element didnt have to be a div. 2. We had handlebars helpers like {{&tool “Streams/chat” foo=bar}} and Q.Tool.setUpElement(“div”, toolName, options), or pass an element instead of “div” to add a tool on an existing element. We also had a jQuery fn method like $(“foo”).tool(“Streams/chat”, options).activate() . 3. Our users just called var element = Q.activate(Q.Tool.setUpElement(“div”))) in vanilla JS or $(“<div />”).tool(...).activate() if jQuery was loaded. * CSS side* 1. We namespaced our CSS by Modulename_toolname_ 2, Some tools took advantage of shared CSS classes defined in the module or a module they depend on Javascript side 1. We just had Q.Tool.define(toolName, constructor, defaultOptions, methods) and the tool.state would be the options merged over the defaultOptions. It was all customizable and merging was done via a smart Q.extend() function that we tweaked to eg combine Q.Event handlers in the best way. 2. Ways to access tools on an element would include Q.Tool.byId() and element.Q.tools etc. The tool ids would be autogenerated so as to establish a hierarchy of which tool was a parent. Then you could do tools.children([filterName]) and tools.parents() and so on. Traverse faster without touching the DOM. 3. We had Q.activate(container, options) to activate tools within a certain container. Javascript for tools would be loaded on demand, and tools would be added/removed on demand. We had Q.Event.prototype.add(callback, key) take a String key or a Q.Tool, so events would be automatically removed when a tool was removed. 4. You could also do Q.Tool.define([toolName1, toolName2], toolName, constructor, defaultOptions, methods) to have tools require that previously named tools already be activated on the element. This is for composability of tools, something more general than inheritance. Let’s say you have a chatroom and you want to add support for @mentions to it and https://linkscraping.com https://linkscraping.com as you type. So you’d make tools that work in top of Streams/chat. It seems to me that ANYWAY your user will have to load a Javascript file that defined your web components. And ANYWAY they will have to load javascript on demand. And ANYWAY this javascript may be packed into a single file so you’ll have to actually check whether a variable has been set before loading modules dynamically so you dont want static loading. And ANYWAY your tools may want to use shared css so you may as well namespace your CSS. And ANYWAY your default options may include event handlers or other things you can’t serialize easily into attributes of an element. And you may want to compose tools or find them with CSS so what’s wrong with using CSS classes instead of the element name for that? And ANYWAY you will want to render your tools in a readable way so why not stuff JSON into data attributes which were allowed for exactly such purposes? And ANYWAY you may want to use a powerful templating engine like Handlebars. The only part I am not sure of is the last one. Seems to me - but I am biased - that we have the optimal approach. If something else comes out we can just turn Q.Tool.define into a wrapper around window.customComponents.define. But our users won’t have to change a thing. They can continue to use Q.Tool and Q.Page and Q.exports(arg, arg) and Q.requires(module, callback) without worrying what’s underneath. Isn’t it better and more stable? But everyone got into Angular and React with its JSX etc. I think the main sell was the dirty checking (the model in Angular, the DOM in React). So you can just render a large chunk. I never saw the benefit of that. You should reason about mutations imho. Components are views with their own viewmodel, that’s all. You can update a bunch of state parameters and then call stateChanged(“a”, “b”) which would requestAnimationFrame() and update stuff. Is it so hard to call stateChanged() after changing state.a and state.b ? Do you really need to instead grok digest cycles or a virtual dom??
- rsinger87 7y agoHuge thanks Angular team. A few years ago, my team desperately needed to pick and run with a frontend framework. After a couple months to learn the Angular fundamentals, we haven't looked back. We find the framework to be extremely intuitive and flexible enough to handle any scenario we've encountered. The productivity wins have been enormous. We have about a dozen apps and anyone on our small team can jump into any project and contribute. I can't imagine how fractured our knowledge would be if we had to stitch together multiple libraries and come up with our own constructs.
- nimishgoel056 7y agoI tried to write a few more points that are not available in this article related to angular 9 features. Check this out. https://bit.ly/2SmHymg https://bit.ly/2SmHymg