Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React created roadblocks in our enterprise app

medium.com

Post reply on HN
Print view View original

281–290 of 298 posts

Re: React created roadblocks in our enterprise app

#281

Post by renewiltord »

midrus wrote: post #263
renewiltord wrote: post #152

Is there a Rails for React? I use React+Redux+Typescript and it's nice but I always have trouble setting up a new project. Rails is magic in that it's all ready. React+Redux+Typescript is great. I just don't want to make decisions here. I want to just make a web app. Like how Rails defaults to ActiveRecord and friends, is there something like that for Rails+React+Redux+Typescript? I'm looking for: * Few decisions for…

Then just use rails. Why are you looking for the same thing in a different language? Just for the language? Or because it is more fashionable than using ruby?

I find that writing React apps is easier for me than writing HAML apps. I have a system now where I can get both but I was wondering if that system is encoded as a framework. I tried the next.js suggestion from the other guy and it’s far short of rails so I think I’ll stick to my thing for now.

Re: React created roadblocks in our enterprise app

#282

Post by zach_garwood »

recursivedoubts wrote: post #10

It's funny, react reminds me a lot of J2EE (and other enterprise frameworks) in many ways. A very large and complex framework, with lots of moving parts and additional stuff that needs to be glued in to make it all work. There is a reaction against this happening right now. You can see it in hotwire from 37signals, Alpine.js and my own response to it: https://htmx.org “Simplicity is prerequisite for reliability”

I recently tried advocating for using htmx for our frontend, but had a hard time even articulating what it is. Calling it a framework seemed disingenuous because, well, HTML+HTTP is the "framework," htmx is just an extension on top. At the end of it all, we went with InertiaJS with a component library -- not a bad alternative in its own right -- but I was hoping to do away with the frontend/backend distinction entirely. I hope I get to use your library in production someday, tho! Nice work!

Re: React created roadblocks in our enterprise app

#283

Post by d0100 »

ralmidani wrote: post #169
nawgz wrote: post #156

Earlier quoted context omitted.

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been…

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

Re: React created roadblocks in our enterprise app

#284

Post by nawgz »

julianmarq wrote: post #218
nawgz wrote: post #156

Earlier quoted context omitted.

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been…

> 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 has made a ton of apps and understands the difference in power between HTML templates and JS components? 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. Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.

Re: React created roadblocks in our enterprise app

#285

Post by nawgz »

ralmidani wrote: post #169
nawgz wrote: post #156

Earlier quoted context omitted.

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been…

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?

Absolutely. For one, React introduced a few primary concepts: components, JSX, and the component lifecycle. Whether you wrote functional components, class components, or moved to the new hooks-based components, these lifecycles are behaving the same. The way you write the lifecycle hook might be slightly different in a hooks world but it still exists the same. JSX is almost entirely unchanged in my experience. Composability and other techniques to pass data or context thru to the children still work the same as ever. Accessing DOM nodes still works the same as previously but with a new method as well.

In general, "the old way works but there's a new way too" sums up a lot of the core features. The library has updated and refined itself, but maintained back-compat with almost all old ways of using it, and conceptually stayed true.

Re: React created roadblocks in our enterprise app

#286

Post by nawgz »

worik wrote: post #173
nawgz wrote: post #156

Earlier quoted context omitted.

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been…

"my code from 2016 still works correctly" That is no time at all in "enterprise level software", being software with investment counted in millions of dollars. What about your code from 1996? Will your React code word in thirty years?

If you don't know why this was downvoted - React rose to popularity in 2014-2015, and so my code from 2016 working correctly implies that the library has remained compatible with code written almost at any point in its lifespan.

Also, shouldn't "enterprise level software" prioritize new and improved ways of working for maintainability in 30 years anyhow? React & TypeScript is going to be a much more readable form of maintaining UIs than old-school template hodge-podge, direct HTML generation, jQuery, or whatever you want to point at. To that end, I answer "my React/TS code is more likely to work in 30 years than a legacy system being forced into the modern web world"

Re: React created roadblocks in our enterprise app

#287

Post by nawgz »

sli wrote: post #253
ralmidani wrote: post #150

Earlier quoted context omitted.

React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from function-based to class-based views, but the change was far less abrupt, and you can still use functional views if you want to. As for TypeScript, I agree it's amazing, but it's neither a framework nor a library for building web applications. It's more of a superse…

I really wish I saw what everyone else sees in TypeScript because that language has not sold itself to me at all, even using it professionally for years now. Even using it's primary feature can be a pain because nobody documents their types as far as I've found. It's surprisingly common for me to write code that compiles but crashes at runtime. Other, better JS-targeting languages manage to allow me to retain type-le…

> I really wish I saw what everyone else sees in TypeScript

> It's surprisingly common for me to wrrite code that compiles but crashes at runtime

Well, is it also common for you to allow `any` in your code?

TypeScript is strongest when it can type-check your entire code. If your API endpoints return data that doesn't match your type (or at any other external data load point), TypeScript clearly can't help with that. I'm actually quite sure that if you have this kind of behavior in TypeScript, your other JS-targeting languages would fail too; you have just mis-typed something.

> Other, better

Yes, you're not biased

> JS-targeting languages manage to allow me to retain type-level features at runtime

What does this mean? They compile to put a magic key `_type` on an object?

> while also outputting leaner, faster, and safer code

I highly dispute your claims. You're building JS still, it's not going to be magically better - this just means you write bad TS. Show me some numbers or some code to make this claim.

> it feels like a huge push for the right reasons and in the worst possible direction

Given that you started your complaint with "no one documents their types", I am not so inclined to listen to your opinion. Types are the documentation. Interface names, key names, types, full autocorrect interacting with any objects, generic type support, reasonably smart type solver / caster, great error messages; these are all things TypeScript offers for learning a thin extension of JS.

> I'm not even going to touch how visually noisy and distracting I find the C#-style type syntax to be

Why not? I would love to hear more ridiculous complaints which only make sense thru your personal lens and have no justification or empirical evidence behind them

Re: React created roadblocks in our enterprise app

#288

Post by nawgz »

worik wrote: post #234
nawgz wrote: post #198

Earlier quoted context omitted.

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 compa…

"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 doin…

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

Re: React created roadblocks in our enterprise app

#289

Post by nawgz »

_coveredInBees wrote: post #158
nawgz wrote: post #122

Earlier quoted context omitted.

As a React dev for half a decade, I strongly disagree with many of your points. > React [includes] so little that you become reliant on a ton of external dependencies React, since hooks, includes a full state management solution - Context, Provider, and hooks. Second, even if you want an actual state management library, both mobx and Redux are quite stable. Applications I have built in 2016 are still running and buil…

> 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 estab…

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

Re: React created roadblocks in our enterprise app

#290

Post by WorldMaker »

nickthemagicman wrote: post #243
WorldMaker wrote: post #153

Earlier quoted context omitted.

> "JSX is supported by quite a lot of frameworks, so you aren't locked into React" > Just not the browser natively.... Angular's *directive and [weird] (binding) [(choices)] will never be supported by the browser natively either. The fact that Angular uses an HTML file extension is a delusion (they really should have picked a different extension, it's such an ugly lie) that the templates will ever be more portable th…

Well I can't comment because I've never used Angular. Sounds like it's as much of an anti-pattern as JSX.

I think it is a worse anti-pattern than JSX: JSX at least uses its own file extensions and doesn't pretend to be HTML. Angular uses the HTML file extension and in my experience confuses a lot of people into thinking the "Angular Template Language" is "just HTML" when it very definitely is not.
Post reply on HN