Hacker News Reader

Five years is not long.

"Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks"

A very bad example. Most software of significant cost and size is serving a industry, and not the industry itself.

Facebook can break things. If your insurance company or bank break things... Get my point?

I’m sorry, but this comment is a total goalpost mover, and complete BS.

The goalpost moving: the initial article is talking about porting a desktop client based program with a reasonable amount of views to the web. Now Facebook scale and quality UI isn’t good enough to demonstrate that React is a strong front end tool.

I also don’t see how the UI is particularly likely to cause issues to an insurance or banking company.

The BS: “most software of significant cost and size is serving a industry, not the industry itself”. This sounds smart but it has virtually no relationship to the main drivers of complexity behind the UIs in discussion, which is number of developers and number of pages. You cannot reasonably tell me Facebook doesn’t show React scales for UI engineering.

"the initial article is talking about porting a desktop client based program with a reasonable amount of views to the web. Now Facebook scale and quality UI isn’t good enough to demonstrate that React is a strong front end tool"

Not the whole truth. It was a big job. "Enterprise level" has no clearly defined meaning, but I assume millions of dollars. A large team of C# programmers doin the system.

So it is worth doing sustainably. There is no evidence that react, which judging from the "I have N years experience of React..." N <= 5 is about five years old, can be a sustainable solution for anything. It might look good now, but can it be maintained in twelve years when all the script kiddies are off on the next Best Thing

Whichrelates to your rude and sweary comment about: "... is serving a industry, not the industry itself" it is not complexity but sustainability. Facebook is the software. Your bank is not its banking software. The bank needs to know that in a decade they will still be able to maintain the software. If they use React, or Angular or goodness knows what else the bountiful world of JS frameworks will throw up for us, they cannot guarantee that.

I can reasonably say that Facebook doesn’t show React scales for sustainability: It does not.

> "Enterprise level" has no clearly defined meaning, but I assume millions of dollars

Ok, so Facebook builds UIs, manages a valuation worth close to a trillion dollars, and uses React everywhere (even sometimes outside of the web!). That does NOT show React scales for sustainability? My fucking ass. That's a bullshit take.

> can it be maintained in twelve years when all the script kiddies

See, software engineers love to pretend UI engineering is like some half-discipline or doesn't matter, but it just makes you look braindead. Your whole take is "Facebook and its trillion dollars aren't showing React scales" and "UI engineering is for script kiddies". Fuck you.

BTW: I do not believe you are sorry! Hard to tell in comments like this, but I think probably you are not.

And nor should you be! (Perhaps for being sweary, but I am a reformed potty mouthed person - so a bit of a snow flake in that department)

"the entire ML ecosystem has been reinvented in the last 5 years"

Fifteen years, maybe, but because of new technology. Actual physical machines that did not exist earlier.

The churn in JS frame works is because because because, no better reason.

“We judge ourselves by our intentions and others by their actions”

Great reply to this mindset. The chance that anyone who makes this claim has actually evaluated enough (or any) JS projects to see why they churn is effectively zero.

We have version pinning for a reason. It lets churn exist without forcing the effects of it onto other developers. I don't care if a library I use gets updated every week or even every day, I'm not installing every new version when it's released, that's silly. Nobody does that in a real project, that's chaos.

I have evaluated a lot of Javascript frameworks, back in the day.

I have seen nothing new in JS frame works. I have seen a lot of old in JS frame works.

The whole area stinks. Repeating mistakes of yesteryear.

Easier to write than read - explains a lot

Imagine having the arrogance to say "back in the day I looked at this language and I can firmly stay the whole thing is shit". Imagine that thing being the language powering the UIs of the entire modern web.

You have already shown me in other comments that you are highly biased and will say anything if it fits with your biases, but this is really an entirely new level of ignorant

> Context, Provider, and hooks

Which is the biggest foot gun I've seen in my life.

There is a surprisingly high number of developer that still don't get it and will make those beautiful applications where, thanks to a naive usage of this, will create applications that rerender the entire application on every keystroke.

Yes, which you can fix by moving a singular key of the context to component state. The beauty of hooks.

> React, since hooks, includes a full state management solution - Context, Provider, and hooks.

Sure, but that hasn't been around even 2 years. Prior to that, there was a different approach and philosophy to doing things. I remember when higher order components were all the rage till suddenly they weren't.

I'm not advocating for stagnation, but at the same time, everything in JS land feels experimental, even in established frameworks, and the entire community keeps marching along as things keep changing. Which if you are a full-time developer doing that, is fine I guess, but it is not the norm compared to pretty much any other software engineering field.

> Second, even if you want an actual state management library, both mobx and Redux are quite stable

I cannot say enough nice things about MobX (although I was using it back when it didn't use Proxies so you had to deal with a lot of cloning back to native JS objects which got a bit ugly at times), and I don't disagree with you on this point for state management, although I personally could not stand redux despite 90% of the community vehemently singing its praise.

> This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks.

I should have perhaps qualified that better. Yes, I know there are people writing complex apps, but I was viewing it from the POV of a non FAANG type place with tons of engineers to throw at a problem. If I was a single person or a very small team trying to develop something complex, I would place a much higher emphasis on a more stable development environment/language/framework.

> Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications.

Let's take Pytorch as a comparison framework. It's had tons of releases, but at a fundamental level, the core API has stayed the same. I've ported 3 year old code to the latest version with pretty much negligible effort. And at its heart, it is because APIs are kept very stable and people aren't deciding each year that they need an entirely new way of doing ML or performing automatic gradient estimations, etc.

Similarly with Python... there have been a bunch of Python 3 releases in the past few years but they each add new things that are useful without making big changes that suddenly change how everyone would tackle building a new piece of software.

On the other hand, porting a 2+ year old React app to the latest version of React (along with bringing dependencies along) would be a very painful process. I know this, because we've done this at the company I work at.

There is also this implicit assumption in JS/React land that you are going to come marching along with all the latest changes. Heck, less than 2 years back, their documentation site wouldn't even let you view older versions of React documentation, so the moment they released a new version of React, the docs would only ever show you the new docs. What's funny, is that today they supposedly have links to their older docs...but every fucking link is broken :-/

example: https://reactjs.org/version/16.8

And nobody probably even knows that, because there is a general expectation in the field that everyone just keeps staying up to date with the latest and greatest and deals with whatever pain points come along with that and no one has probably even tried to access older documentations or raise issues about it. Which is fine, like I've said many times before if you've made your peace with it and that is your full-time job, but it is not the expectation or norm in most other fields.

Finally, I should state for the record (because you stated otherwise in another reply to me), that I actually love javascript...well at least ES6+ JS. I greatly enjoy(ed) JS, JSX, developing in VsCode, and even building things with React, Mobx, etc. I'm not a software engineering snob who looks down on JS and the ecosystem. But I also have a more diverse viewpoint because I work at a small company and get to wear many hats and have been able to do lots of different things (ML Engineer, Front-end work, write and deploy pretty complex software, etc.). And while I have a lot of fun doing front-end stuff, It still feels like there is a lot of constant overhead to it, and that is pretty unique to this one field compared to most everything else.

> Prior to that, there was a different approach and philosophy

I don't really agree. Context and Provider have existed forever. Hooks really just expose the underlying setState calls with a different API and a more graceful backing engine which allows this more granular access. It's part of why they made hooks

> I remember when higher order components were all the rage till suddenly they weren't

I almost never used these, but what was their main point? You wrap something in a HOC to inject some variable, like a router or something? No kidding we moved on, no need for this to be so heavy. Again, you're kind of understanding why they made hooks, this type of functionality can be and is written more concisely with them

> everything in JS land feels experimental, and the entire community keeps marching along as things keep changing

UI engineering and the web as an application platform isi young compared to "pretty much any other software engineering field", don't you think? JavaScript was kind of a shit language 7 years ago too, so a lot of this churn is because first JS improved a lot and then still needed types so we played with a few type systems.

Now we have TypeScript making beautiful, readable, maintainable code, and battle-hardened yet concise libraries like React, because we were willing to say "hey this could be better, let's try a new way". Seems weird that everyone criticizes that so harshly, don't you think?

> I personally could not stand redux

I also don't understand its popularity. I avoided it from the start and opted for MobX

> large, enterprise app in React

> I would place a much higher emphasis on a more stable development environment/language/framework

I mean, no offense, but React is about the most stable UI framework there is. If you don't like JS and you're going to do this by generating HTML reports from some other language, I think whatever you build is going to feel behind the times.

> Let's take Pytorch as a comparison

> the core API has stayed the same

> I ported 3 year old code to the latest version with pretty much 0 effort

Right, how is this not comparable to React? I can run and build my 3 year old code against the newest version with no porting required. Porting from class-based to functional with hooks is also quite easy; I moved my entire component library (25+ components including graph + charts) in a few weeks, and it came out smaller and more performant.

> Similarly with Python

I actually don't think I would try and cite the Python 3 transition favorably if I were you; it was not smooth.

> On the other hand, porting a 2+ year old React app to the latest version of React would be a very painful process

!? It runs against the latest version of React!! Why do you need to port it?

Also, I'm imagining your app has significantly more complexity than your PyTorch app - otherwise this claim seems even more absurd.

> Finally, I should state that I actually love javascript

Yes, ES6+ JS is strong, with TypeScript it's actually a top language overall. I also work on a small team, and am responsible for UIs, APIs, database design, DevOps, and more. Each of these fields undergoes this massive churn as well; databases tried to go NoSQL on us, APIs are low-code now for CRUD and you're a sucker if you manually write your CRUD apps, DevOps has completely changed from rsyncing bundles to container orchestration deployments running on Kubernetes, ML and data science have reinvented themselves to use new features and more powerful toolsets.

UI development is a complex and young topic and so while you might feel it has churn, all software is constantly undergoing churn to match the community's desire for how expressive and powerful it should be. The fact that people constantly rag on UI toolkits being updated over time makes me think they fail to recognize UI as complex or young. I feel like you fell for it too, because each domain you listed yourself as working in has undergone similarly drastic changes in the last 5 years as React has.