Readit NewsOthers have already commented on this, but do you work in tech? IME getting interviewed by directors and even VPs in t-shirts is the norm. I’ve worn jeans to work my whole career. If anything, I think people in tech have a strong prejudice against people in suits (ie “obviously this person isn’t a real software engineer, they’re wearing a suit.”)
Anyway, probably not good career advice to wear a suit unless dress codes at tech companies are suddenly subject to drastic changes.
I always get a positive response.
We tried other names, but we found collisions with essentially all of them. =/ We ended up picking a "least bad", and actually talked to a couple of folks familiar with the old usage to see if it was a worse collision than we realized. They weren't delighted but generally shrugged. So here we are. =/
It's definitely not perfect, but I think it's much more searchable than "C" or some other choices. Ultimately, I think its at least not bad enough to matter compared to the actual project.
I understand that AI stuff now is mainly Python. But is it possible to connect Rails with some Python program/service, is this one of the purpose of microservices?
I do know Ruby well though.
I'm going to cheat and get a list from AI:
1. Difficulty in maintaining and debugging: When state is scattered throughout the DOM, it becomes challenging to track and manage, leading to code that is hard to maintain and debug.
2. Performance issues: Frequently querying the DOM for state information can be more expensive and slower compared to accessing data stored in JavaScript objects or dedicated state management solutions.
3. Lack of a single source of truth: Storing state in the DOM makes it difficult to establish a centralized, authoritative source for application data, which can lead to inconsistencies and errors.
4. Synchronization problems: Keeping DOM elements in sync with a mutable list of data can quickly become complex, especially when dealing with dynamic lists or elements without unique identifiers.
5. State persistence issues: DOM-based state is vulnerable to loss during page refreshes or navigation, which can lead to poor user experiences, especially in single-page applications.
6. Scalability challenges: As applications grow, managing state in the DOM becomes increasingly cumbersome and can result in performance bottlenecks.
7. Difficulty in implementing advanced features: Techniques like time-travel debugging, state snapshots, and easy hydration become more challenging or impossible when state is primarily stored in the DOM.
8. Increased complexity in component communication: Relying on DOM for state can complicate the process of sharing data between components, potentially leading to prop drilling or other anti-patterns.
1. There isn't a good way to test it. There is nothing in the docs about how to test it.
2. Keeping state in the DOM is dangerous
3. Messaging between Stimulus controllers is painful
4. They disconnect parameters from functions. The functions have to scan through the DOM to find what they need which I think is fundamentally weird
5. Reusability is rare
6. It doesn't try to play nice with the larger JavaScript ecosystem.
I personally prefer Vue.
The text and programs are from a book published in the 80's. It was a series of 10 books I think.