Hacker News Reader

Hacker News

Comment by tambourine_man | Hacker News Reader

Parent Full thread

tambourine_man

Sorry, I won’t take blame for that.

Still haven’t found a use case for React/Angular or SASS/whatever.

If I’m guilty of something is not recognizing the validity of those tools, as I’m sure there are.

But 2MB CSS is simply inconceivable to me.

View on HN

I agree, React/Angular front ends always seem slow and clunky to me.

Big +1.

I would be really interested to find one, only ONE, website where React/Angular was really bringing a better experience and better final product than a standard pure JS with simple Ajax system.

What makes you think React/Angular are products to increase user experience? Of course you won't find that, they are tools for developers to streamline development and make maintenance easier. Have you worked on a platform that uses nothing but pure JS and fetch calls? I have, and there's no way to make sense of a project that has to deal with so many things.

>they are tools for developers to streamline development and make maintenance easier.

I'm not convinced they are successful at that either.

https://m.youtube.com/watch?v=F5hA79vKE_E

why is it downvote ? This link just show you can create a basic twitter like application in 10 minutes with the right tool. Imagine how many hours/days it would take with any JavaScript framework !

Probably because a Twitter close isn't even close to a complex application. You can build one in React/Vue just as fast as you would without them.

Yeah, it's a common trope. Everyone can create a Twitter/Facebook/Instagram clone in a week or so of intense work. But that's not actually the hard part. What's hard is getting millions of users in the first place and scaling to that magnitude. In that order.

Anytime you need to stream data to or from a client, like audio/video or data. Single page apps have a much better experience.

From an architecture standpoint, it does also allow a much simpler separation of concerns.

That said, it does it get used more often that it should and can take more time to build than a multi-page app.

Fucking gmail, for example.

The new SPA version is far, far slower than the old HTML version, and uses a truly insane amount of memory. I have 2 gmail tabs open, and according to Firefox's about:performance page, one is using 140mb of RAM, the other is using 95mb, and both are at the very top of the list in terms of CPU usage. Above even YouTube in both CPU and memory, which is itself fairly bloated.

It is absolutely disgraceful.

Google Cloud Console felt slow to me too. And the user experience could sometimes be better too. For example: I set filters in a table of items, clicked many times to Next to paginate on the 10th page. Then I accidentally clicked on an item on the page, detail page shows. Clicking browser' Back button takes me back but the filter is cleared and I am on the page #1 again. State was not persisted so I could start filtering and paginating again. I am not 100% sure but I think it was the Quota listing. The old, document-style pages used to hold state!

Humans have been using physical and mental systems to manage complexity for eons, I simply can't understand this argument. React doesn't automatically fix spaghetti code if you don't know how to organize a platform-sized code base efficiently in the first place.

This is like saying "cabinets don't help organize a kitchen if you don't put anything in them" -- I mean, duh, you have to use it right. That's not an argument to have no cabinets.

There's a reason nearly ALL major web applications rely on a _framework_....rails, django, laravel, you name it. These exist because it's really hard to organize vanilla code without a framework. React and FE JS are no different.

If you're arguing against using a FE framework to organize FE code, you're basically saying "We don't need frameworks in general! All code should be inherently organized!" That's not realistic. It's just not feasible when you have a large project.

> This is like saying "cabinets don't help organize a kitchen if you don't put anything in them" -- I mean, duh, you have to use it right. That's not an argument to have no cabinets.

Good counterpoint. Parent comment sound too much like the "TRUE programmers don't use data structures" old meme

Yeesh, you've badly misinterpreted my comment. Re-reading it, I'm partly to blame here.

>That's not an argument to have no cabinets.

This isn't the point I was trying to make. I didn't mean to piggy back on this part of the parent comment: "Have you worked on a platform that uses nothing but pure JS and fetch calls?"

I meant to respond to this part of the parent: "they are tools for developers to streamline development and make maintenance easier." I often find that the most ardent React fans will see "not React" and jump immediately to "spaghetti of vanilla js and fetch calls," with no further questions asked.

I'm trying to argue against React dogmatism, I'm not arguing in favor of "no framework" dogmatism.

Well, if we take a step back from React and talk about a sort of data-first approach to UIs, I think they are definitely, much easier than the old jQuery era.

Mutable state, notably knowing all possible variations of said mutable state and how it relates to everything, is very difficult imo.

Is React the best implementation of this? Definitely not. It will evolve as time goes on. But I don't think I could ever manage state in the jQuery mutate-everything model again.

To be clear I'm not advocating for React on every possible use case. In fact I've grown weary of it over the years, but not for the reasons the comment I was responding to pointed out. My point is that React makes the process of organizing frontend code easier, not that it's the only way to do so.

I've used react for internal administrative tools for configuring UI, and the ability to do a real-time preview of what the UI will look like based on how you've configured it is pretty useful. Also used it a number of times to build form inputs that aren't natively supported ("list of objects all with the same properties where you can select and make a change to a bunch at once" sort of thing).

Basically I've found that if you're doing something useful which could be done with jquery but would probably have had subtle bugs due to a combinatorial explosion of possible states, you can usually use react in that context to make a cleaner, faster, and less buggy version of that same UI that is faster to develop and easier to reason about (and thus better for the end user, since software that works consistently is more valuable than software that mostly works as long as you don't breathe wrong near it).

If you're looking for examples where a single-page app is better than server-side-rendered HTML with some javascript sprinkled in to make certain components more interactive, though, I can't help you. The successful use cases I've seen for react are of the "use it as the way you sprinkle additional functionality into your server-side-rendered HTML" type.

better experience for who? For the developer it's a way better experience. For the consumer it often isn't because of inefficient bloat, but if effort is put into packaging it sensibly it can be better thanks to build pipelines/optimizations. In my experience, there's a lot of apps that would have never gotten written in the first place without the boost from React/Angular/etc. It simply takes way longer (which means also more expensive) to use "pure javascript and ajax."

I've been doing FE development on and off since IE5/6, starting out with pure JS and Ajax, and in my opinion the modern FE developer experience using the major frameworks is a generational improvement over the messes we used to write. There are still frustrations, but it's a lot better than it used to be.

Browser API's and CSS have all improved drastically since then, so pure JS and Ajax isn't as bad. I still avoid frameworks for small things just to keep pages lightweight. But for heavyweight projects, if you don't use an established framework, you just end up with a shitty home-grown framework anyway, because the alternative, teams of developers working on the same site with no frameworks, is even worse.

Agree completely. I'm amazed at how good pure JS is these days. I only use React when I have a non-trivial UI that I need to write. It's just not worth it for simple stuff. That said I don't do a ton of FE work these days, so my opinion is less relevant.

For a certain kind of developer who drinks a certain kind of Kool-Aid, sure. Personally I am a lot less productive when I’m forced to work on a React codebase. It’s kind of like using an ORM, it can feel like it makes things easier, but really you end up fighting with the abstraction more than if you had just learned the underlying technology itself.

The thing is, every place I've worked that was against ORMs or frontend frameworks wound up evolving their own half-documented, half working framework. I find it's easier to spend as much time learning the abstraction as the underlying technology, and then that knowledge can be ported from system to system.

My experience too. The whole "we don't use a framework" sounds great but it always turns in to some sort of home grown framework that is poorly documented, has bugs, and isn't open source so you can't take it with you when you leave.

Related: "I don't watch or even own a TV" [watches Netflix/YouTube on a laptop six hours a day]

You also miss out on the community aspect of things. Working with a framework like React means that there is a worldwide community of developers that you can tap into when you run into a roadblock.

It is incredibly frustrating to run into an issue with a home grown framework and have to ask around only to discover that the person who wrote the part you're having trouble with left the company 2 years ago and no one else understands it.

I can't help but feel like the people that feel this way are people that don't build maintain and modify customer focused web products for a living.

I updated openEtG to use React instead of PixiJS. https://etg.dek.im https://github.com/serprex/openEtG

Fixed some UI bugs, made it straight forward implement features like better animations & replays, performance improved by removing stuff like a constant timer for UI & having a global mousemove handler tracking mouse coordinates

Come on man, real programmers use assembly and roll their own browsers.

Assembly is a needless abstraction. Real programmers create binaries with xxd.

Real programmers use a magnetized needle and a steady hand.

It sounds to me like you may have never worked in a codebase with thousands of JS files. On a major application, organizing code in vanilla JS is all but impossible. I agree it's better for a very small case, and I agree react slows things down, but that's a worthy trade-off for having organized, legible code.

These are parallel things. Frontend frameworks let you build more predictable and solid apps than vanilla JS.

Indirectly it leads to better UX since the developers can spend more time on UI tweaking, than doing it vanilla.

Well, one primary benefit seems to be to make loading indicators/spinners into first-class components.

What simple Ajax system?

That 2MB of CSS is legacy crap most of it they didn't use. It's the hallmark of Conway's law.

React, Vue, and Angular all use a virtual DOM, which means they're already deprecated 5 years from now. A virtual DOM is dumb.

SASS, SCSS, LESS, etc are kind of great though. It sucks you have to compile them to css, but you can do this:

    .App {
      .Topbar {
        .Logo { color: green }
      }
      .Content {
        h2 { color: orange; }
      }
    }

Saves a lot of time and effort.

Angular uses an incremental-dom not a virtual dom: https://github.com/google/incremental-dom

https://github.com/google/incremental-dom#usage

Technically correct. The point is, it's not native.

Reply on news.ycombinator.com