> Not what happend to Office.com or what you think about their products.
I don't understand this point. Are you suggesting that less people being happy with their product and thus less people buying it is not related to the valuation of the company and their stock?
> Also, you and me are not the customers. Govs and corporations are.
Huh?
I get you're trying to make a point about the bottom line, but that doesn't mean the bottom line is impervious to bad product decisions or that the people who are paying for their products are not in fact their customers.
Less people buying don't count much compared to the volumes bought by govs and corps.
Also, windows and office bought by govs and corps isn't the same edition as the one bought (usually) by home users, so they're not as dissatisfied by what they bought compared to home users. In fact, some of the features such as automatic unavoidable updates, are demanded by their usual clients.
Parent is pointing at the fact that the relationship between our perception of MS products and their financial success is highly inelastic. The bottom line isn't impervious to bad product decisions, but there can be a large number of user hostile decisions that PMs push through that still increase revenue on the whole even at the cost of user satisfaction, before they move past the optimal point in the payoff curve.
So React, the most popular front-end library and used my hundreds of thousands of successful apps, is the ridiculous electric screwdriver? See how weird that sounds and makes it obvious you guys can't give an honest assessment?
React is a javascript library. Javascript needs its own runtime. Why not just write stuff in native windows controls and save having to run an entire javascript runtime for no reason?
Using an entire javascript runtime and framework to make your OS start menu is using a ridiculous overpowered electric screwdriver that strips heads. Using native windows controls is using a proper manual screwdriver that just works
Only someone who has not tried to write stuff in "native windows" would ask this question. If you want a real answer, go try and develop a Windows native application real quick. I'll wait...
I would hope that the windows developers who are working on the windows shell would know how to write a windows native application in C. If it's that bad, they should improve the API, not just write it all in react instead
I learned Win32 programming from the Petzold book circa 1993.
Pretty much everything in there still works, if I type it in and compile it with the current Visual C/C++ toolchain. I might need to get rid of a few MOVEABLE and DISCARDABLE tags here and there, I suppose.
I have no issue with user-facing applications doing whatever they want, electron apps bundle an entire chromium to do their thing, but there's a win32 and win64 api in C for a reason, to make OS level stuff fast
Its popularity or success in other apps has nothing to with the windows situation.
Other apps are successful despite being slow and bloated, since performance isn’t a primary concern of users. In contrast it’s critical for OS internals like the start menu, so a javascript runtime and framework is just the wrong tool for the job.
"Shit tastes great! Millions of flies can't be wrong!" ;)
React only makes sense as a layer on top of the browser DOM, because the DOM itself cannot be fixed without rewriting it from scratch, so making it usable for non-trivial UI needs to happen in the 'framework layer'.
But without the DOM as the thing that needs fixing and the restrictions of the single-threaded browser-event-loop, the React programming model simply doesn't make a lot of sense. Using the "React-paradigm" outside the browser (e.g. SwiftUI, React Native) is pure cargo-culting, it only makes sense for onboarding web-devs who are already familar with React - but makes it harder to create UIs for anybody else.
The actual problem in the context of Win11 is of course that Microsoft doesn't have any sort of longterm strategy for Windows system APIs (not just UI frameworks). The only long-term-stable API is Win32.
Seen in the context of the thread, with the both of you never addressing the actual problem at hand but instead reflexively and vigorously defending React against an alleged attack, I'm sorry to say this reads like an admission.
> that you don’t need templating, compiler, or anything special to write react, “it’s just JS”
This is still true. I don't currently use any of those things. And the existance of a compiler does imply you can't write Javascript. Totally different concepts. Also, pretty sure they had compiler plans for like years now.
> but then it breaks, or has awful performance.
You're gonna have to be more specific. I could repeat that sentence for every programming language/library on the planet and without specifics it would make sense.
> You can’t use if-else in JSX,
I don't need to use if-else in JSX to control flow. I can write if(condition) return html;
> which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.
See the sentence I just wrote before this. I can use if/else to control flow and return early without templating. How is that not ideal?
> And regarding signals, preact is using it and it doesn’t seem to break anything there.
It's not about literlaly "breaking" something. They could implement htem if they wanted to. It's about breaking the mental model.
In React, data flows down. That's a constraint, but not always a bad one. I know exactly where to look for data (up). With signals, that's throw out the window. And now, it's not just about what the component accepts via props/context (which again, is down) it now needs to turn itself on it's head.
I used Angular for years before React and I do not miss having things talking to each other throw multiple lateral levels.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.
This is incredibly misleading (and wrong). Templates don't compose. And React is quite literlaly the king of composition.
It's starting to feel like you've never actually used React, but instead are basing your opinions on what you see other people say (who have also not used React).
You can blame the endless amount of people that jump in these threads with hot takes about technologies they neither understand or have experience with.
How many event sourced systems have you built? If the answer is 0, I'd have a real hard time understanding how you can even make that judgement.
In fact, half of this thread can't even be bothered to look up the definition of CQRS, so the idea that "Storing facts" is to blame for people abusing it is a bit of a stretch, no?
What's your response to the common theme that event sourcing systems are difficult to maintain in the face of constantly changing product requirements?
I think having constantly changing product requirements would certainly make it difficult, but that makes all development more difficult.
In fact, I think most complexity I create or encounter is in response to trying to future-proof stuff I know will change.
I'm in healthcare. And it changes CONSTANTLY. Like, enormous, foundation changes yearly. But that doesn't mean there aren't portions of that domain that could benefit from event sourcing (and have long, established patterns like ADT feeds for instance).
One warning I often see supplied with event sourcing is not to base your entire system around it. Just the parts that make sense.
Blood pressure spiking, high temperature, weight loss, etc are all established concepts that could benefit from event sourcing. But that doesn't mean healthcare doesn't change or that it is a static field per se. There are certainly parts of my system that are CRUD and introducing event-sourcing would just make things complicated (like maintaining a list of pharmacies).
I think what's happening is that a lot of hype around the tech + people not understanding when to apply it is responsbile for what we're seeing, not that it's a bad pattern.
Thanks, this is a great comment. Love the observation that event sourcing only makes sense for parts of a system.
Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts.
No problem and likewise. Conversations like this are great because they constantly make me re-evaluate what I think/say and often times I'll come out of it with a different opinion.
> Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts
Amen. And I think what most people miss is that it's really hard to do for domains you're just learning about. And I don't blame people for feeling frustrated.
> What's your response to the common theme that event sourcing systems are difficult to maintain in the face of constantly changing product requirements?
I've been on an ES team at my current job, and switched to a CRUD monolith.
And to be blunt, the CRUD guys just don't know that they're wrong - not their opinion about ES - but that the data itself is wrong. Their system has evaluated 2+2=5, and with no way to see the 2s, what conclusion can they draw other than 5 is the correct state?
I have been slipping some ES back into the codebase. It's inefficient because it's stringy data in an SQL database, but I look forward to support tickets because i don't have to "debug". I just read the events, and have the evidence to back up that the customer is wrong and the system is right.
> It's inefficient because it's stringy data in an SQL database, but I look forward to support tickets because i don't have to "debug". I just read the events, and have the evidence to back up that the customer is wrong and the system is right.
I think one of the draws of ES is that it feels like the ultimate way to store stuff. The ability to pinpoint exact actions in time and then use that data to create different projections is super cool to me.
> CQRS sounds good, until you just want to read a value that you know has been written.
This is for you and the author apparently: Prating CQRS does not mean you're splitting up databases. CQRS is simply using different models for reading and writing. That's it. Nothing about different databases or projections or event sourcing.
This quote from the article is just flat out false:
> CQRS introduces eventual consistency between write and read models:
No it doesn't. Eventual consistency is a design decision made independent of using CQRS. Just because CQRS might make it easier to split, it doesn't in any way have an opinion on whether you should or not.
> by folks and companies who host queueing technologies (like Kafka).
Well that's good because Kafka isn't an event-sourcing technology and shouldn't be used as one.
Yes, I don't know where the misconception that CQRS or Event Sourcing automatically means eventual consistency comes from. We have built, run, evolved, and operated quite a few reasonably sized event sourced systems successfully, and these systems are running to this day without any major incidents. We added eventually consistent projections where performance justified it, fully aware of the implications, but kept most of the system synchronous.
Yup. It's a shame as amazing as event sourcing is it does come with complexity.
On the other hand CQRS + single writer pattern on their owncan be a massive performance win because it allows for efficient batching of views and updates. It's also much simpler to implement than a fullblown event sourcing system.
If you segregate your read and write, i.e put a (P)artition between them, and require writes to be (A)vailable when reads are down (and vice-versa), then you're either inconsistent, or eventually-consistent.
Please explain how you intend to use different models for reading and writing without there being some temporal separation between the two?
Most all CQRS designs have some read view or projection built off consuming the write side.
If this is not the case, and you're just writing your "read models" in the write path; where is the 'S' from CQRS (s for segregation). You wouldn't have a CQRS system here. You'd just be writing read optimised data.
"Hey guys, I'm going to prove that an OS that claims that you don't have to worry about security anymore is actually secure by asking a total stranger to guess my password"
Since it's so flimsy and insecure, you should guess so you can prove how insecure it is. Alternatively, you could fail to do that, because 10 guesses is safe even against an awful password.
lol But what if, and I know this sounds absolutely insane, the person who stole your laptop knows you and isn't a total stranger on the internet? In your security guru mind, would that effect the probability of them guessing right? Or are you of the opinion that you don't need to worry about people close to you breaking into your stuff?
If someone steals your laptop, then sudo limiting guesses is completely irrelevant. Note that I started with
> I will absolutely say that a distro making that claim should not worry about the difference between 3 and 10 password attempts on sudo (i.e. when you're already logged in).
If you'd like to point out that it's really important to require a high-entropy password for the lockscreen or disk encryption, then I'll agree, but that isn't the argument we're in right now.
I don't understand this point. Are you suggesting that less people being happy with their product and thus less people buying it is not related to the valuation of the company and their stock?
> Also, you and me are not the customers. Govs and corporations are.
Huh?
I get you're trying to make a point about the bottom line, but that doesn't mean the bottom line is impervious to bad product decisions or that the people who are paying for their products are not in fact their customers.
reply