14 ms·

Why does anyone use Angular in production?

• Epenthesis 5y ago
  It's interesting how different "bubbles" of software development can be. For me, as an engineer whose worked across FAANG and YC startups in San Francisco, Angular has had absolutely zero mindshare for at least the past 6-7 years. Every company I know uses React and every engineer I know knows React. So it's interesting and somewhat alien to hear it being treated as the default option.
  • brundolf 5y ago
    I think the separation is along the typical enterprise/non-enterprise split
  • ldehaan 5y ago
    I used to hear that about ruby from devs from other companies, it's just the groups you roll with that define a lot of your choices, including frameworks.
• brynjolf 5y ago
  That is a lot of quotation marks for one post, why is everything so loaded
• Zealotux 5y ago
  In case you're wondering: there's more to the article if you scroll horizontally, I won't comment on the irony of the thing.
  • charles_f 5y ago
    Also ironic, the justified text alignment, huge font and large padding which leaves room for 3 unreadable words per line on mobile.
  • tedmiston 5y ago
    To save some awkward scrolling: https://outline.com/mhWdLS https://outline.com/mhWdLS.
  • WorldMaker 5y ago
    Or shrink to mobile size or use your browser's Reader View. Horizontal scrolling multi-column was a weird aesthetic choice based on personal preference (despite bad and growing worse browser support, sigh), but it's a personal blog and as "a 90s web kid" I strongly believe weird aesthetic choices are what makes blogs personal and not just another walled garden like most of social media (or Medium).
    • ebruchez 5y ago
      I intend the following as friendly feedback. Personal is fine but that doesn't have to imply impossible to use. The main problem is that it's not discoverable, at least on MacOS where there are no scrollbars. I found the horizontal scrolling by chance after trying every key on the keyboard. In the meanwhile I had already scanned the article using the Reader mode in Safari.
      • WorldMaker 5y ago
        Personally, I think that a UX bug on Apple's side that they lost scrollbars and any hint of "more to see". As an iOS and iPadOS user I get so frustrated every time I discover a thing scrolls that wasn't obvious. I have observed that almost every iOS/iPadOS user (mostly subconsciously) "twitches" constantly over apps trying to find things that scroll. I wish Apple would provide at least something of a better user experience here. This is also one of the things where I'm disappointed that browser support for multi-column has only grown worse over time rather than better: I tried to intentionally set it so that there would be at least some next column "bleed through" horizontally in CSS and that (mostly) worked when I built the CSS theme but WebKit, Blink, and Firefox all moved to implementations that always balance columns evenly in viewport space rather than what the CSS specifically asks for. (And Edge Classic died, the one browser that really cared about good multi-column experiences.)
        • toomanydoubts 5y ago
          I get this issue on Android Chrome when using the "Desktop Site" version. Personally, I believe the UX problem is with the website. You seem to be aware of the problem and yet decided to keep a broken version. That's a UX decision made by you. The web is top-to-bottom, every user has this expectation. The usual mouse has a top-to-bottom scroll wheel, not a left-to-right one. Maybe it's not what you want, but it is what it is. You can either accept that fact and use a top-bottom layout, or accept the fact that you made a deliberate decision to create a confusing UX.
  • riidom 5y ago
    Admittedly I like the column-based layout. Just the scrolling should work via mouse wheel and stop at whole columns. Not sure if I would want this on every website I visit, but it's a nice change. At least it doesn't scream "materialize!" or "bootstrap!" :)
    • WorldMaker 5y ago
      I still think it is a shame that Microsoft's proposed scroll-translation CSS still hasn't made it into the CSS multi-column standard (and also didn't survive Edge Classic to Chromium Edge shift either). It's been on my backlog for a while to find a good JS replacement but haven't been happy with the ones I've tested: https://github.com/WorldMaker/lcars-moderne/issues/1 https://github.com/WorldMaker/lcars-moderne/issues/1
  • nimih 5y ago
    If you make your window small enough to hit the tablet/mobile breakpoint, it collapses into a vertical layout, which is much more pleasant. I honestly cannot fathom what would possess a person to make horizontally scrollable columns like this, since it's both difficult to use and introduces novel typographical defects such as widows and orphans.
    • itronitron 5y ago
      While the horizontal scroll isn't immediately obvious I found it easy and enjoyable to use as I can just start reading at the top of the next page instead of concentrating on not losing my place during a vertical scroll. Also, if a typographical defect has a name (widows and orphans) can it truly be novel?
      • WorldMaker 5y ago
        There is a JS library script tag on the site to try to correct the worst widows/orphans and some other typographic defects. It's after body load so as not to slow time to first paint and I don't think all browsers correctly readjust multi-column layout after its corrections/adjustment. The caniuse statistics for CSS native support for widows/orphans correction is much better today than when I last worked on this CSS file: https://caniuse.com/css-widows-orphans https://caniuse.com/css-widows-orphans
      • nimih 5y ago
        Novel to web pages, is what I meant. Software such as TeX and MS Word have a considerable array of (sometimes quite complicated!) tools for dealing with such things, and the absence of such concerns from web development was something that I had never really thought specifically about until seeing a heading appear right before a column break on this article, followed by an orphan in the next one.
  • YetAnotherNick 5y ago
    Missed chance to use "In case someone doesn't know it, ..."
  • hodgesrm 5y ago
    Thanks, I would have missed that completely without your comment.
  • earthboundkid 5y ago
    If the author is out there: Add scroll snap to the text box! Without it, you're constantly misaligned, making it hard to read. Scroll snap is one of those great new CSS properties that makes thing that used to be hard easy.
    • jonny_eh 5y ago
      or… I dunno… vertical scrolling like literally every other web page?
    • WorldMaker 5y ago
      I've considered that, but I feel scroll snap is actually the opposite of the intended affordance for what I was going for. I don't want the scroll to be exact. I want columns to peek out just a little bit in either direction in a "more to see" way. (I had that for a while with this CSS but browsers dropped some support for it.)
      • spcebar 5y ago
        There's not a bit of paragraph peaking in, there's a bit of the paragraph off screen, so to get everything in the paragraph I have to scroll right and then left whenever I get to the end of a line.
• aliswe 5y ago
  This font kills my eyes (on mobile), low contrast color, justified text ... i will have to try on desktop, shame because it was really interesting
• akmittal 5y ago
  I don't know where the author lives but I haven't seem that everyone claim to know Angular. Quite the contrary everyone claim to know React. Yes Angular is not great and most people know it. I just see almost all new applications using React/Next/vue
  • kemiller2002 5y ago
    Interesting. I'm in the U.S. Midwest and most C# devs I talk to don't want to touch React, because they "already know Angular"
    • akmittal 5y ago
      Typescript was largely inspired by C#. Because of Angular following OOPS patterns it is relatively popular in C# developers. In pure front end developer land Angular is quite behind React in popularity.
      • brundolf 5y ago
        > Typescript was largely inspired by C#. Sorry, but I have to correct this every time I see it on here: TypeScript is accommodating to C# developers, but it's equally accommodating to developers who don't want to touch classes with a ten-foot pole (and to everyone in-between). React benefits from it just as much as Angular does, etc.
  • tluyben2 5y ago
    Most devs from India that I talk to are learning react but know angular. They would like to continue with angular but it is not something that is excepted to companies we sell to anymore.
  • smnrchrds 5y ago
    I did a quick search on Indeed and compared the number of results found. It's not scientifically rigorous or anything, but it should give us a rough idea of where Angular and React stand compared to each other. The search terms where "Angular JavaScript" and "React JavaScript" and similar without the quotation marks. Angular, Anywhere in US: 25,248 React, Anywhere in US: 29,197 Vue, Anywhere in US: 8,032 Angular, California: 2,658 React, California: 4,643 Vue, California: 1,134 It seems like Angular and React are both very popular, but Angular is a bit less popular in California than elsewhere in the US. Vue is less popular than both, but it is a bit more popular in California than the rest of the US.
• cphoover 5y ago
  This website is so hard to read from contrast to the scrolling. Can someone copy the text here? *EDIT*: I did it here (and for the most part I mainly agree with the sentiment behind this article): # Angular is Rotten to the Core I find Angular an impressive front-end framework for just how badly it is designed, top to bottom, and yet how large of a cult-ish following it has. There exists a weird “everyone knows it” mentality that in practice seems to be entirely an illusion. There is the strange “no one got fired for picking Google” echo of ancient ibm mistakes exacerbated by Google barely dogfooding Angular (and arguably never successfully). There is the awful internal politics of Google that have produced many horror stories from former Angular developers, former open source community contributors, and combinations in between, and an impression that the rabbit hole goes only deeper if you could dig beneath Google NDAs and secrecy. ## Why does anyone use Angular in production? I’ll start with the sociopolitical weirdness and save the real meaty technical stuff for the end. Let’s think of it like one of those long, mostly useless food blog narratives to air some grievances before the technical equivalent of a recipe. ## “Everyone Knows It” When we started a greenfield project at my employer (opinions here are mostly mine and not that of my employer and other usual disclaimers apply, of course) I suggested React, as I was comfortable and happy with React in other projects, and even did some prototypes in early testing in React. I was brought on to the project to be “the backend expert”, so I was overruled because “no one knows React” and “everyone knew Angular”. I didn’t know Angular at the time, other than gut instincts from skimming tutorials that it was “Enterprise” and “Bloated” in all of the worst senses of both words, and some hesitation/general “sense of doom” from reading the blogs of Rob Eisenberg (because I had used Durandal successfully in previous lives and Aurelia semi-successfully in more recent projects; I’ll come back to all of this later in this post). As soon as we started digging into real world usage of the application it became very apparent to me that everyone that claimed they “knew” Angular, simply didn’t. Out of frustration with application performance and modularization needs and so many little problems, I found myself increasingly having to become an expert on Angular, and the more of an Angular expert I’ve become the angrier I’ve become for using Angular at all. I think there are two big lies that add up to an illusion that “everyone” knows Angular: the Angular template language uses an `.html` file extension, and Angular Dependency Injection at first glance looks “Enterprise” and familiar to Java developers especially. (Sometimes C# developers too.) The first I think is the biggest illusion and the one that causes so much trouble. React’s jsx/tsx looks “weird” at first, and “no one knows it” without at least some learning curve. Vue and Svelte aren’t liars either and people realize there is a learning curve to learn their `.vue` and `.svelte` templates. Like the much mocked Jurassic Park lines “it’s a Unix system, I know this”, despite the many variations of Unix and the weird ui shown on the screens that wouldn’t have been familiar to anyone, “it’s an html file, I know this” is an amazing misdirection of Angular’s. Angular’s template language is no less a complicated template system like `.vue` or `.svelte` or `.jsx`, but that first impression from junior developers that they know enough html it will be “easy” and they already know it is amazing (and wrong). Also, I realize that Angular themselves refuse to call it a “template language” and go out of their way to call it a “view engine”. They seem to insist that you could ship the template language’s html to a browser (as Knockout used to do, using only html compatible custom attributes, back in the day), but at the point where you have an aotcompiler for it is the point where I think you have to admit it is a custom language. At least in my opinion. Angular’s insistence that it is “just using html” seems so much intentional propaganda at this point to keep the “everybody knows Angular” reputation despite an incredibly complex template language compiler and build process. ## “No One Got Fired For Picking Google” Google, for the most part, has never used Angular. The few projects that have obviously used Angular are notoriously awful performing applications. The largest and most commonly noticed is the gcp cloud console. Performance is definitely something it is not known for. Google and its proponents will argue that the gcp console cross-cuts a huge number of teams that all have to deliver components and maybe don’t all individually have the right performance experts and collectively don’t have the right incentives aligned to better coordinate performance across teams and so a lot of the performance is left at “out of the box” configured from base settings. (Despite gcp being a huge revenue source for Google, a major competitive battle front with aws/Azure, and presumably time wasted spent configuring things ingcp can be directly associated with time not running billable operations.) Angular proponents would point out how great it is that Google doesn’t get “special privilege” and it’s almost a badge of honor that one of the largest instances of Angular usage in the company performs so poorly. This kind of “fairness” sounds great on screen photons, but seems immediately and obviously flawed. Is it really that great that everyone is equal in having bad performance out of the box? If engineers “down the hall” and paid out of some of the same budgets can’t get it to perform, who can? One of the big lies implicit in the “no one went wrong going with Google” thing here is that it implies that Angular works well at Google scale, and yet here clearly it falls down. Regardless of what Google thinks of itself, Google isn’t special: other companies have multiple cross-cutting teams involved in building websites/dashboards/consoles/portals all together. It isn’t some special Google-only workflow, it’s a common problem, that Angular is advertised to solve. (It’s one of the oldest reasons for component-based systems since the invention of the computer.) It’s possible that there is a use case that Angular was designed to fit. (That’s somehow not using a component model built to be a component model usable by multiple cross-cutting teams, despite that’s why they have a component model.) But I’ve come to doubt that given it doesn’t really seem like Angular was designed for specific workflows and instead it was designed to meet the goals of specific egos. ## A Toxic Workplace? Here especially I can only make second and third hand speculations. Please take all of this with a grain of salt, try to find your own primary sources, and realize that even primary sources that are publicly posted to blogs such as Medium are filtered a degree or two sometimes away due to Angular’s relationship with Google NDAs and other secrecy tools. The reports are that Angular is among the many projects at Google that appears to be following Ego-Driven Development. (Google is also not special here and certainly plenty of companies practice Ego-Driven Development, but Google has picked up something of a particular reputation for it in the way that it infects their promotion culture and odd incentives to create products that duplicate existing ones at the company and disincentives to support and maintain existing ones.) Angular tries to be an open source community-supported project (in addition to getting the marketing weight from Google behind it), so some of this dirty laundry has aired very publicly. (Compared to what we can mostly only speculate about, say, Google’s revolving door of chat apps.) Most of what I followed second hand was the saga of Rob Eisenberg. I had been following Rob because of Durandal. I loved Durandal for a few years. It was a great minimalist spa framework that left the hard template/dataflow work to Knockout and then just filled in the spa gaps (routing, component lifecycle). On the back of Durandal Rob was invited to work on Angular (in the awkward Angular.js to Angular transition years). There was some sort of falling out some time into that effort, presumably for creative differences, and at the end of that Rob created Aurelia as an answer to Angular’s goals. (I used Aurelia for a project before Angular. I didn’t like it anywhere like I liked Durandal and kind of disliked it. Though in context of having now worked with Angular I can see better where it came from and some of how it wound up departing from Durandal’s principles. I don’t expect to want to use Aurelia again on a project, but I’d definitely recommend it to any “Angular shop” that wants a lighter weight alternative that “everyone knows” and possibly has more of a pit of success than Angular. Faint praise, of course, but still praise.) I offer this (possibly?) slander mostly as an appetizer to the technical discussion. It’s not entirely unrelated, as I find it interesting background. It answers to at least sate some of my curiosity how Angular got designed the way it was and who it was maybe designed for. (Ego being an obvious and clear answer to both.) ## No One Knows Angular (But I Know More Now, Sorry) My fast ramp up to team “expert” on Angular came from a path that was rare and while I would never assert that it makes me a better “expert” than most on Angular, it certainly makes me a peculiar one, especially in being able to pinpoint to some key things were Angular has created “pits of failure” (where it’s just too easy for developers following “best practices” and tutorials and trying to do things “the Angular way” find themselves failing through no fault of their own). One of my odd paths is use of Aurelia before Angular. Aurelia has a better Dependency Injection system than Angular. (In part by going all in on Typescript’s experimental decorators support rather than half-in. Though I think both are wrong to use an *experimental* flag in Typescript based on a tc39 proposal that has been rejected one and a half times.) In particular, Aurelia tree-shakes better out of the box and without a lot of config work. Aurelia’s cli is better at finding circular dependency mistakes and things that may not tree-shake well (and suggesting fixes when noticed). A lot of Angular’s easiest to fix performance problems stem directly from the overly complicated and not very good “Modules” system that gets in the way of all of the smarts and advances packer tools have put into es2015module support and es2015 module treeshaking. The “Modules” provide a second parallel import system that is harder to tree-shake, easily gets out of sync, and actively gets in the way to getting bundle sizes down. The other somewhat peculiar path was that I’ve been a Reactive Extensions fan for a long time. I’ve done C# ui apps with Reactive Extensions from when ReactiveX was still fresh out of Labs/Preview kindergarten. In C# I use ReactiveX (and more recently IAsyncEnumerable InteractiveX) as extremely useful tools in complicated (but easily described by ReactiveX) backend dataflows and multi-threading and plumbing. I used Cycle.js, a js ui framework built for first class ReactiveX, for years before running off to React for the larger ecosystem. Even in React I tend to keep redux-observable as a tool in my arsenal for complicated data flow. I’ve even built some interesting [Discord bot logic “backends” in redux-observable](http://blog.worldmaker.net/2019/10/08/redux-observable/ http://blog.worldmaker.net/2019/10/08/redux-observable/). I know ReactiveX and RxJS pretty well at this point, their strengths and weaknesses, the differences between hot and cold observables and when you want each to apply to which problem, when and where to apply ReactiveX/RxJS as great tools (and how best to do in places that don’t phase junior developers too much), and some good ideas where ReactiveX/RxJS isn’t the best tool for the job. If there’s a core decision in the core library of Angular that is most emblematic a pit of failure it’s the incredibly half-assed adoption of RxJS. This one decision, this one broken usage, affects everything else, contributes to so much of the performance churn of people’s apps by default *especially* when they believe they are following best practices. Angular intentionally ignores RxJS best practices in setting its own “best practices”. Angular decided that they wanted to mix all of the concerns of RxJS Observables, BehaviorSubjects, and classic Node-era Event Emitters in one core EventEmitter class that is the worst of all worlds. This adds an RxJS dependency that bloats *every* Angular app everywhere no matter how well the developers know RxJS. RxJS is a huge dependency to do that with. RxJS has gotten better at tree-shaking itself, but it is still a huge chunky library. RxJS is hard to learn. It does have a huge learning curve. It’s not just something “everyone knows”. If there is a bigger bright neon sign that should be blaring on top of all the assumptions and assertions that “everyone knows Angular” it should be “No one knows RxJS”. You can understand why Angular developers might want to provide “escape hatches” from RxJS because they want make the framework more approachable. However, by ignoring RxJS best practices and making the EventEmitter publicly a BehaviorSubject in api, Angular gives developers an escape hatch deep inside in the core for ignoring RxJS best practices (BehaviorSubjects are meant to be generally avoided, but when used as internal details of an encapsulated api), an excuse to avoid learning RxJS until it is far too late, and almost always immediately falling into a pit of failure that results in bad performance and the many of the worst of singleton “god objects” that are just nasty global variables with much more complicated APIs. Right out of the starting gate, Angular “best practices” cause so much of their own misery. It’s a worst of both worlds situation: why take on a huge, complicated dependency like RxJS if you are just going to immediately provide system breaking escape hatches? These escape hatches then breed like rabbits, having a ripple effect on the entire ecosystem. The few libraries that are more likely to use RxJS for complex behaviors are more likely to get it wrong simply by following the bad example directly from right inside Angular’s core and leaking BehaviorSubjects everywhere. The ones that don’t want to use RxJS just sit on complex webs of escape hatches and easily broken state mechanics (especially if they fall into just using global singletons everywhere). So many tutorials and examples of “good code” are littered with bad RxJS usage (BehaviorSubjects leaking across encapsulation boundaries, Observable subscriptions without matching unsubscriptions (classic malloc without free; reference counting is hard and everyone is bad at it and will be for all time), cold/hot problems, over-subscriptions, and more even more complicated RxJS data flow problems (that at best are just too much work and at worst are memory leaks and performance problems waiting to happen). The ripple effect happens inside the Angular house too as other Angular components can’t make up their minds to embrace RxJS or not, can’t make up their mind how many of their own escape hatches they need to add, and just constantly adding to the escape hatch proliferation problem. Angular Routing tries to use RxJS deeply and while it doesn’t let BehaviorSubjects directly escape into its public apiit offers an almost equally bad “snapshot” escape hatch. Angular’s HttpClient embraces RxJS deeply in its outputs, but for what are essentially over-weight Promises. It doesn’t take Observables for input, nor does it use them in the middle of its processing pipeline, and in being used for not much more than over-complicated Promises it still has ripples like the other escape hatches. Some developers start to associate Observables as “bad Promises that you can’t use async/await with” and take away from it that `subscribe` is just like Promise `then` and use it like bad pre-async/await era callback hell. It directly contributes to the subscribe without unsubscribe problem in so many tutorials and sample code. There actually is an easy solution that these tutorials/samples could use: RxJS Observables provide a good `toPromise()` implementation that does the subscribe and immediately unsubscribe after first value dance, and lets you use traditional async/await. (I’ve made this suggestion to at least a couple of tutorial authors I’ve found. But there’s no way I alone can post that suggestion to the expansive number of bad tutorials in the Angular ecosystem.) Of course, Angular’s HttpClient could just return Promises if that is 99% of what people use them for and most uses of HttpClient are single value expectations. HttpClient offers a somewhat plausible reason for this: with an optional config parameter HttpClient will provide Observables with more values that include a stream of progress values. In theory, this might be useful for better progress reporting in the app, but in practice I’ve still yet to see a good library take good advantage of it. HttpClient isn’t in a library that is setup (in current Angular “organization” structures) to offer an out-of-the-box ui component to make use of it. It’s a feature that might as well not exist given very little good guidance on how to use it (and again that I’ve never seen anyone really take advantage of it). Even in trying to add progress reporting to projects I’m working on, it was much easier to build a dependency-injected HttpInterceptor that kicks off and stops NProgress (and isn’t far removed from things I’ve done all the way back to Durandal and its middleware). HttpInterceptors are “middleware” and at least they aren’t intentionally built to be RxJS escape hatches, but here it is the one escape hatch I found myself particularly using from a provided Observable, because it was so much simpler. Angular’s Template Language doesn’t bother with first-class support for Observables (though that would potentially make things a lot cleaner; Knockout called its bindings Observables for a reason, way back in the day). Instead the template language relegates it to AsyncPipe, which I was angry when I found it in its almost hidden spot in Angular’s documentation which also relegates it to something of an afterthought. The other obvious thing that would clean up a lot of tutorials/samples (including and especially here in Angular’s own documentation!) with regard to Observables is if far more tutorials/samples used `| async` pipes instead of manual Observable subscribe/unsubscribe in example components. (Or you know, if Angular had added Observable support first class into the template language instead of as an afterthought.) Again, RxJS best practices heavily suggest reducing the number of subscribe/unsubscribe to a bare minimum, and yet almost every example in Angular’s documentation (and from there so much of the rest of the ecosystem) use manual subscribe/unsubscribe rather than something like AsyncPipe that can handle it automatically. Though I realize that doing that would mean more Angular documentation would need to teach RxJS sharing (`shareReplay(1)` being one of the most common in my arsenal) and that would risk needing to teach the hot/cold Observable problem and directly risk that “everybody knows Angular” reputation for the actual learning curve (that’s still there anyway, just hidden behind bad documentation and bad practices as “best practices”, because apparently Angular is okay with bad performance out of the box). At this point I’ve contributed more than I should have had to to fix RxJS-related documentation mistakes to the wider Angular ecosystem. I’ve left notes to tutorial writers how they might better their tutorials (though there is no incentive to do so, because “everybody knows Angular”). I’ve glanced at the bad Observable code in entire libraries, shuddered in horror, and wrote my own in a third of the code (and been thankful for the production performance problems I avoided). Two of the worst offenders I’ve seen are Angular Material and Angular cdk, and if Google can’t get Observables right in its own “second party” libraries, I don’t blame anyone else in the ecosystem but the Angular core team for these problems. Also, tossing Angular Material and Angular cdk out the airlock was a huge “performance fixing” development effort on my part (after what the frontend devs defaulted to), and keeping them out is a larger effort because so many tutorials and other third party components “suggest” them (“no one got fired for picking Google”). ## Suggestions For a Better Angular (“Project Gawky”) So I’m not a monster, and this is a “recipe” blog like I said, so I’m happy to leave with a thought experiment of what something like Angular would look like if it properly embraced Observables instead of being wishy-washy with them all the way deep into the core. I think Observables are a great idea for a frontend framework (again, I used Cycle.js for some time previously). Let’s call this thought experiment “Project Gawky” (as a fun synonym for “angular” when referring to a person that also implies a double meaning of observing). At one point I toyed with the idea of attempting a toy proof of concept for “Project Gawky”, but so far as I know Angular’s “Ivy compiler” for its template language is not documented at all for reuse and I have no interest in building my own template language and especially not in trying to emulate the Angular template language just for a toy proof of concept. Taking for assumption that the resemblance to html of Angular’s template language is a part of its success and something worth keeping, I’d start from what you can do if the only bindings you can do are Observables. The idea is basically RxJS-powered “modern” Knockout. First, it would get rid of the incredible weirdness that is Angular’s two-way binding syntax (the strange bag-in-box `[(thing)]` that a lot of people don’t like or understand in Angular templates). Supporting which is an incredibly odd “code behind” pattern involving a normal property and an `EventEmitter` for when it changes, but only by the component itself because you want to avoid infinite loops by it accidentally re-emitting values it got from other components/Angular. But that’s a nice to have “side effect”, the real meat is what you can do once every output variable in the template is expressed as an Observable: combination and scheduling. For years now, React has been building a bunch of initiatives in somewhat parallel (Suspense, Concurrent, etc) to do a lot of complicated update combination and scheduling: in a nutshell, they want low priority dom updates to happen during the browser’s `requestAnimationFrame`timer, high priority updates (such as to inputs that the user is directly interacting with) to happen as soon as possible, and they want to be able to combine all of the updates to entire component sub-trees at once rather than showing partial updates as data is loaded. These initiatives have been fascinating to watch, especially as some of the information React is doing for this combination and scheduling work is “reverse-engineered” from the “pull” and “diff/patch” nature of the Virtual dom. React has been doing some interesting smart things to gather more information, and the underpinnings of Hooks are fascinating in relationship to these efforts. (Though Hooks are required for some of it to work, they mostly just light up more “smarts” and even class-based components still sometimes benefit.) An Observable based template engine potentially has a much easier time doing such complicated combination and scheduling with the comparative “push” nature of Observables. So easy and cheap it’s nearly free and out of the box. Combinators like `combineLatest` are the bread and butter operators for why you’d pick something like Observables in the first place. Observables have a direct concept of Schedulers which provide timing mechanics and moving some updates to happen at `requestAnimationFrame` may be as simple as adding `throttleTime(0, requestAnimationFrameScheduler)` to the right pipelines. Given an aot compiler (like Ivy) you could sometimes bake entire, complicated Observable pipelines for entire component trees at build time (including smart uses of combinators and schedulers) with little to no runtime code. In theory it is so much of what React has been trying to do with a lot of (successful and interesting) hard work in potentially a simpler and “cheaper” package deal. Observables-first “Project Gawky” should reduce a lot of things that Angular relies on Dependency Injection for, or the very least reduce a lot of singletons acting as global state in the average project, so I could even see trying to use Dependency Injection still for wiring up some of the more complicated pipelines. di in that case might be a good way to better encapsulate BehaviorSubjects and remove their need from all “user” code. BehaviorSubjects are mostly an escape hatch around essentially circular dependencies and while di sometimes hates circular dependencies, in the case of Observables they make a certain sense. (Cycle.js’ name is not an accident.) (To contrast with Cycle.js for the very few developers curious: Cycle.js’ Virtual dom approach has a very “Observables first” definition. Inverting it to be html Template “first” like an RxJS-based Knockout should feel very different from the approach of Cycle.js. “Smart templates” doing some pipeline management such as`requestAnimationFrameScheduler` is something mostly sort out of scope for Cycle.js, leaving that essentially for the “drivers”/Virtual dom to reverse engineer similar to React, though you can do some such things by hand to give it a push. I’m not a fan of Angular’s Dependency Injection system, and while I’d simplify it, I can see a use for a Dependency Injection system in an Observable-first “Project Gawky” to clean up or at least simplify some of the harder bits of wiring/plumbing I recall from Cycle.js.) All it would take is taking Observables seriously and first class with fewer escape hatches. It would be a lot harder to learn, but might have a much greater pit of success (smarter update combination and scheduling, right there out of the box with little to no developer config or wiring needed), and presumably a smaller pit of failure. I ran out of interest in trying to build a toy “Project Gawky” proof of concept when I didn’t see an easy way to hack the Angular template language compilers for such an experiment, but I’ll happily code review and maybe pitch in if someone else wants to toy with the idea.
• FloayYerBoat 5y ago
  Can you trust the opinion of anyone using that design / layout?
  • Apocryphon 5y ago
    Looks like the site has been around since 1998 (includes link to original iteration) http://worldmaker.net http://worldmaker.net Using the LCARS style gets geek points for retro sci-fi, but dang that font color is unreadable.
• vanillax 5y ago
  This article absolutely blows. How is this front page material?
  • nick_ 5y ago
    HN front page is regularly 95% hot takes disguised as technical blog posts, or pretentious/esoteric JS/Rust libraries.
    • cheeze 5y ago
      HN often reminds me of that article about how a majority of what you read on the internet is written by insane people.
    • aliswe 5y ago
      If anything, I would call this a technical blog post disguised as a hot take.
  • arenaninja 5y ago
    The headline must resonate with enough visitors
  • johncena33 5y ago
    HN has been slowly becoming Twitter. It's hot takes, dunkings, and outrages. It started with and mostly limited to Google bashing (as the current aricle is). Unfortunately it's going to spread. HN is on its path to become another toxic internet forum or social media.
    • ldehaan 5y ago
      Back before everyone was a bag of sad cats; a toxic internet forum was just called a forum and the people were amazing. Still are. I use IRC and message boards still and it's just fine. I don't use freenode anymore, duck that guy to quack.
• marcellus23 5y ago
  it seems the author is trying to recreate the LCARS GUI from Star Trek. Not sure why the horizontal scrolling though.
• ramoz 5y ago
  React is fun and simple, makes juniors look senior for a bit, until apps get complex. Sr react devs build even further complex abstractions due to the nature. Angular development is reliable. You know what you're getting and what comes with senior development. (Ive moved 2 prototype projects that needed to scale from React to Angular).
  • ben940830298432 5y ago
    The react app I have seen at my current work seems to use a different pattern per file which makes it nearly impossible to figure it out.
    • laurent92 5y ago
      Plus the “any exception makes the screen entirely blank”.
  • josteink 5y ago
    > Angular development is reliable. You know what you're getting You get a product built on top of a framework which does 200+ things you never asked for, can’t disable, and whose the complexity of is reliably causing your simple code to crash in ways which are impossible to analyse, debug and explain. I’ve been burnt a few times on this, and months down the line, my simple CRUD angular apps still have unexplainable, unfixable issues which is destabilising some of our backend systems. And we can’t fix it. Because nobody has any fucking idea what goes on with Angular internals when shit blows up like that. And yes, you can rely on that. I’ll literally take anything not Angular over Angular at this point. At least I should be able to reason about what I’m shipping and fix bugs once reported. May it die in a fire.
    • rezonant 5y ago
      I have none of these problems and I've built a ton of Angular apps. Angular does have a steeper learning curve for new developers but once you get past it, it is much easier to maintain a large application. React is the opposite-- it is very easy to get started but a general lack of opinionation and guard rails means that a project mostly built by junior devs will start to show cracks sooner.
• AbraKdabra 5y ago
  I know this site is old and stuff, but if you're looking at this website and thinking wow what a great idea horizontal scro... no, don't, it's a bad idea in every way possible.
  • moate 5y ago
    Shocking that the author is a self described "backend guy" with UI like that...
• crooked-v 5y ago
  For me, the worst parts of Angular are all about it elaborately reimplementing things that already exist in Javascript. I think the most obvious example is its template expressions and pipes. Instead of being able to have Just Javascript, there's an entirely new syntax they want you to learn and to write special handlers for, and the extra overhead that comes with its parsing behavior.
• whalesalad 5y ago
  The pot calling the kettle black, no?
• TheChaplain 5y ago
  I must have missed the memo or something? Angular is used heavily at my work and we manage to please thousands of users every day, developing in it isn't bad either. I use it for my personal projects too, and yeah so far no problems and I manage to crank out stuff in a pretty decent rate.
  • ldehaan 5y ago
    Yeah it's all about what you know and who you know. I used to think ruby devs were clowns as a Drupal dev, it was dumb, I have since used ruby a bunch just fine, same with X language vs Y language, it's just humans being humans. If you want to know where racism comes from talk to a tabs guy about spaces (but only if he uses a Mac and says he does all his development in a text editor). Or a Mac guy vs a windows guy etc.. I used to fall for that junk but I just grew out of it. Give a dev enough time and he'll realize it's all the same just different words and delimiters, and then you can think about bigger things.
• deleted 5y ago
  [deleted]
• bythreads 5y ago
  ...zone.js...
• bythreads 5y ago
  Seriously zone.js is enough to just walk away
  • rezonant 5y ago
    Zone.js is very useful. You can observe the life time of a chain of asynchronous operations without requiring that they return promises or use callbacks. This makes it very useful for providing "no code" SSR of an otherwise frontend framework. You can reliably know when the page has completed rendering, because the zone has become "stable", that is to say it no longer has any way to run any handlers for future events. Zone locals also allow you to maintain "task-specific" state, for instance allowing you to access the current request being processed without it being passed around. Another use case is having your logger show context information- Frameworks like RoR have done this forever- they show the request ID on each log message that results from processing that request. I don't think there's any good way short of passing the logger around everywhere to pull that off in Javascript short of using Zones. What it does to Promise and other parts is definitely an annoyance, but the benefits you get for it are a lot. If Zones were a standard part of the JS runtime none of that "patch the world" would be needed, as the JS runtime would support it out the gate. Zone.js was always meant to be a polyfill of the Zone concept on the way to standardization. It is unfortunate that standardization has failed because I think it's a very useful idea and there isn't any real alternative to achieve the same goals.
  • josteink 5y ago
    And don’t get me started on silently hijacking my clean ES-promises and turning them into Angular’s own ZoneAwarePromise, managed by its own terrible, undebuggable microqueue. It’s literally impossible to write clean code which compiles to clean code with Angular.
• emerged 5y ago
  I’m genuinely impressed at how bad this site design is.
• gkoberger 5y ago
  This is dramatic. A lot of developers put a lot of time and effort into trying to make something that improves developer experience, and trashing them is shitty. Is there things wrong with Angular? Yes. Is it my choice of frameworks? No. But Angular came out years ago, back when jQuery was the defacto standard. And much like how jQuery (and Flash before that) isn't in vogue now (nor should they be), Angular presented a lot of unique ideas about how we could be thinking about building for the web, and for that I'm appreciative. IIRC, Angular.js was originally built as a prototyping tool for designers. It got popular, and the creators did their best to make it work. It didn't. But it's a lot easier to write negative articles such as "Angular is rotten to the core" than it is to create a javascript framework.
  • turtlebits 5y ago
    Are you talking about AngularJS? I loved AngularJS for its productivity gains, which IMO inspired Vue. Angular however, is a totally different beast and I wouldn't touch it with a 10 foot pole.
    • brundolf 5y ago
      Also known as Angular 1 and Angular 2+ for those confused by the (very confusing) branding. Angular 2 was a ground-up rewrite in a very different style.
  • md8z 5y ago
    That was my initial thought as well, but if you read the rest of the article there actually is quite a lot of technical details. It's not just trashing developers. I think the title could probably be changed to be less inflammatory.
  • simon04 5y ago
    > Angular came out years ago, back when jQuery was the defacto standard You seem to be confusing Angular.js (≤1.8) with Angular (aka Angular.io, ≥2.0). The latter is an incompatible rewrite of the former.
    • 5y ago
• DeathArrow 5y ago
  Maybe Angular is a poison pill invented at Google to slow the competition? I had to work with Angular and I hated it, especially the compilation times and the fact it is very opinionated. But I hate everything front-end that is not Javascript + jQuery. I suspect I would hate React, too. Thanks God I no longer have to touch front-end at work!
• Blackthorn 5y ago
  > Google, for the most part, has never used Angular. This is completely wrong. Though I wish it was true, I've used it and I wish I didn't have to.
• miiiiiike 5y ago
  Angular has its fair share of problems. For example, issues can be left open for a very long time and the way Google requires the Angular team to ensure that the many, many, internal projects that use Angular do not break creates a lot of development overhead and slows the pace of development. I actually had a great conversation with a core Angular dev just today where he outlined the whys of some of the issues. The Angular development team, not including managers, developer relations, etc was described to me as “about half a dozen people”. It’s a very small team with a big task. I think that Angular+RxJs+NgRx is a great way to build apps. Once you really get the hang of it there’s nothing like structuring your app using DI+directives+Observables. I recently created a drop dead simple, performant, and insanely reusable, intersection observer directive constellation that’s easier to use than any other IO library I’ve seen to date. It was maybe a hundred lines in total. I submitted my first PR over the weekend. It’s easy to complain about Angular, but, I’d like to see more people who use it show up to help out. Yes, the corporate side of things slowing the community down is annoying.. But with enough external devs the process could evolve into something more decentralized. Maybe? Who knows unless you try.
  • WorldMaker 5y ago
    I vetoed NgRx in my projects because I didn't think it was a good RxJS citizen either. I've used redux-observable a bunch in React and also in pure Node projects and NgRx on the surface feels like a relative to redux-observable but digging into it below the surface I wasn't happy with it at all. I love RxJS and so many of my problems with Angular come directly from how it and its ecosystem don't use RxJS well and don't set up developers, especially junior developers, to use RxJS well.
• rdevnull 5y ago
  interesting article! some feedback: it looks like you host your blog on github pages .Please add an SSL certificate, it is free and would eliminated the annoying browser warning. LCARS CSS is nice and original, perhaps you can change the font/contrast to achieve something more readable (just in case here are some ideas https://www.thelcars.com/themes/ https://www.thelcars.com/themes/ )
  • WorldMaker 5y ago
    Thanks for the suggestions. I hadn't realized Github Pages supported SSL today for custom domains, missed a Let's Encrypt at some point I suppose. Trying to get that activated. I'll have to look into the mixed content warnings later. Reading the HN feedback I did make a note to adjust the body font color: https://github.com/WorldMaker/lcars-moderne/issues/4 https://github.com/WorldMaker/lcars-moderne/issues/4 Might also play with some of those newer color theme ideas, the Lower Decks inspired ones spark joy for me. (I used a different theme site for some of the colors that was at lcarsdeveloper.com and seems maybe done now. This one seems similar and I'm wondering if they just had to change domain names at some point.)
    • rdevnull 5y ago
      you are welcome! enabling SSL should just be a click on github and is very convenient. I appreciate that your site is different and not like everything out there. Probably just adjusting the font color would go a long way in terms of readability but hey...it is your site so if you like it and gives you joy as it is perfectly fine :)
    • ldehaan 5y ago
      I watch lower decks with my kids instead of bluey now:D it's gggrreat! I do like the color scheme they put together as well, that should be cool, you should name a class boimler :D
• thayne 5y ago
  The horizontal scroll would be a lot less annoying if you could use your scroll wheel to scroll through it.
  • WorldMaker 5y ago
    I agree. I miss being able to scroll with the mouse wheel. I wish the CSS for that had been standardized. I had been seeking good JS options, but still sadly haven't found a good one that works reliably and smoothly/performably. https://github.com/WorldMaker/lcars-moderne/issues/1 https://github.com/WorldMaker/lcars-moderne/issues/1
    • spcebar 5y ago
      Just a thought: ``document.getElementById("co").onmousewheel = function(ev) { this.scrollLeft += ev.deltaY; }``
      • WorldMaker 5y ago
        Thanks. I might try that. I seem to recall not liking solutions that easy for some reason, part of that was trying not to interfere with the native CSS behavior in "Edge Classic", though I suppose with "Edge Classic" that's definitely no longer a concern and I hadn't thought to revisit easy solutions I suppose.
• itronitron 5y ago
  It's interesting that articles about the features of JS frameworks and their provenance are an easier read than articles about how to actually use those frameworks.
• dividedbyzero 5y ago
  I wish it was easier to use no framework at all, no angular, vue, react ... but still benefit from npm/yarn package management, development server with hot reload and maybe even a test runner. As someone who only occasionally needs to build relatively simple frontends against existing APIs, using full-blown angular/react/vue just seems so wasteful. But the last time I tried to put such a setup together, I just couldn't make all the parts (yarn, webpack, jest, ...) work together, and lots of the various plain JS "starter" projects out there are broken as well. It's pretty bewildering – shouldn't this sort of thing be easy? Is there some kind of a vue-cli for frameworkless projects, or how do people get started building more lightweight web apps?
  • toastercat 5y ago
    It sounds like you were trying to use a bunch of tools without understanding what the tools actually do. That said, webpack and jest are bloated messes and easy to break. I'd say just stick to esbuild as your lone dev dependency and get to work writing your framework-less project. Otherwise, take a look at the vanilla Vite template: https://vitejs.dev/guide/#scaffolding-your-first-vite-project https://vitejs.dev/guide/#scaffolding-your-first-vite-projec... If you find that you want a framework (which may be inevitable), give Mithril.js a shot. It's very unopinionated. These days I tend to only use esbuild. For testing, I use my own homerolled test utility and the built-in Node.js assert module, or uvu.
    • dividedbyzero 5y ago
      > It sounds like you were trying to use a bunch of tools without understanding what the tools actually do. That's true, so far I've only interacted with these tools in vue-cli-generated projects and the like. I'm not sure if "framework-less" is the right term even. I'd like to be able whip up quick UIs with a few libraries where needed without too much unnecessary complexity. I find there's little benefit in forcing simple UIs into Vue components, but juggling libraries without npm/yarn is cumbersome, too. I'll have a look at Vite and Mithril.js, thanks for the pointers!
  • crooked-v 5y ago
• aliswe 5y ago
  OK, gave this another try. it seems you fixed the font. please improve contrast a bit (brighter text color) and then PLEASE remove the text-align: justify. it just looks horrible with extreme gaps in it when using mobile.
  • MBCook 5y ago
    Reader mode fixes the issues quite well.
• ilteris 5y ago
  Haha why is this ego driven nonsense article top post on hn?
• bern4444 5y ago
  I don't like frameworks for web when they start creating their own syntaxes. As soon as I see something like ngIf or svelte's {#if x > 10} <p>{x} is greater than 10</p> {:else} or even Vue's v-if or v-for I start looking elsewhere. This is why I like React the best. It doesn't get in the way when I need javascript as it exists and it doesn't reinvent these mechanisms and primitives that are already completely sufficient. The React primitives, especially today, are so easy to work with. Components in JSX can be treated like an object. They are functions that have a return value. They use hooks which are also just functions that return values. Both can be combined, composed, and manipulated with one another using the JS everyone knows (and I at least love). Frameworks should be built up to preserve the structure that the language provide. React does this the best. It's not a framework like Angular but it's not meant to be. That's why we've also created frameworks like NextJS, and soon Remix (remix.run), and other solutions. Even when using {} in react, the thing in the curly braces is JS. I'm not using a framework's invented conditional implementation, I'm using JS's conditional expression. I have access to the language and don't need to learn the framework's equivalent which is usually more verbose and less direct.
  • dimmke 5y ago
    This is a great articulation of what I was thinking when reading him talk about Angular's templating language. JSX feels "honest" - like an authentic extension of JavaScript. Yes there are a few quirky rules but I hated the custom angular attributes etc... I've only had to do a little Angular development in my life but something I remember was how hard it was to get answers on basic stuff. Like I would have a problem that I'm sure was trivial and people run into all the time and I couldn't Google and get a result that wasn't full of really dense Angular concepts and keywords. It's a hard framework to just kind of nose your way into if you need to update something. It's like it wants you to read all the documentation and learn all the fancy words it has for stuff.
    • toastercat 5y ago
      Even better than JSX is straight up hyperscript or something like @hyperapp/html[1]. JSX feels like a cumbersome attachment in comparison. [1] https://github.com/jorgebucaran/hyperapp/tree/main/packages/html https://github.com/jorgebucaran/hyperapp/tree/main/packages/...
• adrianvoica 5y ago
  angular, react, vue, svelte, lit, oh boy, so much bloat. how about getting a hold of your sanity and allowing yourself a few hours to learn https://riot.js.org/ https://riot.js.org/ - almost no learning curve, only pure awesomeness. even if you won't use it in the enterprise (because policies, bla bla), it is still worth knowing things can be done differently - in a good way. good things come in small packages.
• seastonATccs 5y ago
  I do.
• nickkell 5y ago
  It’s a good point about rxjs. I’m a massive fan of rx, but the learning curve is steep and I had the feeling none of my colleagues knew how to use it properly. Having multiple ways of returning (imperatively and declaratively) values from components leads to a mess
• unethical_ban 5y ago
  I'm not a web developer (beyond a hobbyist 5, then 15 years ago). If angular is so bad, why does every Udemy course and web course want to teach me MEAN stack? Honest question, because I'm gonna a look into some web dev courses this weekend and commit to it.
  • lstamour 5y ago
    It’s a catchy acronym. For alternatives, check out egghead.io, designcode.io or https://beta.reactjs.org/ https://beta.reactjs.org/ depending on the content you’re looking for… I’ve never been able to pick just one framework and use it to the exclusion of all else. Even when I was writing Rails apps back in the day, I had to use Scriptaculous or jQuery in addition to Rails and friends. And often write custom Ruby gems and libraries all over the place. Something like React Native seems cross-platform and friendly until you need one simple API and then you’re writing async wrapper functions that have to talk to the main thread in both Android, iOS and wrapper JS. Abstractions and tech stacks always work well but never in isolation. You gotta write the code somewhere. I’m a big believer in owning your dependencies and treating code you ship - but didn’t write - as your own code. E.g. framework code.
• ldehaan 5y ago
  I wouldn't recommend angular to someone who jives with react, just like I wouldn't recommend ror to a Drupal dev. It's different ways of thinking.
• Tade0 5y ago
  My one, big complaint about Angular is the sheer amount of badly documented knowledge you have to accumulate to become an expert in it, so few people really are - the article even touched on that. Better yet - even those who mastered it still discover new things from time to time. In my previous project I've met a very knowledgeable developer who taught me, among other things, that components can also provide services (of course they can!) but shied away from RxJS stuff, which in turn was something that I could teach him. We both struggled with circular dependencies in Jest tests and never solved that one, because at the time the designers of the mentioned testing framework refused to tell how exactly was workload parallelized, so debugging was difficult to say the least.
  • rezonant 5y ago
    Here is the documentation: https://angular.io/api/core/Directive#providers https://angular.io/api/core/Directive#providers I discovered this around Angular 2.0.0 by exploring using Typescript's autocompletion. It can be very useful!