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.
Happy to give you my spin on this. I use Vue, but in personal projects I mix Vue and vanilla JS according to page complexity. On pages that need more state management and would benefit from orderly code (such as the Options API for Vue), I use Vue. For simpler, shallower functionality I use plain JS. I want to emphasize my callout of Vue's Options API, which provides for very nice and easy to read structure to the code. React and Vue's current Composition API, I feel, look like and encourage spaghetti code. But hey, people get better typescript coverage, I guess?
> 1. I see that the event interface specifies detail with `id` and `value` fields. What is the reason for using this? The underlying event already has a target, which will have the id and the value fields anyway. Are the widget's in this system so different that they have different id fields to the DOM elements?
This is something I rarely use in Vue anymore. I think back in the day, when Angular first emerged and pushed these sort of frameworks, there was a philosophy towards making components embed in code as if they were HTML native elements, and not needing to write JS around the event. If I remember correctly, providing a value field isn't asking it for the value of the event. It's specifying which value in memory should be set to the output of the event... But my memory is dodgy on that. It's confusing and I rarely see it used these days, but maybe that's reflective on the projects I've worked on.
> 2. There does not appear to be a field in the emitted event for the event sub-name (other than the custom name in the event structure itself). What if a component needs to emit something other than a "click" event? Ordinarily we'd get the event name from the event itself, so the handler knows whether it is being called on "focus", "click" "activate", etc. This information is lost with a custom event.
Can you expand on the usecase here? Ordinarily, at least in Vue, there's no need to know the name of the event currently being triggered. The component emits a "change" event (or whatever you call it) and the parent component, when setting up the child component, will specify some sort of 'on-change' attribute that listens for the 'change' event and says which function should be evoked as the callback to it. So basically, instead of having to write `document.getElementById('foo').on('change', respondToFoo)`, you simply write `on-change='respondtoFoo'` directly on the element in the HTML.
It's not the world's biggest win, but it does reduce the amount of code our eyes having sift through in reading the JS, and attaches the event details directly to the element(s) they relate to, which I've found to be more readable.
> 3. I'm still confused why you can't emit DOM elements; I mean, if you said "can't do two-way data binding" or something along the similar lines, it'd (maybe) make sense, but your response makes me think that you have not even considered it. I feel, maybe wrongly, that this library is both unnecessarily crippled and over-engineered - it targets spaghetti-as-a-pattern React, but not the hierarchical DOM?
You can, at least in Vue, but it's working against the grain. There's two reasons why:
1. Separation of presentation and state. These frameworks like to keep the HTML/DOM as simple presentation tools, and store logic and data separately. So when triggering events, we want to be emitting the important data as data, and not be concerned with the presentational layer from which that data may have originated.
2. Reusability of components. Emiting dom elements creates a more tightly coupled environment where there are a lot of expectations of the object being emitted (and little assurance as to what that object contains). By only exposing data and leaving the DOM element behind, it's easier for invoking components to use that data without having to hold expectations of the data structures being passed through.
These are all great points too! so in your opinion should I still keep the {id, value} encapsulated event system, it offers less control, but a minimal api shape for easy handling at the application level
Seems the opposite way round to me. We couldn't conclusively say that AGI is possible in principle until some physics (or rather biology) discovery explains how it would be possible. Until then, anything we engineer is an approximation as best.
A large part of it is that we maxed out a lot of how communication tech can impact daily life, at least in terms of communication, but economically and culturally got in the habit of looking for new and exciting improvements to daily life.
The 19th and 20th centuries saw a huge shift in communication. We went from snail mail to telegrams to radio to phones to television to internet on desktops to internet on every person wherever they are. Every 20-30 years some new tech made it easier, cheaper, and faster to get your message to an intended recipient. Each of these was a huge social shift in terms of interpersonal relationships, commerce, and diminishing cycle times, and we've grown to expect these booms and pivots.
But there isn't much of where to go past "can immediately send a message to anyone anywhere." It's effectively an endstate. We can no longer take existing communication services and innovate on them by merely offering that service using the new revolutionary tech. By tech sectors are still trying to recreate the past economic booms by pushing technologies that aren't as revolutionary or aren't as promising and hyping them up to get people thinking they're the next stage of the communication technology cycle.
> A large part of it is that we maxed out a lot of how communication tech can impact daily life, at least in terms of communication,
Perhaps for uneducated casual communications, lacking in critical analysis. The majority of what passes for "communications" are misunderstood, misstated, omit key critical aspects, and speak from an uninformed and unexamined position... the human race may "communicate" but does so very poorly, to the degree much of the human activity in our society is placeholder and good enough, while being in fact terrible and damaging.
My understanding is that this isn't Netflix's fault. They were king when they were the first major streaming service, and studios and networks were happy to get extra income from hosting their content on Netflix. But Netflix knew that any success it has would be mimicked by those same studios and networks, and that they would pull their own content to their own services as soon as they have them up and running, and so Netflix started making its own content in preparation for that day. And that bet paid off.
If the production quality of Netflix was close to HBO it would be nice. HBO has some absolute classics: The Wire, The Sopranos, GoT, White Lotus, The Last of Us, Alaskan Killer Bigfoot. Almost all bangers.
I'd argue Netflix productions started out almost as great as HBO, but quickly took a dive when they started pushing quantity over quality. Now finding a quality Netflix production is about once a year. Maybe that's the same rate as it use to be?
I agree that the quality went down, but I think it might be part of their strategy.
I think when they first started, they tried the HBO strategy of putting big money into big shows that try to win over broad audiences. But over time shifted to focusing on low budget shows that appeal to specific, smaller audiences. Which makes sense, if your goal isn't to have 70% of the total market as paying users but rather 90% of the market as paying users.
The problem is the bean counters running Netflix didn't want to pay the cast and crew their due, so their shows ended before the cast and crew could unionize, specifically so they couldn't unionize, leaving Netflix with no HBO-grade shows. Pennywise, pound foolish.
This is the way. As the studios decided they could make more money by becoming a streamer than they'd ever make with licensing deals with Netflix, they quit making those deals. As the deals would expire, Netflix would start removing them.
I always thought Netflix probably could have made licensing deals on their CDN. Lots of early streamers had issues (still have) with their CDN. Then again, the studios would probably want a clean break because they are so good about every thing they do (yes, that's sarcasm).
What's your take on the article saying that D.C.'s crime rate is at a 30 year low? Do you feel that things in big cities are so bad that an overreach of powers is justified in an attempt to fix it?
People in this thread are focusing on change in crime instead of the total rate of crime. The bottom line is that total crime in Washington DC is one of the highest among states and cities and is a clear outlier.
It's 19th of 83 (just barely making it inside the top quarter percentile) large population centers in the US, with 5,223 per 100,000 (~0.052 Per Capita) people Reported Incidents of Crime (all types) if using the adjusted[0] crime rate. If you use the data unadjusted for differences in population reporting data, it drops to 30th of 100. Via: https://en.wikipedia.org/wiki/List_of_United_States_cities_b... which is primarily sourced from FBI Crime Data Explorer https://cde.ucr.cjis.gov/LATEST/webapp/#/pages/downloads
Also worthy of note is FBI's Caution Against (Crime) Ranking:
> Each year when Crime in the United States is published, many entities—news media, tourism agencies, and other groups with an interest in crime in our Nation—use reported figures to compile rankings of cities and counties. These rankings, however, are merely a quick choice made by the data user; they provide no insight into the many variables that mold the crime in a particular town, city, county, state, region, or other jurisdiction. Consequently, these rankings lead to simplistic and/or incomplete analyses that often create misleading perceptions adversely affecting cities and counties, along with their residents.
0: "For the 2019 population estimates used in this table, the FBI computed individual rates of growth from one year to the next for every city/town and county using 2010 decennial population counts and 2011 through 2018 population estimates from the U.S. Census Bureau. Each agency’s rates of growth were averaged; that average was then applied and added to its 2018 Census population estimate to derive the agency’s 2019 population estimate"
I don't think I would use the word justified. I would say as someone that's lived in a high crime area that I'm in support of trying to reduce crime rates in areas with high crime rates. I don't think there's anything wrong with trying to reduce the crime. Trump lives in DC. He works and his employees work in the DC area. They want to take action to reduce crime.
I spent some of my life watching people on TV demanding to defund the police and all the other nonsense while they lived in low crime areas and didn't have to suffer from the policies they are promulgating on poor people. I wish trump would do this where I used to live to be honest.
That being said, I would like to mention a basic theory that I have. If you're poor, you're often forced to buy the cheapest options in terms of housing or used cars, etc. When a neighborhood improves and is "cleaned up", property values and rents rise. Suddenly the neighborhood you live in is becomes unaffordable for poor people.
Essentially, there is an economic trap: affordability often comes bundled with low quality, and improving quality often erases affordability when talking about things like used goods or housing. It's not necessarily clear that poor people are the recipient of the benefits of lower crime in inner cities, because without high crime rates, inner cities are prime top tier real estate.
> I don't think there's anything wrong with trying to reduce the crime.
This is the bailey of your motte and bailey argument. The motte is the implication that the National Guard should do this (or rather, shouldn't not do this). Regardless of it being good to try to reduce crime, this is a bad way to try to reduce crime.
Probably not without cooperation from municipal authorities which doesn't appear to be on the table.
There's no federal police force (other than maybe the coast guard and ICE neither of which really have jurisdiction here) so yeah the national guard is the least heavy alternative.
Thanks for sharing the link, I hadn't seen that before! Very serious allegations there.
> Calling in the guard is not overreach when a city is demanding it through inaction.
Is the city calling for protection, though? There's a big difference between police departments fabricating data and a need for intervention, whether through taking control of the city police or bringing in the national guard. What's the actual situation? Why is the Trump administration militarizing the city instead of running statistics to get actual crime numbers?
Downvoted as this comment feels like it's trying to be witty/upshowing the parent comment without actually engaging with it or offering anything of substance. If the comment was along the lines of "yes, but we've also done a lot of good, let's reflect on both", great. But that's not what it was. Instead it feels like a statement that's trying to argue with the parent comment despite the parent comment never saying we haven't done any good.
It wasn't a criticism of what they were saying (a point on which I agree with that poster), but whether the comment itself was contributing to the discussion or not. It was a very low-effort comment that offered no reflection on what the parent said, doesn't tie into the original post, and lacks depth towards its own point.
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.