[HN Gopher] Why does anyone use Angular in production?
___________________________________________________________________
Why does anyone use Angular in production?
Author : WorldMaker
Score : 62 points
Date : 2021-11-04 18:15 UTC (4 hours ago)
(HTM) web link (blog.worldmaker.net)
(TXT) w3m dump (blog.worldmaker.net)
| nickkell wrote:
| 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
| rdevnull wrote:
| 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/ )
| WorldMaker wrote:
| 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
|
| 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 wrote:
| 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 :)
| itronitron wrote:
| 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.
| [deleted]
| bythreads wrote:
| ...zone.js...
| bythreads wrote:
| Seriously zone.js is enough to just walk away
| josteink wrote:
| 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.
| Zealotux wrote:
| 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.
| YetAnotherNick wrote:
| Missed chance to use "In case someone doesn't know it, ..."
| hodgesrm wrote:
| Thanks, I would have missed that completely without your
| comment.
| charles_f wrote:
| Also ironic, the justified text alignment, huge font and large
| padding which leaves room for 3 unreadable words per line on
| mobile.
| WorldMaker wrote:
| 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).
| SahAssar wrote:
| > I strongly believe weird aesthetic choices are what makes
| blogs personal and not just another walled garden like most
| of social media (or Medium).
|
| Sure, but in this case the choice also strongly sacrifices
| usability. Even on non-MacOS desktop firefox I didn't know
| there was more to the article before reading the parent
| comment.
|
| If you want people to read more of the article then perhaps
| make it easier to find out that there is more of it.
| halfeatenpie wrote:
| I see your point and that's up to you. But I do think
| factoring in the end user's experience is important here if
| you want them to listen to your argument.
|
| You're trying to sell someone that your idea is right, but
| having the desktop experience be a bit difficult (and putting
| it on the end user to deal with it) doesn't really help you
| in communicating your points. It also makes it harder for
| them to digest your content, therefore people might just skip
| over it.
|
| But again, it's a personal blog so all these decisions are up
| to you and your liking!
| WorldMaker wrote:
| I appreciate that and tried to compensate for some of the
| trade-offs with the CSS available at the time. CSS that the
| browsers seem intent on not supporting and maybe dropping.
| I do find upsetting that I end up having to apologize a lot
| for trying to do some things that I thought were
| fun/unique/unusual/personal touches and the browsers just
| getting worse about it with passing years rather than
| better.
|
| It is interesting how many of these comments have fallen
| into style of substance fallacy over the contents of the
| arguments themselves, and I am listening to all of this
| feedback. This current CSS was designed to make 90s kid me
| happy, primarily on "Edge Classic". It's not aged as well
| as I would have liked, and I don't know if/when I'll
| revisit it, but I am listening.
| tarboreus wrote:
| You know what? Keep it. It's weird but I think that makes
| it cool.
|
| Don't get demoralized. Everyone is boring today. If this
| was a business or something I'd say ditch it and make
| your website have Bootstrap or whatever least common
| denominator thing. It's not, it's your place to express
| yourself, so don't let wet blankets ruin your site for
| you.
|
| Here's two other weird sites just to keep up your morale.
|
| https://slimedaughter.com/
|
| http://art.teleportacia.org/olia.html
| dentemple wrote:
| The first section just needs a little note that the user
| needs to scroll horizontally to continue.
|
| Certain browsers make it completely non-obvious that you have
| to do so to see more content, and it's no longer "intuitive"
| UX for most users.
| LarrySellers wrote:
| Unfortunately it makes them inaccessible in this case, I
| wouldn't even know how to scroll sideways unless you actually
| expect a user to click and drag a scrollbar. Even if the site
| was usable the the text is still illegible.
| WorldMaker wrote:
| Yeah, I wish I had scroll wheel support again. The CSS for
| that was never standardized and the browsers that supported
| it no longer exist and most of the JS-based solutions are a
| bit more lacking than I would prefer.
|
| I've been tracking it for a while:
| https://github.com/WorldMaker/lcars-moderne/issues/1
| ebruchez wrote:
| 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 wrote:
| 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 wrote:
| 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.
| WorldMaker wrote:
| I stated several comments up directly in this chain that
| a confusing UX on my personal blog was a deliberate
| decision. I stand by that.
|
| I also point out that I _tried_ to add affordances to
| make it easier to use and was stymied by bad browser
| support _getting worse_. I haven 't updated this CSS in a
| while, because I haven't felt like I needed to, but the
| way the browsers display it in 2021 is actively worse
| than when I wrote it and I'm sorry about that.
|
| I can also _at the same time_ believe that Apple removing
| scrollbars altogether and not replacing them with some
| sort of affordance is also a UX crime, whether or not my
| own decisions that make are worsened because of it were
| deliberate.
| toomanydoubts wrote:
| Well, it's good to see that you accept its your own
| decision, given the circumstances, that made it what it
| is.
|
| If you're set on that, maybe you could try adding a
| really unmistakable indicator such as a "Scroll right for
| more ->" text. I'm not sure if that's good as I'm not a
| UX/UI designer, but probably better than nothing. Still,
| as a user, a would prefer something that I'm used to,
| such as top-down text.
| WorldMaker wrote:
| When I wrote this CSS the columns themselves were
| supposed to do that and supposed to "peek" across the
| edges. Browsers decided to take a different, worse layout
| approach to multi-column and broke my intended CSS
| affordances. There wasn't intended to be "nothing". Just
| time and tech debt.
| cheeze wrote:
| > I wish Apple would provide at least something of a
| better user experience here
|
| But they don't, so its generally our job to work around
| that and provide sane usability in light of decisions
| made by larger browsers.
|
| Still doesn't make horizontal scrolling discoverable or a
| pleasant UX.
| WorldMaker wrote:
| I _had_ affordances. Browsers dropped support for them. I
| 'm taking all this feedback in for whenever I have time
| to next update my personal blog CSS.
| shadowgovt wrote:
| Multi-column plays poorly with mobile user agent UX,
| because the swipe motion made (often with just a thumb)
| is inaccurate. Works alright if you can reduce it to just
| the y-axis, but you ask a lot of your end-user on a
| mobile UA to scroll horizontally also. Flipbook or
| vertical scroll are the two metaphors that work here.
|
| That having been said, you should be able to tune your
| stylesheets to vend one that gets users single-column
| text on mobile devices with some elbow grease. Up to you
| whether it's worth it.
| WorldMaker wrote:
| That's absolutely what this CSS already does and why a
| suggestion above is to shrink the browser tab width to a
| "mobile" media breakpoint for vertical scrolling if that
| is preferred even on wider screens.
| shadowgovt wrote:
| My mistake... I had my phone set to "Request desktop
| sites by default" and forgot!
|
| No complaints from here about the mobile UX.
| kevin_thibedeau wrote:
| The 90's web was broken with bad assumptions about the
| viewport for what was supposed to be a flexible layout
| engine. This is no different that hardcoding for 640x480 and
| making everyone else suffer.
| Alex3917 wrote:
| I'd agree with you if hitting the spacebar or the arrow keys
| made it scroll over a full page. But honestly this is pretty
| ridiculous.
| earthboundkid wrote:
| 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 wrote:
| or... I dunno... vertical scrolling like literally every
| other web page?
| WorldMaker wrote:
| 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 wrote:
| 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.
| riidom wrote:
| 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 wrote:
| 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
| nimih wrote:
| 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 wrote:
| 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 wrote:
| 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
| dividedbyzero wrote:
| 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?
| Gigachad wrote:
| "Feeling wasteful" is not a logical evaluation of the
| technology. Does it feel wasteful when you used an incredibly
| powerful computer capable of almost anything to post a text
| comment to a website in the same way you could have 20 years
| ago?
|
| VueJS is very lightweight and loads almost instantly. It runs
| on even very old computers well. Native JS will never be able
| to compete with frameworks because frameworks have the ability
| to rapidly innovate and try new things without worrying about
| having to keep them around forever.
|
| IMO the browser should become something like a CPU where it
| provides the low level components to do anything and the
| website provides the framework to make it easy.
|
| It doesn't "feel wasteful" to use C or Python to print hello
| world when it could have been done in raw ASM.
| oikawa_tooru_ wrote:
| > IMO the browser should become something like a CPU where it
| provides the low level components to do anything and the
| website provides the framework to make it easy>
|
| Maybe webassembly is the thing that you are looking for?
| Gigachad wrote:
| WASM is where I think the web should be heading. It's been
| shown time and time again that designing good high level
| interfaces is very hard and there will always be a better
| design out later. Platforms like web browsers are not able
| to innovate like libraries can.
|
| JS has multiple implementations for date interfaces and
| they are all flawed in ways. Rust decided that date
| handling should be the job of 3rd party libraries which
| have the freedom to drop bad ideas and break compatibility
| for the goal of a constantly improving implementation.
| dividedbyzero wrote:
| They feel wasteful because what I'm doing really is pretty
| simple in most cases. I can easily build that in plain
| JavaScript and it feels wasteful to pull in all those layers
| of abstraction and write Vue components where plain JS ends
| up being shorter and easier to reason about.
| bern4444 wrote:
| Why can't you use npm modules via a CDN like
| https://unpkg.com/? Add a JS file that downloads whatever
| package you need and then use them in that JS file? Have your
| HTML page load that file via a script tag (you can also have
| the HTML file load the packages in a script tag) and then
| you're off to the races.
| dividedbyzero wrote:
| That's what I did before npm came around, but proper package
| management, hot reload, test runners etc. are creature
| comforts I'd hate to do without these days. Keeping
| dependencies up to date when getting them from a CDN is
| pretty cumbersome.
| lioeters wrote:
| Maybe something like Preact CLI? It's not "no framework", but
| seems pretty close.
|
| > In just 4.5kb you get a productive environment with preact
| and preact-router
|
| https://github.com/preactjs/preact-cli
|
| Edit: On second look, it uses Webpack and Babel, and these days
| newer tools like ESBuild and Vite are faster and probably
| lighter.
| keb_ wrote:
| 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-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 wrote:
| > 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 wrote:
| I think what you're missing here is that as soon as you start
| answering the questions necessary to get those tools to work
| together right (for example: how do you split files? how does
| your routing work? how does injecting replacement code for hot
| reload work?), you end up with a framework.
| dividedbyzero wrote:
| Of course any plain JS app I'd write would end up being a
| kind of nano-framework; for me, the difference is in the
| unnecessary complexity this approach would avoid. Vue, React
| etc. bring a lot to the table; sometimes I'd rather just
| write that tiny, less-than-ideal nano-framework because it's
| good enough and pulling in tons of dependencies feels
| unnecessary and might actually increase my app's attack
| surface. I'd like to keep the creature comforts of npm/yarn
| etc. though.
| WorldMaker wrote:
| I've had some success with npm, snowpack, mocha, typescript as
| that sort of stack for more "vanilla" efforts that feel rather
| more "modern". I think mocha is easier and cleaner than jest. I
| like keeping all of my transpilation to just Typescript without
| needing a massive Babel install/pipeline. snowpack
| (https://www.snowpack.dev/) right now I think is in a sweet
| spot of a better "ES Module native" developer experience than
| webpack and has better defaults when left unconfigured. (So
| much so that while there are snowpack templates/generators
| provided by the project I mostly don't use them other than for
| reference.)
| emerged wrote:
| I'm genuinely impressed at how bad this site design is.
| gkoberger wrote:
| 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.
| gkoberger wrote:
| ADDENDUM: The original title on HN was "Angular is Rotten to
| the Core". My defense was about the "core" aspect... since the
| core was, in my opinion, a noble attempt at making the web a
| better place.
|
| (Additionally, I feel like if you're going to criticize Angular
| for being by Google, you can't really be recommending React.
| Also, not the point, but I think the "No One Got Fired For
| Picking Google" subheader is a weird take on the original IBM
| version of the quote.)
| simon04 wrote:
| > 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.
| md8z wrote:
| 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.
| turtlebits wrote:
| 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 wrote:
| 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.
| seastonATccs wrote:
| I do.
| akmittal wrote:
| 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
| tluyben2 wrote:
| 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 wrote:
| 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.
| laurent92 wrote:
| In 2020 I searched for employees and 90% were Angular, 10%
| React. Now it is the 30-70 (because the skills market is
| delayed compared to things people are currently learning).
| kemiller2002 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| cphoover wrote:
| 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/). 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.
| alfu wrote:
| https://github.com/WorldMaker/blog.worldmaker.net/blob/gh-pa...
| FloayYerBoat wrote:
| Can you trust the opinion of anyone using that design / layout?
| Apocryphon wrote:
| Looks like the site has been around since 1998 (includes link
| to original iteration)
|
| http://worldmaker.net
|
| Using the LCARS style gets geek points for retro sci-fi, but
| dang that font color is unreadable.
| DeathArrow wrote:
| 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!
| Epenthesis wrote:
| 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 wrote:
| I think the separation is along the typical enterprise/non-
| enterprise split
| Blackthorn wrote:
| > 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.
| bern4444 wrote:
| 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.
| vanillax wrote:
| This article absolutely blows. How is this front page material?
| nick_ wrote:
| HN front page is regularly 95% hot takes disguised as technical
| blog posts, or pretentious/esoteric JS/Rust libraries.
| cheeze wrote:
| HN often reminds me of that article about how a majority of
| what you read on the internet is written by insane people.
| arenaninja wrote:
| The headline must resonate with enough visitors
| johncena33 wrote:
| 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.
| aliswe wrote:
| 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.
| adrianvoica wrote:
| 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/ - 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.
| marcellus23 wrote:
| it seems the author is trying to recreate the LCARS GUI from Star
| Trek. Not sure why the horizontal scrolling though.
| ramoz wrote:
| 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).
| josteink wrote:
| > 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.
| ben940830298432 wrote:
| 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 wrote:
| Plus the "any exception makes the screen entirely blank".
| miiiiiike wrote:
| 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 wrote:
| 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.
| aliswe wrote:
| 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
| ilteris wrote:
| Haha why is this ego driven nonsense article top post on hn?
| crooked-v wrote:
| 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 wrote:
| The pot calling the kettle black, no?
| TheChaplain wrote:
| 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.
| AbraKdabra wrote:
| 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 wrote:
| Shocking that the author is a self described "backend guy" with
| UI like that...
| thayne wrote:
| The horizontal scroll would be a lot less annoying if you could
| use your scroll wheel to scroll through it.
| WorldMaker wrote:
| 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
| spcebar wrote:
| Just a thought: ``document.getElementById("co").onmousewheel
| = function(ev) { this.scrollLeft += ev.deltaY; }``
| WorldMaker wrote:
| 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.
___________________________________________________________________
(page generated 2021-11-04 23:02 UTC)