React, the framework, is separate from react-dom, the browser rendering library. Most people think of those two as one thing because they're the most popular combo.
But there are many different rendering libraries you can use with React, including Ink, which is designed for building CLI TUIs..
Anyone that knows a bit about terminals would already know that using React is not a good solution for TUI. Terminal rendering is done as a stream of characters which includes both the text and how it displays, which can also alter previously rendered texts. Diffing that is nonsense.
You’re not diffing that, though. The app keeps a virtual representation of the UI state in a tree structure that it diffs on, then serializes that into a formatted string to draw to the out put stream. It’s not about limiting the amount of characters redrawn (that would indeed be nonsense), but handling separate output regions effectively.
There are of course exceptions to every rule, and I'm sure some companies have been successful in building their own in-house tooling.
At the end of the day these decisions are all series of trade-offs, and the trick is understanding your requirements and capabilities well enough to make the right trade-offs.
The B2B startup motto of "where someone is using Excel to do something other than accounting, there's a startup waiting to happen" has been shockingly resilient over the decades, and I suspect will continue to be.
We need a new one: "Where someone is using a vibe-coded internal tool made by the creative department that keeps needing bug fixes, there's a start up waiting to happen."
And don't forget the safety in getting to say "our systems are down because of [X TRUSTED SOFTWARE FROM LARGE KNOWN BRAND] and we're just waiting for them to fix it" instead of "our shitty internal tooling is broken and no one knows how to fix it"
This feels like it goes along the lines of "people's vibe code is cluttering up our PR's, people still need to review" -- it misses the boat: models are already capable of getting you up to speed on how the code is organized and works, in as much as you want to or need to be up to speed. They are already helping me cut down review time because I don't need to aimlessly hop around, I have a good starting point that I can scrutinize and dialogue about. Same thing here: employee leaves company -- about 3 years ago you would be right, now the company is left with an unmaintainable mess of legacy code and tech debt. TODAY this just doesn't matter. No one really needs to read that code too closely, it's already easy for agents to digest and explain and modify.
Doing this today, in production, with full trust, is clearly not wise, but the writing is clearly on the wall that this is going to be the norm more and more over the coming years. The times they are a-changin.
Can you be clear what you mean? What are you saying has not worked once?
And "it will be the norm" is a clear corollary of, absent any significant and unforeseen roadblock, even with the current highly imperfect agentic sausage-making factories we have today, what capabilities will be in like 6-12 months time.
When the effectiveness of vibe coding an internal workflow was measured, only 5% of efforts worked. That's pretty rare and bad. And those are the early adopters who tend to be more adaptable and effective with new technology. That's a big part of why people don't believe the (your) hype. Its great at simple things with a low cost of failure. Problem is, its rare to pay a good wage for simple things with a low cost of failure. Also, writing new code isn't a big part of most engineers jobs. To put it more simply, vibe coding optimizes the wrong things about engineering.
I think you can avoid the pain by thoughtfully designing it to avoid lock-in. You want it so that if needed, a dev can vibe-code a migration tool to the equivalent SaaS offering. AI lowers the barrier for creating these in-house replacements, but it also lowers the barrier for scrapping them too.
The thing about lower barriers is that it makes it easier for e.g. Salesforce to raise the level of expectations. And that's the moving target. New employees will come from elsewhere and wonder how a company is operating using tools from 2020 when X, Y, Z are becoming industry standard.
The key here is that the moving target will _never_ be "what can 1-2 people vibe code without any expectation of being the best at what it does?"
(Also: training people on bespoke tools takes much longer than training on configurations of standard tools. Imagine if you had to learn a new source control system at every job, like in the '80s.)
4. Employee continue in the company and request help (or the managers see the need):
4.1 They hire more, but if all are vibe-coders too
4.1.1 The product gets more complicated (no more complex, that good developers can manage!)
4.1.2 Bugs creep in, feature request pile up.
4.1.3 People start to get desperate, not worries! now:
4.1.3.1 Somebody vibe-code a new alternative that solves
the immediate problem
4.1.3.2 Bugs creep in, feature request pile up.
4.1.3.3 Needs to sync with the other tools
4.1.3.3.1 Somebody vibe-code the sync that solves the immediate problem
(the saga continue)
In parallel:
4.2 Eventually is obvious that need external help
THEN:
4.2.1 They ask for consultors for build tool, of course, from a company that has embraced the IA!
4.2.2 They build new shinny tool!
4.2.3 Bugs creep in, feature request pile up.
4.2.4 Needs to sync with the other tools
....
AND:
4.3.1 They ask for consultors, to teach them what to do, of course, from a company that has embraced the IA!
4.3.2 New shinny theory of how do the thing with IA is now being implemented!
4.3.3 It require a rewrite of not only past solutions but, a change of how the company behave!
4.3.3.1 Needs to sync with the other tools
.......
4.3.4 And it spark beautiful office/political debates around some philosophical whatever that also trigger changes in the structure, hiring or whatever, alienating the people that has been working there, that after months, has started getting the handle of it!
4.3.5 Employees either leaves the company or moves on to another project.
4.3.6 New employees arrive, with a wild new IA tool and different vibes that vibe-coding!
... the saga continues
5. Is now clear that it need to buy a product form a well stablished software provider
the people that USE the software the most are not the people BUYING the software. it’s why all enterprise software has trash UX.
do you think i as a software engineer like using Jira? Outlook? etc? Heck even the trendy stuff is broken. Anthropic took took 6 months to fix a flickering claude code. -_-
Not relevant point though. I was answering to this "I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years", I wasn't arguing that such apps don't make money.
> In my city, apartment buildings used to require steel structures and lawmakers relaxed the requirement so they went back to wood because it’s cheaper. Now the new ones look great but they’re burning down and falling apart at higher rates than before.
It certainly wasn't intended as a straw man argument. I was speaking to the broader issue that any data that's gathered anywhere can be used against people. Even if it seems like there are good reasons to store it.
I think you may have missed that I was replying specifically to this part of a parent comment and agreeting with it:
> We are really seeing the fears of data collection from the 2000s and 2010s come to fruition
Reasonable countries have gun control laws.
The list goes on of things that need to be restricted or legislated to add limits.
Is this a serious question?
reply