isochronous

> Some people own a lot of guns and knowing exactly where they are at all times is just not feasible.

If that's the case, they need to own fewer guns. I cannot think of many things more important to keep track of at all times than where one's guns are.

Considering Japanese culture, I'm not surprised. This is what happens when you have super-conservative social values backed up by a strong pressure to conform. Few people are willing to take a risk or convey honest feelings, and both of those things are inherent in a romantic relationship.

This kind of thing is exactly why my old boss went and created his own minimalist framework built around using native code: http://www.domxjs.com. Its explicit purpose is to allow developers to learn and utilize the platform, rather than learning a bunch of libraries.

No, but I might just dip in there for lunch. Why does it have to be taking a client out for fine dining?

One of the first things that made me realize this was watching an old interview with Steve Jobs. He'd be asked a question, and would just sit there, totally silent, for maybe 10-15 seconds, and it was obvious that he was pondering the question in order to give a well thought-out answer. Since seeing that, I've made more of an effort to actually ponder questions, rather than trying to give the quickest answer I can, and people seem to response well to doing that.

Jesus, dude, OSS is not some kind of holy grail that renders it immune from all criticism, much less valid criticism.

1. I agree about the "you're free not to use it" line, but I frequently find that documentation can seem comprehensive when you're evaluating something, but as soon as you get deeper into the weeds, that's when the shortcomings reveal themselves. And telling someone to "help them" when they themselves are looking for documentation to get help? That's just laughable. I sure as heck wouldn't want someone who can't get my product to work to be submitting documentation PRs.

2. This is just snide. Refusing to help someone because they're expressing frustration is simply spiteful. You have no more information than the rest of us about what was actually asked, so implying that the author "had it coming" seems uncalled for.

3. Then you're not very familiar with the OSS economy, are you? There are frequently paid support plans available for major OSS projects.

Yeah, there are a lot of "popular views" that are complete and utter nonsense

That's because twitter actually has content moderation policies in place that they do their best to apply. They're obviously not perfect, but again, the whole reason the app store banned parler was that they had no workable moderation plan in place. Twitter does.

Are you familiar with how publicly traded corporations work?

"People claim Twitter can't possibly moderate content at scale, except that Twitter makes money at that same scale."

I'm sorry, but is that supposed to be a logical argument? Because it doesn't actually make any sense. Twitter is a platform that allows pretty much anyone with an internet connection to post content. There were, on average, 500 million tweets posted per day last year.

So on one side you have the set of potential content creators, churning out half a billion tweets per day, and that number will almost certainly continue to steadily increase. So, as a company with a set amount of income, and who is beholden to its shareholders, what's your plan to moderate 500 million tweets per day while still turning a reasonable profit?

Truly a disingenuous argument.

Parler didn't get TOS'd because they had things fall through their moderation process; they got TOS'd because they did not have a workable moderation process in place, period. Twitter obviously does make mistakes - both AIs and humans are fallible - but they have about as good a moderation process in place as it's possible to have with the amount of message traffic they process.

Also, I'd like to point out that the only evidence WE'VE seen of this so far are a few claims made in a lawsuit.

There's more than one explanation as to why "mainstream media" might not run a story. The NY Post isn't exactly known as a bastion of credible journalism. That's why they ran the Hunter Biden laptop story when everyone else passed because they couldn't verify it.

See, and this is where I (and I'm guessing you) might beg to differ. I'm a web developer, so the vast majority of my time is spent working in JavaScript. Our team has been working in ES6 for the past ~2 years. Our lead developer just LOVES him some ES6 - destructuring, aliasing, lambdas, you name it, and he's all-in.

Me, though? Well, let's just put it like this: when we find some framework-level bug that's written in "clever" ES6 syntax, our first step in debugging is almost ALWAYS to rewrite the given function traditionally, without any of the ES6 shorthand. And the reason we do that is because reading and debugging a whole stack of anonymous lambda calls is a PAIN IN THE ASS. Or figuring out where a certain variable is coming from when someone uses overly-complex destructuring syntax to magically pull a value from deep within a nested object.

I mean, don't get me wrong, I do like and use almost all of the modern ES6 niceties, but I also feel like it's much more difficult to parse and understand code compared to what we were all writing a few years back. People will, I'm sure, be arguing about what constitutes "good code" for decades to come, but to me, when working in an evolving codebase, especially with other people, plain ol' human readability is paramount. If people can't figure out what your code is doing without throwing in a breakpoint and stepping through line-by-line, you've failed at writing good code. And this will be my opinion right up until the day humans stop writing code by hand.

Google is terrific at answering random questions compared to Siri, though. And I use my Alexa products for shopping lists. Not too long ago they added a feature where it tries to figure out what section of the grocery store things are in, and then it groups items on your shopping list into those grocery store sections. It's pretty nice and a simple "alexa, add <whatever> to my shopping list" is pretty bulletproof.

Once you start playing the song once, you can generally say "repeat on" and it'll loop the song. YMMV depending on where the song is coming from.

Not in the USA, they don't. Not as long as the cops in question don't know for a FACT that their behavior violates established law - even if it DOES violate established law, they aren't held accountable unless a previous court case established precedent under almost the EXACT SAME CIRCUMSTANCES. As you might expect, finding a previous case in which the exact same circumstances applied is not an easy thing to do. Read up on qualified immunity: https://www.lawfareblog.com/what-qualified-immunity-and-what...

Good to know developers have their own nonsensical conspiracy theories.

There's a big difference between job interviews and school interviews/oral exams, though.

Because then you don't have to pass a huge framework library down the wire along with all of your custom code? Look at it the other way, if you don't get a big advantage over web components by using React, Svelte, etc then why would you use them? Web components are natively supported by modern browsers. Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments.

I guess maybe you had a different experience than I did, because I never had web components "pushed" at me in any way. It was always a technology I was keeping my eye on but was hesitant to invest in until the browser support was there, and now that the browser support arrived I've seen a grand total of ONE web-component-focused talk at the web dev conferences I've attended, and that one was given by our project lead.

I've had an iPhone since Google Assistant really became a "thing," but I use my Google Home all the time to get answers to questions that I'm surprised it's able to parse, like "what was the name of the dog in <movie title>", or "what song has the lyrics <insert lyrics here>". In fact, I'd say that 9 times out of 10 it gives me a pretty decent answer to any question I ask it. Of course, that may be because I'm familiar enough with the limits of technology to know what types of questions not to ask.

As far as reminders and stuff go I'd recommend just trying that sometime when you're not driving just to see what the workflow is like. Sometimes you just have to set something up the first time you use a feature (like picking which calendar you want reminders saved in) and then from that point on it's transparent.

Yes, thank you. I don't know why "they have dependencies" is a valid criticism. Literally any complex thing where the developer didn't write 100% of the code has dependencies. Most of the dependencies for the web components we use at work are... other web components, which is EXACTLY THE POINT of web components: reusability, portability, encapsulation.

I'll agree with a few of her points, but as far as this point goes, I have to wonder what components she's trying to use here. And if she wants to see the full markup of the shop demo, all she has to do is use "inspect element" on it rather than "view source."

Lit-HTML is a templating system that's baked into Lit-Element, which is basically the successor to the Polymer framework. It simply uses JS template strings, with a few little niceties in the binding syntax to allow for things like setting properties rather than attributes, adding/removing boolean attributes, and defining event handlers inline. It lacks two-way data binding, but we use "data" elements as a centralized data store. That store provides a master state object that's passed down to every component on the page - though frequently it's just a sub-tree of state that gets passed down. If a component receives some input and needs to update its state, it fires off an event with the updated value, which has a corresponding handler in the data element. That handler taps into a functional pipeline we've built to handle function composition, passes the information down the appropriate pipeline, and the master state is updated appropriately. At that point the data element fires a "state-changed" even that basically everything listens for, and whoever cares can then update their own little bit of state from the master store (typically one line of code).

I mean, we're using web components to build large web apps at my workplace, and in my experience 95% of the dependencies of web components are... other web components. Which makes sense for anything more complex than a simple button. The whole point of web components is to create portable, reusable code that can be encapsulated within an HTML tag, so if I'm writing an app that needs buttons, inputs, date pickers, etc, obviously I'm going to import components for those things where native controls don't meet my needs. I don't understand why "it has dependencies" is a valid criticism.

Please learn how to properly quote things, all of your replies are showing up as part of what you quoted

Weird, because we're using web components at my workplace to build complex web applications. We use Lit-Element as a base class and have come up with a top-down functional state pattern for data that removes the need for two-way binding. If a sub-component needs to update its state due to DOM interaction, it just fires off an event with info about that DOM interaction, and the data store for that component (another web component) does the necessary state modification, then fires off a "state-changed" event that tells all associated components to update their state from the "master" store (one line of code). All of the data elements use pure functions to do state modification, so doing complex operations is simply a matter of composing the appropriate functions. I've not used react myself other than playing with a few demos, but another developer on my team says the pattern is very similar to how react stores work, and the core modules that drive it are like 100 lines of code.

This is one incredible journey back into my teenage years. Thanks so much to the developer and the person who shared it here!

TripX was pretty, but Geiss, Milkdrop, and Gforce were my favorites, if only because of the insane number of add-on visualization presets. What was always ironic to me was that most of the presets by the actual developer were pretty garbage.

The reason IS obvious: It's called "feature bloat." That being said, unless you install a bunch of extensions, VS Code is still pretty snappy, at least on all of my computers.

Oh my god, I haven't thought about Sonique in decades!