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

61–70 of 298 posts

Re: React created roadblocks in our enterprise app

#61

Post by nickthemagicman »

bluefirebrand wrote: post #24
nickthemagicman wrote: post #18

Earlier quoted context omitted.

JSX always seemed like a red flag to me. It was redesigning something that already exists to make it so that it uses non native browser functionality? Also the portability looked like an issue from it. I don't understand the use case for it. Vue and apparently Angular use basic browser friendly components.

Why does it really matter if the code you write is browser friendly or not? Everything is transpiled to browser code anyways, that includes Vue and Angular and JSX. None of the code you write is ever really touched by a browser anymore. At the very least it's minified.

Agree completely!

I think the whole ecosystem is insane!

Something that needs 3 or more layers of transpilation...is not right. Typescript to Babylon to JS. Sass to css.

These are workarounds for native JS warts.

That's why Im excited about NATIVE web components and future releases of JavaScript becoming sophisticated enough that we can ignore all of this framework insanity.

Or even better...web assembly somehow taking over and making all of this pointless. Native Typescript. Yes please.

But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.

Re: React created roadblocks in our enterprise app

#62

Post by franklyt »

The main problem I’m having here is that I can’t think of any JavaScript framework that has solved this problem.

Angular is just too cumbersome, though it gets an honorable mention.

Perhaps there is so much churn here because the correct way hasn’t been discovered yet?

Re: React created roadblocks in our enterprise app

#63

Post by nkw »

swsieber wrote: post #16
ourcat wrote: post #4

AngularJS was indeed a bit of a pain when we switched to Angular 2+ and beyond, but it was so worth it. I chose it because of the skillset that our current (small) team has. There's no way our 'designer' (more an HTML/CSS guy) could have wrapped his head around JSX, the way it mixes scripts with layout markup. The way Angular separates concerns for us is great. And the components are extremely flexible and reactive a…

Oof. I work on an angular app and the build is slow as molasses because it's big. And we of course don't want to move away from the official build tool because build time improvements are always "right around the corner".

You might consider NX if build times are an issue. It is monorepo based and includes computation caching[2] and incremental builds, but under the hood uses the angular build tools. We've found it pleasant to work with.

[1] https://nx.dev/latest/angular/core-concepts/computation-cach...

Re: React created roadblocks in our enterprise app

#64

Post by nickthemagicman »

nawgz wrote: post #60
nickthemagicman wrote: post #18

Earlier quoted context omitted.

JSX always seemed like a red flag to me. It was redesigning something that already exists to make it so that it uses non native browser functionality? Also the portability looked like an issue from it. I don't understand the use case for it. Vue and apparently Angular use basic browser friendly components.

How is magically hydrating a DSL extension of HTML any better than using JSX? Arguing about "non-native browser functionality" doesn't make any sense to me, your Angular app doesn't work until it's com-trans-piled into the same HTML/CSS/JS output that JSX produces...

Oh I agree. It's all insane. Ready for native web components and/or web assembly to become mature and get rid of this JS framework, 5 layers of transpilation, nonsense.

But to address your point, you're locked into JSX a lot more than someone writing in native browser code that doesn't need transpilation and can be ported between other frameworks at the end of the day.

Re: React created roadblocks in our enterprise app

#65

Post by nawgz »

zumu wrote: post #17
sergiotapia wrote: post #3

I don't agree that React is not enterprise ready. The mistake OP made was reaching for Redux for some weird reason. Redux-saga, _thunks_? I guarantee this project used thunks of some kind because some blogger posted about it and it was popular and trendy. Pick boring tech that's objectively simple and not an exercise in genius. mobx, today: apollo-client (if you have a graphql api). I've never seen any other project…

> I've never seen any other project stain a framework as much as Redux has done. Is there a good article that would summarize the backlash against Redux? While I don't do front-end much anymore, Redux was such a productive tool for me when I was a contractor. I found it incredibly powerful and easy to work with, if cerebral for the uninitiated. Meanwhile, I had the exact opposite experience with apollo-client and the…

It sounds like GP drank the mobx juice to me.

Honestly, after using mobx, it's almost impossible to understand why Redux is popular. MobX is more concise, more performant, has a crazy amount of built-in optimizations, and lets you forget about tracing your crazy graph of relationships just to update some view.

Of course, mobx had "bad" (read: used decorators) syntax for a while, and only with MobX 6 did they clean it up, but boy oh boy is it clean now

Re: React created roadblocks in our enterprise app

#66

Post by mixmastamyk »

iamsb wrote: post #32

As a counter point, I was almost fired for not choosing to build a SPA for an internal app which was going to be used by 3-5 people, 5-10 times a month, if that many. I worked at large accounting software provider, and internal billing system used static pricing which was changed once a year. The company wanted to move to a more flexible system where pricing can be setup based on few rules like customer type. For thi…

"old style" from the horse-and-buggy-olden-days of 2010+ :D.

Re: React created roadblocks in our enterprise app

#69

Post by dntrkv »

hertzrat wrote: post #8

There are a variety of clips of Jonathan blows twitch stream where he talks about web development. He feels that it has gotten so inefficient and complicated that it now takes 20x as long to create something as it needs to. He suggested that it would be faster for most teams to create their tech stacks utterly from scratch. He further argued that once this efficiency problem gets figured out, most web jobs will disap…

He sounds like someone that hasn't done any web dev at large scale. 90% of the web devs at my place of work just fulfill business needs day in and day out. Around 10% actually spend any time messing with the tooling. Sure, when you don't know what you're doing and you're working on a smaller project, you can get bogged down with the tooling aspect. But in every job I've worked with a healthy engineering culture, the tooling side of web dev is invisible to most of the devs to the point where they wouldn't know how to make a config change if they wanted. They just build shit.

Re: React created roadblocks in our enterprise app

#70

Post by Gaelan »

flowerlad wrote: post #59

> So I am not afraid of getting into a debate about why those are unusual patterns for React. I have seen some developers follow patterns just because they are patterns. Once the community starts doing things one way that's it, even if it is a dumb way, the herd mentality causes the dumb way to become established. Redux is one of those dumb ways. > Because 30% of the business logic was inside Redux-Saga, I marked it…

> Business logic should be written in POJO. Plain Old JavaScript Objects. Using a library such as Redux is a dumb way, but this is the community-embraced, herd-mentality way.

Redux is really just a pattern for business logic using POJO - you have a function that takes an update and returns the new state. The library itself is about a hundred lines.

> Use Web Components. Using the flavor-of-the-month JavaScript libs for a large application that must live years or decades is not justifiable.

How is web components not just another flavor-of-the-month JavaScript library, and an unpopular one at that? Sure, it's part of the browser instead of something you load externally, but I'm not sure that changes things in any meaningful way. You're still tightly binding your code to something which may or may not remain popular.

Post reply on HN