674 karma · joined May 27, 2011
Side projects https://projects.owenkelly.com.au
The whole idea of the useState hook, is that it’s _not_ internal state to the hook. That state isn’t stored on the stack of the hook function, but against the component.
So like many other functional programming langs/libs/frameworks react had a controlled means to run side effects.
That’s the escape hatch of useEffect. It’s not a bad thing. It’s thematically same as the unsafe block in Rust. It allows you to reach out of the main paradigm, when required.
useEffect let’s you safely communicate with the world outside react (ie cause side effects). It’s the only reliable way to …escape.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
All declarative code eventually runs something imperative.
And anything non-theoretical is going to have side effects somewhere.
Painting to a screen is a side effect.
Reading a file is a side effect.
Software gets messy when it intersects reality.
But, we can do quite a lot by staying in a theoretical realm. You can build a whole UI in the theoretical realm, where no side effects exist.
When you actually need to run it though, you drop out the the theoretical and into reality. Now there’s side effect’s everywhere.
So you contain them. Encapsulate those side effects into composable blocks. Test them extensively. Offload that work to someone who’s just focussed on managing them.
Updating the DOM is a side effect. Making a network request is a side effect.
Contain them, test them, and then you can stop thinking about them.
If someone else has done all the work to contain side effects, you can build a UI without them.
The comment was a reference to the fact that if you don’t use a framework, you’ll end up a building one anyway.
We didn’t have classes until ES6. And they’re not real classes, they still use prototypical inheritance under the hood.
If you want truly idiomatic JS, you shouldn’t be using classes. You should only be writing functions, and build your class-like objects with prototypes.
On a practical level, I absolutely recommend new engineers learn React. The job market is enormous, it’s a skill the market still rewards well.
And it’s a very productive framework. It rewards you for learning it, with better collaboration and velocity.
I would say the same for the other major view frameworks too, but React still has the biggest job market.
Until ES5, the industry thought JS was a Frankensteinesque monster.
Until maybe 5-7 years ago, anything that wasn’t OOP was considered a bit weird.
Calling any of these languages weird, is like policing English speech. We borrow so much from other languages that’s words have multiple meanings. Pronunciation follows contradictory rules, and regional dialects can be hilariously incompatible.
There’s a few languages closer to French, which has a strict control on what the French language is. For example, Go. There’s really only one paradigm them, only one way to do things.
Like it or not, pushing the boundaries of language design and framework design is how we improve as an industry.
You can’t not like a new thing because it’s weird at face value. You risk missing the forrest for some moss on a tree, and being left behind.
And sorry, that’s the same article this comment thread spawned from. I didn’t find it convincing at all, it’s let down by a lack of understanding in a few key areas.
The code you linked is what React helped me get away from. There’s multiple files in different folders for one screen. It’s hard to see how it composes, which is a useful boundary as it lets me know in the scope of that part of the UI.
UI is _hard_. There’s complexity that needs to go somewhere, and I’m one of those who prefer to push as much if it that isn’t business logic into a framework.
This becomes exponentially more important for every engineer you add. Go success is along these lines, with typically only one way to do things it’s much easier to share code.
From the code you linked, I could find my way around, but piecing it all together took a lot more work than any of the frameworks.
You mention only needing to know JS, HTML and CSS. But you missed that you still need to know how all that code is put together, what calls what. How it updates. React needs this too, the only difference with it being a framework is that knowledge transfers to a different project.
And to be clear, I’m not saying you need to use react or a framework—going your own way is often how amazing new things are found.
What I am saying is your attitude isn’t helping you here. React is still arguably the most used framework[0]. There’s a reason so many of us like using it and it’s what you described as “other crap”.
Frameworks help with collaboration, in the same way programming languages do. To do anything interesting with a general purpose language, you’re either going to use a framework, create a new one with good documentation and build a community of engineers around it, or build a halfbaked one that few people understand.
I’m open to other ways of doing things. It’s a good way to grow. I learnt SwiftUI a little while ago, and while I don’t use it regularly it improved my understanding of UI building. I learnt imperative UI API ages ago, and know for sure I want to avoid/contain that into a more manageable declarative approach.
[0] https://trends.builtwith.com/javascript/javascript-library/t...
Because at some point your function call is manipulating registers on the CPU. If we go even further, the CPU needs to load its next instructions and then the data required.
Point being, we abstract and encapsulate complexity and provide a simpler API around it. It’s the only feasible way to manage the inherent complexity.
React builds up a virtual description of UI. react-dom and react native take that description and synchronise it to the UI layer.
If you need to do something extra, that they don’t handle like managing a map widget (ie mapbox) in React that only has an imperative API, it sure would be nice to do that yourself.
You can build a UI without useEffect. You can hide messy implementation details inside a well tested component, and contain where useEffect is being used.
And, you can understand how useEffect works so that you can use it without it having a negative effect on you.
We can agree that state management is complex, no matter how it’s done. If you disagree, cool go build a database.
Of all the complexities around state management, the one squarely placed at the top for me is: time.
State is a variable you care about, that will change over time.
Signals and Hooks/Effects present two very different approaches to the problem.
They both require updating your mental model, and they both have specialised tooling.
Myself, I’ve never fully grokked observables/signals—particularly in relation to a UI. They shift complexity into a location that I think makes them harder to reason about.
I did take to the React approach with Components and hooks. And in my experience so did many others.
I disagree with the article saying all frameworks must have signals, and I appreciate the React core team holding their ground on that.
It’s healthy for the ecosystem to have frameworks built on different ideas, otherwise why build a new framework?
But React, if you added signals I think you would warp it’s entire foundational paradigm.
But it’s a powerful escape hatch like rust’s `unsafe` block. Rust can do amazing things to ensure safety of your program, but there’s still times where a human can do it better.
By signposting that, keeping it to limited blocks, and wrapping it up in a safe function you get the capability to do hard things, while exposing a safer API.
useEffect is similar, it lets you write the imperative synchronisation logic. For example if you need to interact with a DOM element that only has an imperative API, someone needs to do the work somewhere to wrap it in a declarative one. You can do that in a component with a useEffect hook, and then expose a declarative API.
You keep the clarity of declaring what you want to happen, and abstract the how to the effect handler.
React builds on functional reactive programming, something the FP world is known for[0]. I’m not saying it’s pure FP in the dogmatic sense, I just wanted to point out it’s closer to FP than the other paradigms.
Without the ability to interact with the outside world (side-effects), FP is not of much practical use. Not to say it’s bad or shouldn’t exist, just we need to add to it a bit to make it useful.
Why would we do that? Because the underlying ideas and principles provide a great foundation. Building on that to get FRP and algebraic effects, monads and so on, is very different to starting from OOP and brining FP ideas over.
React hooks are an interesting and tricky thing to put in a box, because they’re almost monads, almost thunks, almost algebraic effects. The interplay with fibers and components makes them hard to pin down, but they are much closer to functional than any other paradigm.
[0] https://wiki.haskell.org/Functional_Reactive_Programming
> But then they added hooks and useState and useEffect and so on, which made the functions impure. The problem with hooks is that they “hook into” React state and lifecycle features, which means it is modifying global state.
React components don’t update the dom every time they run, they update the fiber tree / virtual DOM.
Only in the commit phase is the DOM updated and side-effects are run.
My rough understanding is that:
Hooks, excepting useEffect, all run in the render phase.
UseState hooks store data in the component in the fiber tree, and capture a sequential list of updates when you call setState.
Algebraic effects can seem a bit odd at first, but it’s really like a generalised try/catch. Instead of storing state in the function itself, you reach out up the stack to the component and store it there. And every hook you call from your hook stores it there too.
It’s why call order is important, because it’s how they know which is which.
You don’t modify any global state though.
The actual component function needs to be able to be called multiple times in the render phase (which just updates the vdom), and must have the same output each time, if the inputs/props are the same.
Every now and then, the tender phase can be interrupted to run the commit phase, which synchronously brakes a snapshot of the vdom and applies all the needed updates to the outside world.
Perhaps it’s better to think of as
render: f(props) -> descriptionOfUI commit: apply(descriptionOfUI)
I would absolutely say components and hooks are functional, with algebraic effects. And that the resulting data struct from those components, is what’s used to produce side effects.
Even useEffect, is a description of a side effect to run, it doesn’t run in your hook, it runs on commit with all the other side effects.
There’s a ton of optimisations under the hood but that’s roughly my understanding of how it works.
A service small enough that a team or engineer can rewrite it in a cycle/sprint.
When it’s bigger than that, you have the compounding effects of other systems that interact with each other.
My point was that remote teams across countries, and in some cases timezones, can work. But replacing a team just becuase you can get cheaper engineers is destructive.
Build a remote team on purpose, or let your team move to locations that requires them to work remote.
The point I'm trying to make is focus on the team and what's best for them. If it's a new team why limit yourself to one country.
> Why in this case even have an _________ engineering team, ever?
The same reason some engineers command more renumeration than others (in the same market), you find good talent and want them on board.
But you suggested getting rid of the existing team in favour of a remote team in another country, because remote is more efficient. You lose more than you'll gain in the cost savings.
I'm fully on board with remote teams across the globe, especially when it means engineers can be on call while the sun is up.
Do it becuase it gives you access to talent, not because it's cheaper or remote is "efficient".
They are distinct things, and knowledge workers aren't the most fungible things.
A good team is a good team, regardless of how they communicate and collaborate. Replace one person in that team, and you have a different team.
Replacing a team just because they're remote is phenomenally destructive, just like the layoffs are.
> because why not? after all, remote is so efficient
That's not the point of remote. It is a preferred way of working for a significant portion of the industry.
You’re anxiety is likely because you don’t feel safe sharing the amount of progress you did or didn’t make. Unless your working on the most basic boring stuff, you’re not going to have the same rate of progress—at least not in a manner that is easily digestible in a standup.
I’ve seen this play out in so many teams over the last decade. A standup shouldn’t be a daily grilling on progress by higher-ups. If you’re team is full of adults and professionals, you don’t need hurrying along.
IMHO A standup over 15m means the team is too big, or you’re all sharing too much.
The most useful thing I’ve found standups do is surface blockers to the whole team, as there is often someone who can help that you might not expect.
If you need to go deep into anything, do it after the standup so others can leave.
BUT, “how are you?” is almost always a Phatic Expression[0], especially in cases where it could be considered a generic greeting.
Phatic Expressions seem to be more important to some cultures than others. For example, in Australia it’s such a fundamental greeting it often trips people up[2]. In this case the question is not a genuine or sincere inquiry into you current state, but rather a request to acknowledge the presence of each other.
In that sense, “how did you sleep” would be such a curve ball unless among friends I think it would cause secondhand embarrassment.
Tom Scott did a great 3 min video[1] on this exact thing.
[0] https://en.wikipedia.org/wiki/Phatic_expression [1] https://www.youtube.com/watch?v=eGnH0KAXhCw [2] https://www.unilodge.com.au/blog/g-day-mate-a-guide-to-aussi...
There’s other ways to get that model, but lambda makes it pretty easy.
Contrary to (seemingly) everyone I liked the Touch Bar MacBooks. I barely ever used the function row, but the software that came by default wasn’t the best. But pock.app was perfect. It put alt-tab visually on my keyboard.
My daily driver is now a Mac mini, and Touch Bar MacBooks time has passed.
The stream deck replaces that functionality really well.
If you don’t have one, but think it could be helpful—it’s probably worth a shot. There’s nothing like a dedicated for a specific action.
[0] https://cloud.google.com/blog/products/application-developme...
[1] https://slsa.dev (edit: fixed this link)
It’s one thing to read a theory, or watch an animation. But to be able to play with such a high fidelity analog is by far the best.
It’s like going from print debugging (measuring values in a circuit for example) to a full on debugger where you can stop the world, adjust something and see how _everything_ is affected.
Every citizen has a responsibility to submit a ballot (either valid, invalid, or covered in dicks).
And the state (or in our case an independent electoral commission) has a responsibility to collect a ballot from every voter. Which leads to making it as easy as possible for you to vote, with early voting, mail-in ballots and heaps of polling centres.
The ballot problem is easier than you’d think though. Make effective corruption untenable, by involving a lot of people in the process. Everyone who can gain from the outcome should have equal presence as observers.
And the tangibility of the ballot is crucial, it’s much harder to make 10,000 pieces of paper appear or disappear than to flip a bit.
It may have something to do with the fact that everyone has to vote, so you either learn how it works or try to dodge it. As in, it’s your responsibility as a citizen, not your right.
We also had the decade of Prime Ministers, where it was reasonably for you not to know who the current prime minster was. Amusingly the UK recently had a go at this as well, with about the same results.
Top line is, the drift to conservatism as we age no longer holds. The thread goes into more detail as it’s a bit nuanced.
But as one LNP strategist said dejectedly on national television during the LNP wipeout “you can make new conservatives if they have nothing to conserve”. If the status quo doesn’t serve the majority of voters why would they do anything but vote to change it.
https://twitter.com/jburnmurdoch/status/1608746369505976323?...
> In 1912, the former Electoral Act was amended to make enrolment compulsory. In 1924, to increase voter turnout and reduce party campaign expenditure, the Electoral Act was amended to make voting at federal elections compulsory.
Our election cycles are short, and there’s a small defined period where we talk about the election. After which we all get back to what we were doing. Contrast to some other countries, when the elections (even 4 years out) are always on the cards.
But to your point, even if they don’t know the issues, or care their vote is worth as much as mine. They have a responsibility to submit a vote. They don’t have to fill out the vote correctly, they can submit an informal or donkey vote.
They can partake in the classic Aussie tradition of drawing richly detailed genitalia on their ballot for the poll worker to admire.
What you do with your ballot is between you and that piece of paper.
But short of a few very limited circumstances you need to do you duty and make your voice heard. We’re not asking the informed, the educated, the wealthy, the elite or any other subset who they think should run things. We’re saying, your job as a citizen is to record your opinion on who should be running things (even if your opinion is “I don’t know”, you still need to record it).
And the key part here is that no one can take that away from you. The alternative is the game of voter suppression, making you think your vote isn’t wanted or won’t change things. Dropping you from electoral roles days before an election. Damaging the postal service to hamper mail in votes.
We’re one of a tiny number of countries that do it, and almost a century on I think it was a brilliant idea.
We don’t have a draft, and other than Jury duty (which you can reasonably get out of), voting is _the responsibility_ you have as a citizen.
[0] https://www.aec.gov.au/About_AEC/Publications/backgrounders/...