It sounds like that relationship was not supposed to be salvaged to begin with. ChatGPT perhaps prolonged your friend's suffering, who ended up moving on in the end. Perhaps unnecessarily delayed.
My knee-jerk reaction is that outsourcing thinking and writing to an LLM is a defeat of massive proportions, a loss of authenticity in an increasingly less authentic world.
On the other hand, before LLMs came along, didn't we ask a friend or colleague for their opinion on an email we were about to write to our boss about an important professional or personal matter?
I have been asked several times to give advice on the content and tone of emails or messages that some of my friends were about to send. On some occasions, I have written emails on their behalf.
Is it really any different to ask an LLM instead of me? Do I have a better understanding of the situation, the tone, the words, or the content to use?
Firstly, when you ask a friend or colleague you're asking a favour that you know will take them some time and effort. So you save it for the important stuff, and the rest of the time you keep putting in the effort yourself. With an LLM it's much easier to lean on the assistance more frequently.
Secondly, I think when a friend is giving advice the responses are more likely to be advice, i.e. more often generalities like "you should emphasize this bit of your resume more strongly" or point fixes to grammar errors, partly because that's less effort and partly because "let me just rewrite this whole thing the way I would have written it" can come across as a bit rude if it wasn't explicitly asked for. Obviously you can prompt the LLM to only provide critique at that level, but it's also really easy to just let it do a lot more of the work.
But if you know you're prone to getting into conflicts in email, an LLM powered filter on outgoing email that flagged up "hey, you're probably going to regret sending that" mails before they went out the door seems like it might be a helpful tool.
"Firstly, when you ask a friend or colleague you're asking a favour that you know will take them some time and effort. So you save it for the important stuff, and the rest of the time you keep putting in the effort yourself. With an LLM it's much easier to lean on the assistance more frequently."
- I find this a point in favor of LLM and not a flaw. It is a philosophical stance, one for which what does not require effort or time is intrinsically not valuable (see using GLP peptides vs sucking it up for losing weight). Sure, it requires effort and dedication to clean your house, but given the means (money), wouldn't you prefer to have someone else clean your place?
"Secondly, I think when a friend is giving advice the responses are more likely to be advice"
- You can ask an LLM for advice instead of writing directly and without further reflection on the writing provided by the model.
Here I find parallels with therapy, which in its modern version, does not provide answers, but questions, means of investigation, and tools to better deal with the problems of our lives.
But if you ask people who go to therapy, the vast majority of them would much prefer to receive direct guidance (“Do this/don't do that”).
In the cases in which I wrote a message or email on behalf of someone else, I was asked to do it: can you write it for me, please? I even had to write recommendation letters for myself--I was asked to do that by my PhD supervisor.
I wasn't arguing that getting LLMs to do this is necessarily bad -- I just think it really is different from having in the past been able to ask other humans for help, and so that past experience isn't a reliable guide to whether we might find we have problems with unexpected effects of this new technology.
If you are concerned about possible harms in "outsourcing thinking and writing" (whether to an LLM or another human) then I think that the frequency and completeness with which you do that outsourcing matters a lot.
It can become an indispensable asset over time, or a tool that can be used at certain times to solve, for example, mundane problems that we have always found annoying and that we can now outsource, or a coaching companion that can help us understand something we did not understand before. Since humans are naturally lazy, most will default to the first option.
It's a bit like the evolution of driving. Today, only a small percentage of people are able to describe how an internal combustion engine works (<1%?), something that was essential in the early decades after the invention of the car. But I don't think that those who don't understand how an engine works feel that their driving experience is limited in any way.
Certainly, thinking and reasoning are universal tools, and it could be that in the near future we will find ourselves dumber than we were before, unable to do things that were once natural and intuitive.
But LLMs are here to stay, they will improve over time, and it may well be that in a few decades, the human experience will undergo a downgrade (or an upgrade?) and consist mainly of watching short videos, eating foods that are engineered to stimulate our dopamine receptors, and living a predominantly hedonistic life, devoid of meaning and responsibility. Or perhaps I am describing the average human experience of today.
I used custom elements extensively in 2014 when support was not as widespread. I think it's a beautiful, elegant solution and I'm still a little bit bitter that React became as big as it was. Now everything "has" to be a SPA because developers want to use React, whereas most users would actually be better served with good 'ol HTML with some custom elements where needed.
> Now everything "has" to be a SPA because developers want to use React
Have you followed anything in the last 5 years? Outside of bootcamp students, this has been on the decline for a while… in some cases overcorrecting for where a SPA might make more sense.
I’ve been getting into SSR with JSX as a template engine using kita. You still get full typescript analysis and composability. It beats any other SSR web templating system I’ve used.
I agree the need for everything to be a react app by default has gotten out of control. But I think if you’re a startup with unknown future needs it’s hard to ignore the flexibility and power of something like react. If you know you’re just making a CRUD app and good old fashioned form POSTs will do then it’s beautiful to have that speed and the lightweight pages.
You do the crud app and then they want: just make this to edit inline. You do some Ajax api Call with a tiny js. Then you need more and more. Then you have a mess and you’d be better with react. I still can’t find a project id be better of without react. When I tried without it bite me very quickly.
They are too high level, preventing many low-level optimizations.
They are too low-level, preventing you from using/implementing them without going into the details of how they actually work.
They break many platform assumptions and conventions, creating no end of problems both for end users and implementers, and needing dozens of new specifications to fix glaring holes that exist only because web components exist. All of those specs? A heavy dousing of Javascript of course.
Even the people who push them heavily cannot agree on what they are good is and what the goal of them is
What makes custom elements good is inrerop. I can use them in react, Vue, angular, svelte, solid, or just plain ol' server rendered html. I can switch out the internals entirely for a WC lib, or not, with nobody knowing or caring.
This is a unique advantage to WCs. And it's such a compelling advantage that it makes almost all the downsides tolerable. At least if you are in a position where your component might be used in many places. Design Systems are a good example. The consumer can be any app, built on any technology.
And there are plenty of downsides. But they are mostly felt by the author, not the consumer. Similar to how TS libs can be very complex to author because of type level gymnastics, but when done right are easy to consume.
(I do not push them heavily, but I can appreciate strengths and weaknesses of all tools)
They don't need to be leaf components to still have this strength. I've worked with design systems which have a <my-layout> component near the root which defines sidebar, header etc slots. This still works nicely with react, Vue etc
But I agree they tend to be better suited as "leafier" components
Honestly I couldn't care less what the original proposal said! Things evolve. Utility is found in unforeseen places. That's the nature of ~everything. Personally I'm not a fan of that kind of component but not aligning with some original, preordained vision is a minor nit
Not even sure what argument you're making here. A web component bundles one or more of: markup, styles, functionality. You can't do that with just html such that it's easily consumable in all the ways I mentioned.
As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator of those into native HTML/JS, as if it would bring us closer to having native Vue/React. Which of course never happened, partly because HTML is fundamentally incapable of having anything but string attribute values, and partly because reactive DOM is basically a hard problem that can't or maybe shouldn't be solved natively.
> As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator
First web components proposal is from 2011. First specs are from 2011-2013.
React was introduced in 2013 and didn't gain much traction until at least a year later.
Right, and that proposal was withdrawn, and a new one, the one we have now, was proposed based on lessons learned from (or inspired by?) React/Vue. Maybe there was a common ancestor or general consensus about the techniques floating around in the community before proposal #1, but it was clearly inferior and flawed, and #2 was the one I'm talking about.
Web Components are not a single proposal. Their core originally is three specs:
- Custom Elements
- Shadow DOM
- HTML Templates
Custom Elements v0 was implemented by Google, but the API changed (especially with ES6 classes making their way into all major browsers), and now everyone's on Custom Elements v1. There are very little fundamental changes between the two beyond that.
Shadow DOM is there, is an endless source of bizarre problems that literally no one has, and in the end will need ~30 different specs and changes to the browser to fix those problems (for a sample see https://w3c.github.io/webcomponents-cg/2022.html)
HTML Templates were only implemented in Firefox, and were removed in favor of JavaScript-only HTML Modules which were eventually scrapped in favor of on-off additions to JavaScript imports (see e.g. "CSS Module scripts" https://web.dev/articles/css-module-scripts)
> was proposed based on lessons learned from (or inspired by?) React/Vue.
Lol. The world wishes it were so. There rarely was such an insular group of people developing major web standards as those developing web components. They were hostile to any outside input or influence and listened to no voices, and looked at no implementations but their own.
I traveled often between Jakarta and Japan in 2018, 2019 and 2020. The real breath of fresh air for me was literally the fresh air back in Japan. After running around for a week through Jakarta, I would inevitably develop a deep cough and a clogged nose. That said, the people, the food, and as someone else pointed out the nightlife is amazing.
Somebody I know had asthma while she lived in Jakarta. It went away when she moved to Europe. I really liked Jakarta, but the air quality is one of the reasons why I won't go back again.
An established founder makes claims X is the new frontier. X receives hundreds of millions in funding. Other less established founders claim they are working on X too. VCs suffering from terminal FOMO pump billions more into X. X becomes the next frontier. The previous frontiers are promptly forgotten about.
I think it's a bit confusing when it comes to terminology, this seems more graphics focused while I suspect that a 10 year plan as mentioned by YLC probably revolves around re-architecting AI systems to be less reliant on LLM style nets/refinements and better understand the world in a way that isn't as prone to hallucinations.
Sidenote, but I love that in a GitHub issue discussing banning the use of LLMs, the GitHub interface asks if there's anything I'd like to fix with CoPilot.
I love the argument that Managed DBs cost a lot, but they're supposedly safer. Meanwhile people can't figure out the IAM permission models so they give the entire world access with root:root.
reply