For example because the wait time in the theme park which I visited can be find only in their app for iOS and Android. The same true for ordering food to your table in another theme park. Yeah, there are alternatives, but those cost you time, sometimes hours. And these companies won’t implement anything for an error margin.

The fact this is a thing is part of the problem.

We should not be downloading executables and running them from random third parties in order to do mundane tasks. If they absolutely must have an app, it should be a web app, end of.

Here's a question, what if the executable was thoroughly sandboxed? Like Firecracker level with virtualization? And once you're there, what's the difference between that and a webapp?

I don't think apps are going away so users need to have a switch that says, "I don't trust this company with anything". Extremely limited Internet access, no notifications, no background activity at all, nothing. It needs to be like apps for the 2nd gen iPhone: so completely neutered that webapps look like Star Trek level technology.

There is beyond zero incentive for either Apple or Google to provide something like this. Google HAS network permissions on Android. You just can't access them. They're hidden from you, presumably because Google prefers more malware and spyware running on your phone.

The reality is that both Google and Apple are not just in on this, they created this situation. They not only don't care if you download 1 million apps from the app store that may or may not be malware, they actually prefer that model. Going as far as to sabotage the web to maintain that model. Going as far as developing their own browser which is broken to maintain that model.

Which, relatedly, is why any type of argument of "safety" around the app store or play store is complete and utter bullshit. Apple and Google want you to download as much malware as possible. All their actions demonstrate that.

This is the inverse of what he's saying. Attestation takes control away from users. Permissions give control to users. The ultimate user control is not using the software at all.

That's what the GP meant, wasn't it? "Good luck with your sandboxing, Google is already a step ahead in this cat-and-mouse game".

Again:

> but this would just hide the actual problem with interoperability and pass it down for the next underdog project to worry about.

Just consider how this wouldn't happen at all in an environment where no platform dominates in popularity (and it doesn't always happen today either, as lots of things like these are accessible via the Web from any platform regardless).

We have exactly that interoperability right now, and the market said that they don’t want use that.

A market like that needs to be better regulated then.

Yeah, I don’t understand the parent commenter either. Even with my latest laptop, it took days and weeks to make everything work (like audio, my monitors, DPI, VLC/mpv, even networking). And even then I had to turn off some hardware functionality, because it’s so buggy (bye-bye battery life). And this is before introducing Wayland for example…

Also installing is way easier for beginners with Windows. I’m happy that Linux installation now at least reached the level of Windows 98, but I still need to search for things every single time, even when I do it about every other years for several decades now. Just because somebody thought that it’s so important to ask simple users about an implementation detail which almost nobody care about. And this is before bugs… which I encounter quite frequently.

It’s getting better, but by not much. It could be a very stable OS with the right hardware even 20 years ago. That didn’t change, you still need to be very careful if you want a good experience with Linux and a GUI. I had no laptop or PC in the past 30 years on which I could install Linux without serious hiccups if I wanted anything more than terminal. I could almost always make it usable (it was impossible with one laptop), but I always had to give up something, like battery life, game performance, my headset at the time, etc. And of course a ton of time.

That feels like bad luck to me. I've had a Dell, two Asus, and a ThinkPad over the past decade or so, and except for hibernate with the Dell, everything has just worked out out the box with no tinkering.

With 2 ASUS? You seem to be the lucky one, not me. ASUS is quite infamous for more than a decade about its bad Linux support. Basic things can work sometimes well, but you need to be extremely lucky to have one which really completely works as intended, like temperature control.

> I think using Date.now() is perfectly ok.

This is why we have tests which we need to update every 3 months, because somebody said this. This is of course, after a ton of research went into finding out why the heck our tests broke suddenly.

I would call those badly-written tests. The current date/time exists outside the system and ought to be acceptable for mocks, and in python we have things like freezegun that make it easy to control without the usual pitfalls of mocks.

What are those mock pitfalls, which are avoided by freezegun which is a mock according even to them? IoC and Clocks solve the same problem. So what are the pitfalls of using those instead of this other mock?

Applying it to the wrong module, a very common mistake in python due to how imports work.

There is enough people who don’t read articles just headlines whose world view can be changed with this.

In Hungary, where I’m originally from, one of my friends sent me an article, which was about immigration in 2015, because she thought that the local district government wanted to move “migrants” (dog whistle for non white people over there) into her district. The headline said that, the body said the exact opposite… and it worked.

Also there are a ton of comments here, on Reddit, and really everywhere, that makes it quite obvious that a lot of people don’t read just headlines.

> you can always decide what to do next.

I think everybody can find examples from their life when this was not true. And not even just simple one like a reaction to a flying object towards your face, but some high level impulses, like when I was in love, I definitely couldn’t control my acts completely. Of course, I was still responsible for my acts, but they were only instincts, no real thinking was involved.

> Isn't it the modern equivalent of "let me Google that for you"?

No. With Google you get many answers. With AI you get one. Also we know that AI is unreliable with some possibility, it’s highly probable that you can get a better source on Google than that. This is especially bad when the question is something niche. So, it’s definitely a worse version of lmgtfy.

People don’t or even can’t remember how was front end development before React/Flux/Redux. You could easily had problems with state management even with less than 1000 LOC simple pages. Of course, you could mitigate it, but it wasn’t trivial at all.

Look, I wrote one of the only published books on Backbone, and it will always have a special place in my heart, but ... the OP has no idea what he is talking about.

Backbone employed a two-way data binding flow. You're responsible for updating the models (ie. state) (way #1) when the user triggers events, AND you are responsible for updating the DOM whenever the models (ie. state) changes (way #2).

In React, they used a revolutionary new paradigm (flux), making it so you only worry about one direction (updating the models/state in response to events); you never render anything (React renders everything for you in response to state changes)!

If you've tried developing a non-trivial site with both, it quickly becomes apparent how much that one difference completely simplifies a huge aspect of development.

so we need a state manager which also updates dom automatically. is there such a thing?

This is off topic but I need to ask you to stop breaking the site guidelines. You've been doing it repeatedly lately (not in the current case—present comment is fine), and we end up banning such accounts.

If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it. We've asked you at least once before: https://news.ycombinator.com/item?id=36796345.

Thanks dang, i'll do better.

I remember watching one of the first React demonstrations/talks, and the biggest selling point was literally "You have a web page with various elements, and some of them needs to keep in sync, at Facebook we have chat messages and notifications, and they need to be in sync regardless of where you are, even on the same page, how do you solve that?" and then outlined how having one place for the state to live solves that issue without resorting to two-way data-bindings, instead data only flows in one direction.

Not sure if React isn't being presented as such anymore, but that's still the problem I see React solving, not more, not less.

Yeah I would argue that it's possible to do it well with Backbone, and you end up with something much leaner but it requires a really strong understanding of state/event flow and lot of discipline, whereas with React the correct way to handle this is the 'obvious' path, which dramatically lowers the barrier to entry.

And now everyone has phantom unreads again because it is cyclical and a different team is in charge of every other div

You just need 2 components with bidirectional binding to enter a world of hurt.

As you say many people do not understand how important, vital and bizarrely _non-obvious_ uni directional data flow was.

Everything was so hard. Everything! Backbone was kinda fun to write though, I'll admit. But not fun at scale to manage.

At least there would be an incentive to reduce size. I could easily got the same amount of information with the same quality when I had 3 MB/month 20+ years ago.

Not disclosing the ingredients is illegal large part of the world, and people can die if you don’t do that, so the answer is clearly yes in some sense. This is also true for some cooking techniques, like heat treatment of raw meat. I think your analogy is not the best.

Not disclosing ingredients is more like not disclosing dependencies because I am very confident that you can't go into a shop, buy a random food and then construct recipe from list of ingredients.

There are parts of the code which don't use dependencies, because you wrote it. Which part of any food is not created from ingredients?