Live data from Hacker News

React created roadblocks in our enterprise app

medium.com

291–298 of 298 posts

Re: React created roadblocks in our enterprise app

#291
post #108

Earlier quoted context omitted.

> Just not the browser Most backend frameworks need literal compilation - all that's different here is that the target is a specific JS version, not machine code. Additionally, there's a bit of "naivety" here - browser vendors are the ones that implement native features, and that's clearly not a domain that a random developer can impact. Instead it's JS frameworks and associated tooling, which is all very strong now.…

Well we can revisit this in the future and see what the status of React is!

Yes we can. Please remember Web Components have no backing, while React has a top tech company actively developing, maintaining, and embracing it.

For the last 5 years, I've heard about "Native Web Components", and for 5 years, the prevailing wisdom is to use react instead. :)

Re: React created roadblocks in our enterprise app

#292
post #206
post #53

Earlier quoted context omitted.

I don't really understand what users are doing when they say things like this. What kind of features are you trying to implement? As a React dev since 2015, things were pretty bad initially in this way - but now you can literally build complete applications with React, react-router-dom (clearly the winner in this regard), and your choice of state management (mobx 6 is, to me, the best). Redux is king and MobX is the…

> debugging / error messages I think its still quite bad for debugging. I get a lot of "look here" for errors, but there are still times I set breakpoints on the internals to try and figure out what is going on. Usually in combination with some babel plugin messing things up, or some webpack caching issue, etc. I still think more could be done here, but adding the necessary debugging stuff would bloat the core. > Red…

> Usually in combination with some babel plugin messing things up

To be honest with you, you can't really blame React in this situation - it is nonetheless immensely frustrating to be sure.

> Redux is quickly going out of fashion

Yes, when I say it's "king" I only mean in terms of popularity within the community. I personally never understood the point of Redux and have always greatly preferred MobX for exactly what you say - it is far too verbose.

I also don't really have a good read on how the future of these projects will go - I would have thought MobX would've won out long ago. Maybe now with MobX 6 moving away from decorators it can gain the steam it deserves. I think the key blocker has been / is that MobX is building a runtime graph, and people don't understand graphs (let alone dependency graphs) very well, so it feels like magic. It's really easy to use though.

With features like Suspense, I feel like React will continue to push for more concise ways to write your components, but I also wonder if even the one level of misdirection that Suspense shows will be enough to limit its adoption. So far, explicit and non-magic seems to be a strange community preference

Re: React created roadblocks in our enterprise app

#293
post #185

One of the core reasons software projects run into problems is politics - and this article is about politics. What should have happened ideally is that the blog post author would have said to the CTO: - we're going with React - you've chosen us to guide you in this - you now need to trust that my advice on standards and approach is correct - you need to get your developers to do it the way I say - if you don't, then…

"- you need to get your developers to do it the way I say" You have a team of developers that have a collective experience of perhaps eighty years in your organisation. Do as I say, me who just popped in and afterwards will pop out again.... That is how millions and millions of dollars are lost in this business.

Just like Riot has 200 years of experience doing their game and shit still hits the fan on a timely basis

Re: React created roadblocks in our enterprise app

#294
post #276
post #254

Earlier quoted context omitted.

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…

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

Re: React created roadblocks in our enterprise app

#295
post #284

Earlier quoted context omitted.

> hating on React It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars. They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway). > With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django…

> hating on React What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell > How can you "promise" this? Because I am a pro web dev who…

> What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement.

A) I have a very different interpretation of the other person's comments• and I don't see anything factually incorrect in them, b) I would call what the other person said criticizing even if I vehemently disagreed, if just to keep the discussion productive, and c) there was no specific "correction" of anything in the comment I replied to; you only expressed that you think react is stable.

> understands the difference in power between HTML templates and JS components

Those HTML templates don't exist in a vacuum and are invoked by whatever language is being used in the backend. The only "advantage" javascript gives is that it saves you the blink of reload; beyond that, the logic of a web application doesn't change in the slightest regardless of where the html is being rendered.

> There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way

The GCP console is a gigantic mostly angular based single page application. The AWS console is mostly a jsp based server side application. You know what they have in common beyond being dashboards for managing cloud platforms? They're both unwieldy giant hodgepodges of work by a multitude of different teams.

There's no silver bullet.

You have a preference for single page applications. That doesn't mean a user is going to like an unusable SPA more than a well architected server application more just because the SPA saves page reloads.

> Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.

I originally asked for a source of your claims, and I would really like to see your data for this.

Let me turn your original claim on its head: With proper backend tooling (be it Rails, or Django, or whatever else) and a low-javascript, progressive enhancement library like htmx, I can "promise" you I can make a better web application than with just javascript, no matter how much JSX hacking one can muster.

But I don't actually believe that, because it's better to use the right tool for the job. Sometimes an SPA framework is the right tool, and in that case I'll go for vue or svelte. After all, they're vastly superior to react ( ;) ).

• For starters, most of them were about the javascript ecosystem in general; for that matter, you've been focusing on react more than anyone else in this exchange.

Re: React created roadblocks in our enterprise app

#296
post #284

Earlier quoted context omitted.

> hating on React What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell > How can you "promise" this? Because I am a pro web dev who…

> What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. A) I have a very different interpretation of the other person's comments• and I don't see anything factually incorrect in them, b) I would call what the other person said criticizing even if I vehemently disagreed, if just to k…

FWIW, I am not against SPAs, either. I actually prefer using them in most cases if I can help it, because it pushes me toward building out an API that is not coupled tightly to my web front-end, and can be reused if I ever need to serve a mobile app, etc.

Also, you are correct that I was not initially dissing React specifically. The amount of churn in the Node ecosystem is a real issue, and I am always getting those vulnerability emails from GitHub for old, forgotten repos where a dependency I never even knew I had is problematic.

Deno recognizes this is a serious problem, with one of the bullet points at the top of the home page touting "a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std". Deno was started by Ryan Dahl, who also invented Node. I don't know if he's said this explicitly, but I would imagine he had his own Dr. Frankenstein moments with Node.

Re: React created roadblocks in our enterprise app

#297
post #284

Earlier quoted context omitted.

> hating on React It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars. They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway). > With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django…

> hating on React What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell > How can you "promise" this? Because I am a pro web dev who…

>Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components

so what you're actually promising is you can make a better website with React than with Django for any website that needs advanced JavaScript interactivity - but then obviously the comparison would not be between Django and React but between React and some other JavaScript based frontend technology.

Re: React created roadblocks in our enterprise app

#298
post #283

Earlier quoted context omitted.

Stability is not just about backward-compatibility; it also means promoting concepts/idioms which are consistent and long-lived. Django has been around for about 3 times as long as React, but has not undergone the same amount of churn that React has. If someone wrote React code in 2016 and left the scene for a couple of years, can they come back and build new React projects without significant re-training? Regarding…

> can they come back and build new React projects without significant re-training? The answer is yes

with the proviso that anywhere you try to work at doing this will probably complain because you are not using the new way of doing things.
Post reply on HN