I think they mean the "just" in "Do you just want to host repositories?", implying that it's never "just" hosting repositories, and the needs will continue to grow beyond what the simple solution offers.
I've had them all my life. I remember watching a some video a few years back that said they're more noticeable against a bright/white background, which checked out with my past experiences. And judging by your skiing comment, probably for yours as well!
I surprisingly had good results when I told the LLM to only communicate in ASCII memes. It did a fantastic job of summarizing the situation using relevant memes, and the humor was enough to keep things fresh. As silly as it sounds, it's worth trying when you're in that LLM burnout corner.
I think the parent comment is snark. They're saying that since many Firefox users are saying "Let me turn off AI features, please!" for features they don't want at all, and few to no Firefox users are saying "Let me turn on AI features!" because few to no Firefox users want AI features in the first place, Mozilla is making AI features opt-out to "satisfy" the "want" of turning off AI features.
I've seen my cats pull on a cord in order to reel in the toy at the end. I don't find that to be all too different from the cow orienting a scratcher. Should I?
Idk I guess that's really up for you to decide. My opinion is that behavior seems very uhhh instinctual? Like if they were eating something that was running away from them I'm sure they would employ a similar tactic/behavior. Thing far away from me I need it closer. The logical steps to use a tool that would have 0 instinctual context seems leaps and bounds more "complex". I'm no animal/evolutionary scientist, just my opinion. It very well could be!
For what it's worth, it happens to me about 5 times each summer. But I also welcome spiders as pest control, so it's not a surprise, and I forget all about it 5 seconds later.
I wouldn't call ChatGPT "brand recognition". People know the term ChatGPT, but I don't think they associate it with OpenAI or any company in particular, in the same way that people might associate Civic with Honda. Instead they'll associate it like they do the terms Bandaid, Kleenex, etc., as a catch-all term for LLM chat interfaces, regardless of who is providing the service. When OpenAI starts ads, I imagine people will start saying "oh, here's a ChatGPT without ads" and point to Claud or Gemini or whatever.
That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.
I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.
The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.
> my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air.
This was exactly how I felt. I building a Backbone app around the time React was released. It was only around 2600 lines of JS at the time but event handling and state management already felt like a tangled mess.
Porting it to React was a huge improvement even at that scale and really paid off over the next 5 years of development.
Agreed. You want to run htmx at a company where the business requirements change every month? Good luck but you’re going to end up rewriting it and have a much harder time hiring.
It depends a lot on the rate of change of the document.
Documents that experience little change don't need classes because their structure is reliable.
Documents that change often have unreliable structures, and will require frequent updates to the CSS rules to match structure changes. Using classes insulates the CSS from the document structure, mitigating the need to update CSS as the document evolves.
It also depend your development strategy. If using Vue components and writing the CSS in the same file as a dedicated, small-scoped components, it's practical to update the CSS references alongside the document changes. But when there's distance between the HTML and the CSS, or there are components in use who's structures may change unpredictably (such as from 3rd party libraries), classes provide a safer reference.
There's no need to have an ideology of using classes or not using classes. The practical approach is to assess the nature of your work, the rate of change of the documents, and to adopt practices built around those assessments.
The vast majority of the time, if my document structure changes, I want the presentation to change too. It may depend some on how complex the document structure is... I usually advocate for simpler structures. I agree that one should assess and adopt practices applicable to what they are building.
Seasoned software engineer with 11 years of web development and a proven success record using Ruby on Rails, Vue.js, React, and other frameworks. 10 years in startups, as small as 7 employees. Experienced mentor and coach to up-and-coming engineers, and champion of collaboration and efficient communication.
My ambitions are to build products I can be proud of. Software isn't an end, it's a means to an end, and the goal is hit our targets and win customers leveraging software. If you're looking for a level headed engineer who prioritizes a healthy and respectful work environment, a strong communication culture, and a deep understanding of the problems we're facing, reach out and say hi.
I am also open to work with technologies not listed above.
