Live data from Hacker News

React I love you, but you're bringing me down

marmelab.com

411–420 of 574 posts

Re: React I love you, but you're bringing me down

#411

Earlier quoted context omitted.

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…

That's why I like GraphQL, you get exactly the data you request, no transformation necessary.

True and I like GraphQL but in many cases your UI needs data in a way that isn't available on your existing endpoints. Ex: summary data / aggregations for reports or analytics. Or simple things like fullName on a user entity, a displayAddress, a display greeting based on their user group, you get the idea. You can do all of this on the frontend but it just becomes messier.

This is what I'm referring to.

So you still need to write some new graphql resolvers on the backend and update your graphql schema. Not much different from writing some new REST api endpoints or expanding an existing endpoint.

But if you use GraphQL then I agree on the benefit and approach still of having as much of your data logic on the backend. And with GraphQL you have a schema that is readily available, auto-documented and available for frontend devs to use for current and future components.

Which is better than having that logic on the frontend IMO.

Re: React I love you, but you're bringing me down

#412

Earlier quoted context omitted.

It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases

Hooks had nothing to do with v8 optimizations or `this.state`. Per https://reactjs.org/docs/hooks-intro.html , the primary motivations were: - "It’s hard to reuse stateful logic between components " - "Complex components become hard to understand" - "Classes confuse both people and machines" (remembering how `this` works, code minification, method binding, etc) There's also an excellent "Why React Hooks?" post at htt…

> This works because closures capture data in a scope, whereas mutable class instances could have gotten changed and refer to a single `this` instance.

So `this.state` is hard to optimize?

> Hooks had nothing to do with v8 optimizations or `this.state`.

Huh? That's what you just said. The spec makes it hard to optimize. The JIT compiler can't infer enough about the shape of the data.

Re: React I love you, but you're bringing me down

#413

Earlier quoted context omitted.

Vue 1.x was great, v2 lost its way, and Vue 3 with the composition API looks fantastic on paper. (I haven’t used it in any meaningful way) I’m even more impressed with the extended Vue ecosystem like Vite, Vitest.

> Vue 3 with the composition API looks fantastic on paper. (I haven’t used it in any meaningful way) Recently worked on migrating a large codebase over from a legacy solution to Vue 3 with composition API, it was a pretty enjoyable experience, especially with Pinia! Though I'd say that the problem was that most component libraries/frameworks out there actually don't support Vue 3 well enough. Last I checked, only the…

> Most of the other ones considered weren't quite there yet

From what I recall, quasar managed to update very quickly.

Vuetify is currently in Beta for Vue 3 as they went with a greenfield rewrite to deal with tech debt. I rolled it out to a production site recently and it works well.

BootstrapVue completely dropped the ball, despite the corporate sponsorships the original maintainers went missing for a whole year & bailed. It got new maintainers at the start of the year, but they've been delayed by current geopolitical events.

Re: React I love you, but you're bringing me down

#414

Earlier quoted context omitted.

Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…

This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring. For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel. The little I know about JS so far, I definitely know this joke is tired and played out. Step 2: Get a better joke please?

I understand your frustration, but I think you’re missing what is actually meant to be a helpful takeaway from this.

Essentially, all these frameworks ARE part of a cycle that repeat, and in time we all start to see it. Most of them just iterate on previous concepts, with some core concepts going way back to the late 60s, 70s and 80s.

What remains the same is the underlying Javascript language itself, and more importantly, fundamental software engineering and computer science principles.

Learn the fundamentals, and they will help you learn every new framework and language more easily, and in more depth.

If you really just want to get a job using JavaScript, then you might be best off browsing job postings to see what kinds of companies are hiring for which frameworks, and go from there.

But if your goal is literally to learn JS and find the right tech stack for you, unfortunately there is no replacement for learning the basics, and then picking a framework that looks interesting, and building something in it to see if it clicks with you.

Re: React I love you, but you're bringing me down

#415

Earlier quoted context omitted.

By the same extension, would you consider your comment worthy of the same classification of "cringey"? How you feel about the delivery is not relevant to the topic, and if you had opted not read to it, it would not be the person in the arena that would be at a loss because of it.

> By the same extension, would you consider your comment worthy of the same classification of "cringey"? No, but I think your comment falls squarely in that category.

Have a great day! Hahaha

Re: React I love you, but you're bringing me down

#416
post #356

Earlier quoted context omitted.

Eh, to some degree you do get a starting point in uni for various things. You’ll learn basic models for systems or databases as part of core requirements. If a web course exists, it’s most likely optional and out of date. Web is certainly a different context, and some people struggle to pick it up. There’s no authoritative book like the C Programming Language, and the web is full of wrong information that sometimes c…

> Web is certainly a different context I mean it's a thin or fat client talking to a fat or thin data source over a network. "We" have been building systems like that since the 1950's.

This is absolutely correct from the perspective of a senior developer. Junior devs generally haven't completed enough language/framework hype cycles to develop the required experience (or cynicism really) to look past the bullshit to this very simple fact.

Re: React I love you, but you're bringing me down

#417

Any general coders wondering about React as their first front end framework - just use Vue. It’s easier, makes quite a lot more sense, has a “one true way” approach regarding many topics and can be comfortably learnt in a day. It’s easier for others to understand your code too. JSX yuck.

Would you say Vue 2 or Vue 3 would be better for someone venturing into Vue? Also, have you used Svelte much?

Easily Vue 3, the dev tooling/xp + docs are much better over Vue 2.

Re: React I love you, but you're bringing me down

#419
React and other client-side frameworks are great for apps where you need a highly responsive UI, but for many websites, server-side frameworks (Rails, Django the many spinoffs) are easier to write and maintain than SPAs. Yet there seems to be this idea that every "modern website" must be written with a JS framework like React.

Re: React I love you, but you're bringing me down

#420

Earlier quoted context omitted.

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…

That's why I like GraphQL, you get exactly the data you request, no transformation necessary.

This is why I dislike graphql especially with react. It’s gets set up as a half assed ORM (but without joins!) and then all but the most senior of engineers end up using it as your application state which slows the whole app to crawl forcing a big rewrite.

Using an orm and building a proper data model in your code using a store like redis takes very little additional time (especially with sequelize!) and it has the benefit that your junior and mid level engineers understand where the underlying data is stored.

Post reply on HN