Hacker News Reader

Comment by GiorgioG | Hacker News Reader

I disagree. I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse. I had a chance to do some side work and decided against building a SPA. I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order. If I need some more complex interactivity then I might sprinkle in something lightweight but I expect that to be the exception not the rule.

Death to complexity on the frontend for complexity's sake.

View on HN

Re "complexity", for reference: the dependency tree (as in yarn list) of production-only installation of a default angularJS app created with ng new --minimal app is...

(I wanted to paste it, but it's too long = 2500 lines)

I think this is a separate problem. The JS ecosystem's love of dependencies is not about complexity, but about "not re-inventing the wheel" - everyone has been trained that for any problem there is a library to solve it, and writing code to solve the problem yourself is a waste of time.

This attitude is already hurting everyone, and it's only going to get worse. But it's a different thing than the complexity problem.

For me it's the definition of complexity. Something that has many parts is complex.

If I want to dig into "how my angular app works", I can't, because I cannot browse 2500 npm packages on github to find out what they are doing. Even answering the question "does my app actually require this dependency" is completely impractical.

To be fair, I had this problem learning Rails too. I like knowing how and why something works, and so the "it just does this because that's the convention for Rails" was confusing and annoying rather than helpful, and trying to dig into the Rails code base to work out why was pointless.

Part of the reason I love Go is because there's no magic. I can look at the definition of a std lib function and it's right there, in plain code, and makes sense.

But despite Go being simpler than Rails (for this reason), I'm not sure that any given Go project is simpler than any given Rails project. The moving parts are more obscure, definitely, but I'm not sure there are more of them or that they're providing more complexity.

That's because Angular invented new problems to then valiantly tackle them. I've written a bit about this here: https://news.ycombinator.com/item?id=20040877

> I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse.

> I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order.

Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it!

Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.

Most apps are simple, no I’m not talking about Facebook. The problem is templated pages apps are not considered sexy, so we build SPAs so we can look good (and pad the resume,) to the detriment of productivity.

At my day job, the meme that won and now dominate is "the percieved performance of a SPA is greater than that of a non-SPA". My calls for making our backend more performant are ignored (and probably ridiculed, because of how out-of-the-loop I seem). React for the win!

I hardly belong anywhere, it sometimes seems.

I get the impression that OP's day job requires that they use Angular but they were able to use ASP.NET Core Razor Pages for a side project. I could be wrong.

Either way, I can confirm to OP's findings with Angular. I worked on an Angular project not too long ago and every time I hit Command-S I had to wait 10 seconds before the page would refresh. Manually refreshing wasn't an option, of course, because it was busy compiling. I tried to explain to my client that those 10 seconds were quickly adding up considering what my billable rate was but they didn't seem to mind. It was from Google and that's all they needed to know.

React native’s fast refresh is... I’m not even sure of the words to describe it. Revelatory? I had no idea it was possible to develop apps so quickly and seamlessly while maintaining state as you code. I thought edit and continue debugging was the holy grail in C# until I used fast refresh and redux. I would not be exaggerating by saying that I would choose react native as a technology strictly because of how much fast refresh speeds up development of GUIs (but it’s great for many other reasons too). I can’t wait for fast refresh to make its way into react web. We have several large, complex apps in ionic/Cordova/angular stack and now that ionic react is stable it won’t be long for us to jump off Angular altogether.

We have a large desktop application that hosts tabs of other react applications and provides windowing features, all built in Electron, that is written in React. we can edit a component within an app and save it and have the UI update with the same state and the new component change in under a second. react native fast refresh is even better because it’s understanding of life cycles and hooks is better but hot reloading within a react app is extremely performant for us. I wonder why you’re having to wait so long?

I've started playing around with React Native lately and so far have been pleasantly surprised. I have also used NativeScript quite a bit and it too has a very fast compile and refresh. I don't know what it is about Angular that makes the refresh so slow.

Personal anecdote: Angular 1.x at the time was a breath of fresh air because it allowed to create very clean, very modular front-ends with a lot of (unit) testing opportunities. The next best thing we had at the time (again, in my own experience) was Backbone, which was a lightweight layer on top of jquery but we didn't have any tests on that one.

So for us Java developers it was great. I don't know about Angular 2 and beyond, but I'm sure it has its place.

Same here, I made it sure that our next project isn't going to be an SPA. It is absolutely madness what is going on in the frontend development space.

These sound like implementation issues. Why does compile time suck? Do you cache compiled files and update only what has changed? Are you doing minimization and / or compressing in development? If compile time isn't under a second during development, you're doing it wrong.

It does not suck. The compile times are OK and are getting better. Angular (and other) SPAs have capabilities no RoR, ASP.NET or Django setup can even begin to touch. Separating the back-end from the front-end with an independent API is also a god-send.

Death to remaining in the dark ages for nostalgia's sake.

Oh, it does suck, hugely. Longer time to first paint, more bandwidth, more cpu and battery usage, huge dependency chains, slow "live" updates...

A lot of my issue with the Javascript-heavy present of "modern" SPA websites is that they have to recreate native browser functionality, which is inevitably slower and worse.

Way too many websites could have the same functionality, in a simpler form, with better performance with a more "traditional" stack. You can even have your API separated front-end and back-end via server-side rendering (by which I mean old-style server-side rendering).

The modern zeitgeist is mostly hype, fad, and novelty.

> The compile times are OK and are getting better.

Our frontend Angular test runs take 25 minutes to run less than 2,000 unit (not integration) tests. That's just nonsense. I don't blame Angular so much as I blame the JS ecosystem. For comparison our backend unit test runs (ASP.NET Core) take 3 minutes to run 6,000 tests.

You can argue we're doing something wrong, but as a company with a a thousand or so devs - reaching out to the most experienced frontend devs we have, their answer is: you've got too many tests, split up your SPA into smaller SPAs. Great, more complexity and dependency management hell.

I would write backend code in almost any framework before writing Angular, Ember, React... Backend is 100% a better experience.

I can't wait for Rust/WASM to eat Javascript alive. I'm considering writing my next frontend project in Rust.

Reply on news.ycombinator.com