Waiting for React Recoil to become the standard, it's amazing!
recoil is a winner
React I love you, but you're bringing me down
291–300 of 574 posts
Re: React I love you, but you're bringing me down
#292Waiting for React Recoil to become the standard, it's amazing!
apparently they lifted atoms
Re: React I love you, but you're bringing me down
#293I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…
> There are always [] half-finished fix-the-world ideas conflicting with each other,
I work in a code base like this. People's suggestion? Introduce React!
Re: React I love you, but you're bringing me down
#294I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…
I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in. customElements.define('my-element', class MyElement extends HTMLElement { ... }) I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this featur…
React itself really hasn't gotten significantly bigger. It's more of a rendering library than a framework.
Custom elements are really neat, and may very well do what you need. The big pain point that React solves (for me at least) is that you get to define your views declaratively instead of imperatively.
Re: React I love you, but you're bringing me down
#295Earlier quoted context omitted.
woah woah hold on there young one This isn't that. My hostile working definition of a framework is something that . breaks core assumptions about a language or system . limits what a user is permitted to do . increases complexities by adding new abstractions . has non-specific specifications by using unclear and imprecise language At the end you are hardly writing software. Instead you're deep into a world of new abs…
This is cynical as heck, but a good read. Do you have any plans to publish the larger document?
After that encouragement I do! Thanks!
The premise is how to write a successful framework. The cynical takes are presented as advice.
It's structured like those guru business books like "Blue Ocean Strategy" or "Little Bets".
That genre requires an additional separate focus and some further work. It's by a bunch of narcissists who ran multiple businesses into the ground who pivoted to being a guru and offer acronyms, charts, and X-point frameworks in tidy books with a bunch of business examples, most of which catastrophically collapse within 12 months of publication.
And then the books sell 5 million copies, the authors get Ted Talks, it's the same mechanism at play. People pass around their Clayton Christensen of Geoffrey Moore diagrams and crib paragraphs quoting them like they're bible passages. And people eat it up. It's wild.
I remember looking at the Appendix of one of Jim Collins books for the first time about 10 years ago where he talks about his methodology with his team. When you start cross-referencing and see the omissions, mistakes, and misrepresentations, it's wild. I was like "wow this thing is nonsense".
You've got Sutherland's Scrum, Collins BHAGs, and you burn through $20,000,000 in Series A without releasing shit. Alright, I guess that's what we do.
Re: React I love you, but you're bringing me down
#296I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…
It really is hard to understate how damaging the half-finished ideas in the code base can be. To the point that I often prefer to stay on something I don't like, if I'm not positive I can finish moving completely off of it.
> It really is hard to understate how damaging the half-finished ideas in the code base can be.
People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters.
Re: React I love you, but you're bringing me down
#297Earlier quoted context omitted.
"Just" is not really fair here, they're a window into global variables. Global state is awful to deal with but a necessity in the real world, so having some sort of constrained global state is something we're always trying to solve in new ways, singletons, monads, etc. Here we have hooks, which is an interesting experiment but something I personally would have played with in some new framework rather than dropping in…
Depends on what you mean by global state. You don't have access to a single pool of global variables. You only have access to what you put there and what you've been given.
Is it that they are global state to react but not to the programmer or his/her code?
Re: React I love you, but you're bringing me down
#298The part about Redux and Context seems to be a complete misinterpretation of what Context is meant for. It was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. State management in React is a topic discussed to death, there are plenty of options if you have specific tastes or requirements but plain old React state works perfectly fine as well (especial…
> [React Context] was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that.
I think the conflation came more from the "community" than from the React team itself. Many people were (ab)using Redux for simple cases were Context would have been sufficient and, in the process, paying the price of having a lot of boilerplate related to writing anemic "reducers" whose only purpose was to store things on the global state, and eventually also paying the price of having a ball-of-mud of a global state where no-one could be sure of the dependencies between components, as anyone could be accessing anything on that big ball-of-mud. (Been there; not proud.)
So, when the Context API came along, with a much leaner API (no actions or reducers) and less "global-y" feel than Redux, people who were misusing the latter naturally saw the former as a good replacement
Re: React I love you, but you're bringing me down
#299Earlier quoted context omitted.
People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned fr…
> Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" Here's a secret nobody told you: You don't need to learn frontend specifics. All the same lessons from business software engineering apply. I not-graduated comp sci in 2012 and have been building webapps since before jQuery was…
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 comes above more authoratitve sources like MDN in Google results.
Re: React I love you, but you're bringing me down
#300Earlier quoted context omitted.
People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned fr…
> Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" Here's a secret nobody told you: You don't need to learn frontend specifics. All the same lessons from business software engineering apply. I not-graduated comp sci in 2012 and have been building webapps since before jQuery was…
Preach!
Data modelling and managing complexity (or I prefer to say knowledge organization) is a prerequisites for every software program ever.
I'd add one more: System design.
Basically dealing with many asynchronous moving parts, managing entities' lifetime, separating and categorizing domain/data, and understanding what-is-important-to-whom. It is a knowledge that's applicable whether you are programming a kernel scheduler or managing people and projects