Why does anyone use Angular in production?(blog.worldmaker.net)

80 pointsby WorldMaker5 anni fa145 comments

blog.worldmaker.net

Why does anyone use Angular in production?

http://blog.worldmaker.net/2021/06/26/angular/

147 comments

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.

WorldMaker5 anni fa

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).

ebruchez5 anni fa

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.

WorldMaker5 anni fa

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.)

toomanydoubts5 anni fa

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.

WorldMaker5 anni fa

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.

toomanydoubts5 anni fa

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.

WorldMaker5 anni fa

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.

shadowgovt5 anni fa

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.

WorldMaker5 anni fa

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.

shadowgovt5 anni fa

My mistake... I had my phone set to "Request desktop sites by default" and forgot!

No complaints from here about the mobile UX.

cheeze5 anni fa

> 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.

WorldMaker5 anni fa

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.

SahAssar5 anni fa

> 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.

Alex39175 anni fa

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.

LarrySellers5 anni fa

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.

WorldMaker5 anni fa

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

halfeatenpie5 anni fa

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!

WorldMaker5 anni fa

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.

tarboreus5 anni fa

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

[deleted]5 anni fa

dentemple5 anni fa

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.

kevin_thibedeau5 anni fa

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.

nimih5 anni fa

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.

itronitron5 anni fa

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?

WorldMaker5 anni fa

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

nimih5 anni fa

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.

riidom5 anni fa

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!" :)

WorldMaker5 anni fa

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

earthboundkid5 anni fa

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.

WorldMaker5 anni fa

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.)

spcebar5 anni fa

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.

jonny_eh5 anni fa

or… I dunno… vertical scrolling like literally every other web page?

tedmiston5 anni fa

To save some awkward scrolling: https://outline.com/mhWdLS.

charles_f5 anni fa

Also ironic, the justified text alignment, huge font and large padding which leaves room for 3 unreadable words per line on mobile.

hodgesrm5 anni fa

Thanks, I would have missed that completely without your comment.

YetAnotherNick5 anni fa

Missed chance to use "In case someone doesn't know it, ..."

bern44445 anni fa

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.

dimmke5 anni fa

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.

toastercat5 anni fa

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/...

thatswrong05 anni fa

That's an interesting opinion. JSX feels far more natural to me.

toastercat5 anni fa

JSX also initially felt more natural to me aesthetically since it looks like HTML. But that's where those feelings end; JSX is not valid JavaScript, it doesn't extend the language in any meaningful way, it superficially resembles HTML which we all were already familiar with. Hyperscript or HTML helper functions are not only less typing, but indent more naturally and can live in regular .js files without need for transpilation or IDE plugins.

WorldMaker5 anni fa

> JSX is not valid JavaScript, it doesn't extend the language in any meaningful way

It's semi-directly related to (subset of a) JavaScript standard which it evolves some of the more useful syntax for some modern needs. It's just not an "active" standard currently targeted by browsers today (in part because it need evolution): ECMA-357 aka E4X aka ECMAScript for XML. [1]

There's currently no interest in adding browser support for JSX (either from the JSX spec itself or any browser makers), just as E4X support waned very quickly when Firefox was the only browser interested in supporting it, but that doesn't mean it is impossible to see browser support at all in the future. It was standardized once, it might be standardized again now that we have a better idea of what it might be used for in the wild. (I don't think it will be, mostly because there's an ecosystem of interesting non-React usages of JSX that would be hampered a bit if it wasn't just a transpiler step.)

[1] https://en.wikipedia.org/wiki/ECMAScript_for_XML

bern44445 anni fa

JSX allows for dynamically generating HTML elements that have access to values from JS without any work in binding the two together.

That's pretty convenient.

JSX is valid JS. It is converted down to the same thing as what you describe, function calls to React.createElement(). Which can also be used instead and aliased to a function if you prefer.

Using "HTML" like syntax in JSX then let's React not have to invent it's own base components and let's you think about the "HTML" as HMTL.

You could even alias all the elements to function names

    const h1 = (...) => {
        React.createElement({...}) 
    }

and then call those functions like so

    h1(...)

across your components instead of <h1> ... </h1>.

    const MyComponent = () => {
        return (
            div(
                h1(...)
                h2(...)
                p(...)
                items.map(item => li(item))
            )
        ) 
    }

A "component" is just a JS Object that you can manipulate and pass through wherever you want like anything else.

toastercat5 anni fa

> JSX is valid JS. It is converted down to the same thing as what you describe, function calls to React.createElement().

This is disingenuous. Browsers do not understand JSX, nor do most JavaScript engines. TypeScript also gets transpiled to JavaScript -- it is not valid JavaScript in and of itself, you require a build step. We can argue semantics, but I think it's pretty clear what I meant.

> You could even alias all the elements to function names

You've just recreated what I mentioned two comments above in this same comments thread. :) See: https://github.com/jorgebucaran/hyperapp/tree/main/packages/...

This is what I'm arguing for over something like JSX.

bern44445 anni fa

I understand, and the browsers don't understand JSX is a fair point.

I'm only illustrating that the difference between JSX and JS for React is about syntax and not the core distinction of why React feels easier to work with compared to angular/vue/svelte etc which all invent their own mini languages. JSX feels much more natural since it allows for the same JS everyone (hopefully) loves.

Something like hyperapp/hyperscript can absolutely be used in place of JSX, but the HTML likeness that JSX enables feels more natural to me - and I think most - vs a bunch of h1(), h2() etc function calls. In the end, though, this is a trivial difference.

A component expressed in JSX is really just a JS function call that ends up as a document.createElement() invocation.

Epskampie5 anni fa

You think

‘const [count, setCount] = useState()’

is normal javascript? It runs completely counter to the way functions and variables normally work, using some global store behind your back.

The idea that react is “just javascript” has gone out the window with hooks.

yladiz5 anni fa

The code you just put is vanilla JS, so yes it's normal, it doesn't require any compilation step to work. If you made a React component that returns something that didn't require a compilation step, like Hyperscript, then it too would be normal Javascript. You can argue that having a function perform a side effect in this way isn't a good design decision but it is supported in the language and "normal".

WorldMaker5 anni fa

All of that is vanilla JS as of ES2015. The destructuring assignment is new enough that it maybe doesn't feel that normal to you depending on your current projects, but it's not really that unnormal:

const [x, y] = [0, 0] // point destructuring

If you really wanted to, you could always feel more at home by doing it the old pre-ES2015 way:

var countState = useState()

var count = countState[0]

var setCount = countState[1]

That's the same code. It's not even that different from how JS functions have always worked.

const [x, y] = getPoint()

No one would accuse a function named "getPoint()" of using a global store "behind their back", they assume it is "getting" the "point" from somewhere, certainly, but wouldn't necessarily know where (or care where in most cases if you are just using someone else's library or component). It could be using a window.point global, it could be making an XHR/fetch request to an API somewhere, it could be creating random points, it could be trying `this.point` and depending on any nearby Object.bind() or Object.apply() that `this` could be nearly any object (including window, but not necessarily). (JS's objects have always been that weird. That's JS's normal.) There are so many options and that's the nature of function calls you have no idea without seeing its implementation.

The useState implementation is particularly a black box in React, but it's no more a "black box" than the the average "normal" function.

Also all the spooky "Rules" about using hooks (maintaining their order, making sure they are never used in branches, etc) exist because it is not just using a global store! It is essentially using a curiously bound `this`, which again is very normal JS OOP going way back to the beginning of the language. It doesn't look like a normal object and React's developers don't want to call hooks "objects" to avoid confusion and because they are easier to program if you don't call them "normal weird JS objects" and use some fancier functional programming abstractions, but they very much are "normal weird JS objects". You don't see the weird Object.bind (equivalents) because the framework is taking care of those for you, but it's not the first (and it will not be the last) JS framework to give developers a black box API that looks confusing from the outside and asks you to trust it is doing the right thing inside.

toastercat5 anni fa

> Frameworks should be built up to preserve the structure that the language provide. > React does this the best.

Considering idiomatic React basically necessitates JSX, no, React does not do it the best. Frameworks that embrace things like hyperscript and regular .js files over unnecessary aesthetics and goofy file extensions like .jsx do this better than React (Preact, Mithril, Hyperapp). Even hooks are weird and magical to JS veterans -- most people hopping into React are essentially told "just accept this, it works, and you don't have to understand how".

bern44445 anni fa

I've never really understood the hooks are complicated line.

Maybe it's the understanding that they integrate with React's event system (which I think is powered by something like rxjs/observables), but hooks make the most sense once you start implementing custom hooks which are incredibly easy to write and reuse.

Need a hook for undoable (and re-doable) state? It can be implemented in ~30 lines and then used anywhere in your application.

Need a hook to manage data from an API across your application, a custom hook makes this trivial especially if you need to connect it with your global state management (like redux/context/etc).

JSX is nothing special and it's possible (and trivial) to set up your component files to use a .js extension.

The only thing JSX does is let you write components with an HTML like syntax instead of with a bunch of function calls. I find this extremely ergonomic.

Bad React is when the two ideas - view and component logic - are mixed too much. That's the point at which components need to be broken down further to avoid bloat or a custom hook is needed to handle data.

toastercat5 anni fa

I feel like you're speaking completely past me, because I never said using hooks were complicated. On the surface, they simplify quite a whole lot to the point where complete beginners to JavaScript can grasp them and be productive quickly.

franklyt5 anni fa

I used to think this, but sveltes templating language is trivial and keeps the problem space manageable for its maintainers.

bern44445 anni fa

It does work well for smaller focused applications. As soon as you need an escape hatch though to do something it doesn't have an expression for, and you will always find a situation where you do, you run into the barrier between the framework and the native language which becomes clunky and odd.

You end up having to extend the framework in potentially weird ways to get your thing to work.

It's much nicer when your framework just uses the underlying system instead.

midrus5 anni fa

Looking just at the "syntax" to discard or like something is very naive in my opinion.

Thinks such as the performance, the reactivity model, the "gotchas", the ecosystem, the libraries, the tooling, etc are far, far, far more important than "I like IFs done this way".

This is the same thing as when people discard Tailwind because "I don't like reading that many classes". There's so much more behind it to like or dislike it.

crooked-v5 anni fa

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.

gkoberger5 anni fa

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.

md8z5 anni fa

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.

turtlebits5 anni fa

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.

brundolf5 anni fa

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.

simon045 anni fa

> 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.

hasperdi5 anni fa

I wouldn't say they're incompatible rewrite. They are two different products.

gkoberger5 anni fa

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.)

WorldMaker5 anni fa

In this case the phrase "to the Core" is much more directly aimed at from Angular's core outward in that Angular literally has a key library named `@angular/core` and that my technical complaints originate there and I do try to draw the line from those decisions made in `@angular/core` and the ripple effect they have on other major libraries and the ecosystem as whole.

That the phrase "to the Core" serves as double entendre here questioning their intent/philosophy behind the existence of the framework was certainly intended to be clickbait, but I thought it clickbait that HN would appreciate because it is technically correct (and as we all know that is the best kind of correct). I appreciate that it was not well received by some and I may have been too clever with it.

miiiiiike5 anni fa

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.

WorldMaker5 anni fa

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.

Epenthesis5 anni fa

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.

brundolf5 anni fa

I think the separation is along the typical enterprise/non-enterprise split

ldehaan5 anni fa

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.

akmittal5 anni fa

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

smnrchrds5 anni fa

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.

laurent925 anni fa

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).

kemiller20025 anni fa

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"

akmittal5 anni fa

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.

brundolf5 anni fa

> 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.

tluyben25 anni fa

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.

ramoz5 anni fa

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).

josteink5 anni fa

> 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.

ldehaan5 anni fa

You'll get there eventually but a quick level up: it's only that way because you don't know how it works at it's base level and nobody will be able to fix it until they do. You have to spend the time digging in and if you don't then don't be surprised if it doesn't work, that's going to be every system you work on though. Not everyone has the time to put in when a new better framework comes out every 6 months. So I use old shit :D it still works and it's still fast and I know it backwards and forwards. Html and Javascript with a backend that generates all the shit so I don't need to make backend calls add socket io for loading stuff after the page is loaded. No framework except the server side, and that depends on the language. If you want to get really frustrated but level up super fast on multiple languages and frameworks? Install JHipster, and then change something. It's amazing how easy it is to break and what a giant pita it is to fix, but i do it all the time because you really gotta get in there and poke and prod until you figure out the problem.

rezonant5 anni fa

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.

ben9408302984325 anni fa

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.

laurent925 anni fa

Plus the “any exception makes the screen entirely blank”.

franklyt5 anni fa

>weird hierarchical "junior/senior" dichotomy

Will this ever end?

TheChaplain5 anni fa

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.

ldehaan5 anni fa

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.

FloayYerBoat5 anni fa

Can you trust the opinion of anyone using that design / layout?

Apocryphon5 anni fa

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.

nickkell5 anni fa

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

AbraKdabra5 anni fa

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.

moate5 anni fa

Shocking that the author is a self described "backend guy" with UI like that...

bythreads5 anni fa

Seriously zone.js is enough to just walk away

josteink5 anni fa

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.

rezonant5 anni fa

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.

Tade05 anni fa

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.

rezonant5 anni fa

Here is the documentation: 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!

aliswe5 anni fa

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

dividedbyzero5 anni fa

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?

Gigachad5 anni fa

“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_5 anni fa

> 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?

Gigachad5 anni fa

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.

dividedbyzero5 anni fa

One thing I really like about the current web is that I can still inspect and dissect almost everything with just the developer tools. I couldn't do that with WASM blobs, which of course the ad industry would absolutely love since then they can just obfuscate their binary blobs and hide anything in there, legal or not, malware or not, and it's no longer feasible to rip it out.

dividedbyzero5 anni fa

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.

toastercat5 anni fa

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.

dividedbyzero5 anni fa

> 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!

WorldMaker5 anni fa

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.)

lioeters5 anni fa

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.

toastercat5 anni fa

The creators of Preact more recently introduced WMR: https://github.com/preactjs/wmr

+1 for esbuild and Vite. Personally, I think esbuild alone is enough for most usecases.

bern44445 anni fa

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.

dividedbyzero5 anni fa

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.

bern44445 anni fa

Gotcha. I bet you could throw a script together that would use the package.json to auto generate script tags to inject in an HTML file.

It's not ideal but I don't think it'd be too hard. This would require though a build step which is what you seem to want to avoid.

crooked-v5 anni fa

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.

dividedbyzero5 anni fa

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.

ilteris5 anni fa

Haha why is this ego driven nonsense article top post on hn?

cphoover5 anni fa

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.

alfu5 anni fa

https://github.com/WorldMaker/blog.worldmaker.net/blob/gh-pa...

MBCook5 anni fa

Just use reader mode.

rdevnull5 anni fa

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/ )

WorldMaker5 anni fa

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.)

ldehaan5 anni fa

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

rdevnull5 anni fa

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 :)

Blackthorn5 anni fa

> 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.

unethical_ban5 anni fa

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.

lstamour5 anni fa

It’s a catchy acronym. For alternatives, check out egghead.io, designcode.io or 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.

aliswe5 anni fa

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.

MBCook5 anni fa

Reader mode fixes the issues quite well.

itronitron5 anni fa

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.

ldehaan5 anni fa

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.

marcellus235 anni fa

it seems the author is trying to recreate the LCARS GUI from Star Trek. Not sure why the horizontal scrolling though.

vanillax5 anni fa

This article absolutely blows. How is this front page material?

nick_5 anni fa

HN front page is regularly 95% hot takes disguised as technical blog posts, or pretentious/esoteric JS/Rust libraries.

aliswe5 anni fa

If anything, I would call this a technical blog post disguised as a hot take.

cheeze5 anni fa

HN often reminds me of that article about how a majority of what you read on the internet is written by insane people.

arenaninja5 anni fa

The headline must resonate with enough visitors

johncena335 anni fa

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.

ldehaan5 anni fa

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.

thayne5 anni fa

The horizontal scroll would be a lot less annoying if you could use your scroll wheel to scroll through it.

WorldMaker5 anni fa

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

spcebar5 anni fa

Just a thought: ``document.getElementById("co").onmousewheel = function(ev) { this.scrollLeft += ev.deltaY; }``

WorldMaker5 anni fa

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.

whalesalad5 anni fa

The pot calling the kettle black, no?

DeathArrow5 anni fa

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!

brynjolf5 anni fa

That is a lot of quotation marks for one post, why is everything so loaded

adrianvoica5 anni fa

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.

bythreads5 anni fa

...zone.js...

seastonATccs5 anni fa

I do.

emerged5 anni fa

I’m genuinely impressed at how bad this site design is.

[deleted]5 anni fa