MrPatan

I imagine writing code by hand without AI will be the assembler of our times.

Maybe the reasons to do it won't be "performance", but actually "maintainability" or "legibility".

Very similar to how you don't care about the machine code your high level code generates in 99% of the time, so you just make changes and replace it every time happily, but for that tight loop you want to keep it an assembler, I can imagine a world where, let's say for a bunch of simple UI components, you just ask the machine to do it for you and if tomorrow the requirements change a bit you ask again and throw away the old one, no big deal. But some gnarlier piece of business logic, harder to explain even to a human may need a more careful treatment, and to be easier to change by hand because that's where most of the changes happen, maybe.

Far superior... at making basic 90s UIs that nobody else wants today.

For better or worse, but the reality is nobody wants them anymore. Branding is a thing. When a client wanted something different you used to tell them "You can't have that" and they had to take it, because there was no other option.

The instant web enabled and normalized arbitrary UIs, "You can't have that" Delphi people simply went out of business. Because it turned out Delphi was far inferior at doing what people actually wanted.

Vox also doesn't make their money from whatever it is they preach, but from Vox getting clicks.

Maybe it turns out web and electron UIs took over the world because web technologies are just a better way of building UIs, and everybody who tries them in earnest realizes it.

How about "Every GUI toolkit out there trying to avoid using web tech is going to end up implementing a half-baked implementation of CSS", to coin a phrase.

Do unions make people richer, or being richer affords people to have more wealth-destroying unions?

Ima stop you right there and ask how you made the bullet points.

• Is it just a pasted character?

* Is it a markdown thing? * Is it?

> - how is the data fetch completion signalled to the component? > - how is the data piped into the component?

Both have the same answer. When you fetch the data you put it in the state, and then you render your components based only on that state.

If we're talking React the state makes it into the component through the props (pure UI component) or, if using Redux or similar, some kind of hook that triggers a rerender when the store changes (useSelector? My React-Redux is a bit rusty).

The point is not to worry anymore about change detection and rendering, because the framework takes care of it by being either fast enough that it can run on every change, or smart enough that it can tell when it's not necessary to re-render (caching, change detection).

Of course, this setup with redux etc makes a lot of sense for bigger apps with lots of state coming from different sources. I don't have any specific example I can point to, but any redux implementation examples could help. I use NgRx with Angular, and the docs are OK at explaining the flow of data.

Closed loop, here we come!

Wish us luck, the band for "normal, boring, incremental evolution" of the kind that we got with computers, the internet and mobile phones is looking kind of narrow.

This is how I know we're past "peak woke". The usual playbook of redefining words is cracking, and you lost control of your own word.

Nature is healing.

But.. that's what woke is now, if it ever was anything different. It's the cosplaying, the signaling. It's very funny that they made the song and dance literal song and dances.

Maybe you don't like that it be like it is, but it do.

Ah, which is exactly what the urban dictionary entry tells you. Funny.

Which to be fair is what most people reading that problem understood the first time. I wonder what would happen if you then tell gpt "No, it's the lion that can't be with the cabbage, not the goat, try again"

Good idea, wrong metric. What should fit in a screen is the concept. If you take a big, hairy, complicated thing and just chop it into several functions that fit on a screen you have gained nothing.

Sure:

- Click the link to show top scorers

- Initiate fetching the data

- (The view may change to indicate you're loading the top scorers, if you want, that's a different matter).

- Receive the data, the view changes to display the data

This is opposed to:

- Click the link to show top scorers

- View changes to show top scorers component. A component loads, or mounts, or inits, or does something which triggers a data fetch

- Receive the data, the view changes to display the data

Your app "knows" you need the data when the user clicks the link, no need to involve the view components into this.

This gives you the ability of adding a lot of complexity to how you fetch the data that is best handled outside a UI component (like caching, reusing it in other components, error handling, retrying, throtling, whatever), while saving you from a whole class of problems where a misunderstood component lifecycle has consequences for your data. Frameworks like React or Angular are going to try to help you by caching outputs, reusing components, dropping updates for the same frame, prerendering, preloading or anything really. If you fetch data when a component does any of that, suddenly you have to care about it and fully understand it. The abstraction leaked. If you treat the component as close to a pure function as you can, things become much simpler.

This applies to relatively big, relatively complicated apps, controlled by a single entity, where it pays off to prioritize simplicity.

Our vocal cords evolved for language, but the brain remained as rasa as a tabula can be.

Oooh, I see it now, bailouts to banks will be handed out based on ESG scores! GG

Don't fetch data from your views!

React enables v=f(s) by making DOM updates faster. v=f(s) was always a good idea, but before vDOM, replacing the HTML of the page on every little state change was too much for the browser.

- Now you describe your views as pure functions of their inputs and stop caring about them, React cares about them. You know that with the right s, the right v will follow.

- You need to care and manage your app's state carefully, yes, and everything goes in there. Fortunately, patterns and frameworks like Redux make it releatively straightforward to do this.

You can still make a mess, sure, and make mistakes, etc, of course. No silver bullet. But you can now deal with those two separately. If you start fetching data from your components directly you're back in jQuery hell with extra steps.

You don't do that.

Why would fetching data depend on whatever is being rendered?

You know what data you need or not need before rendering anything, or you will be in a world of pain.

This is why people use redux, keep state in a store and just do v=f(state).

Your app is the store, not the DOM.

It really makes things much simpler. The trick is to keep all the state in the store, including when things are loading, when some user interaction is happening but not yet complete, etc.

From your comment, it seems like there may be some problem if the user is interacting somehow, let's say in the middle of doing a drag and drop, and some data update comes in from a websocket, right? Well, if that's going to cause a problem for your render it's because apparently your data-updated function h needs to know if the user is doing a drag and drop. That should get put in the state when the user starts the interaction, and now h can know about it and react correctly.

Yes, it's more complicated than just have some component render based on the data you receive, but that's because it turned out that your app was more complex than you thought, it has more states you need to care about.

There's no magic wand, but this stuff works, just adds some boilerplate code but I don't mind.

Because you get in the mind of the test-giver and correctly predict the point they're trying to make and act accordingly. If you can't or won't, you fail. That's what school is about, after all.

When I saw Minecraft for the Nintendo Switch I bought it, thinking it'd be a solution for the MS login madness and my kid could play easily with it.

Wrong!

It's even worse! You still have to log in with some MS account, but on top it's buggy, slow, laggy, and crashed a few times on me generating the world. What a disaster.

There's two distinct camps talking past each other:

- Devs who make relatively small e-commerce-type websites, who loves tailwind, bootstrap, etc. Good defaults, fast throughput, maintenance is less important

- Devs who make relatively big web apps, who hates them. Everything ends up customized one way or another, maintenance is most of the work, tailwind and bootstrap end up only getting in the way.

The problem here is that this distinction is seldom make explicit, and here we are.

Were they the ones laid off this year?

One of my first programs calculated the odds of losing everything with a martingale strategy for a desired outcome and starting capital.

It needed so much capital to get to a safe enough point that it'd be better to just put the money in the bank (but thinking back, this was back before 0 interest rates, so there's another lesson there for you....)

Can't get around those pesky face to face interactions. Better to implant an equality-enforcing device under the skull to zap the brain every few seconds.

- New features help close sales.

- New features also add tech debt, complexity, cost, bugs, makes you slower, and will lose you some sales that way.

- At 0 features you really need to implement features instead of messing about with the bugs in the devops scripts.

- At e.g. Windows scale, maybe stop messing about with new features nobody asked for and fix some bugs, yes.

- In a Laffer-curve-like effect, there must be a point where it peaks and it's better to fix bugs than to implement a new feature.

- It's a very difficult to identify where you are in the curve.

- One of the measures is simple "do X, get money from this guy I have on the phone"

- The other measure is fuzzy, lags, is subjective, can't be traced to a particular feature.

Good luck!

How about more complex prompts?

If "print 'hello world'" is not copyrightable does that imply that more complex programs are also not copyrightable?

> "elephant with blue skin" or any other prompt

I don't buy it. The space of prompts is pretty big just at the length of a few lines. You'll find guides and how-tos on how to write the prompts you want, seems quite the complex and creative endeavour to me!

But maybe at some point tech X has improved enough that it can make a difference, and you would never know if those ego-driven founders didn't try.

I think I get it. You really don't want to shift your mind to the browser. Your mind is in the server, you know what's up in there, and distributed systems are complicated, so one of the ends should be made as dumb as possible. I get it.

Except, guess where the mind of the user is? On the other side of the browser. Embrace the browser, server people, it's closer to the user!

Actual news: Yahoo not dead yet

Yes! I can't wait for food production and distribution to be put in the hands of government officials. Access to food is going to be equalized so hard!

The market has been taking care of it for too long, we're getting too fat, we need a few decades of food controlled by the police to get back into shape.