Hacker Newsnew | past | comments | ask | show | jobs | submit | tim1994's commentslogin

With signals you can avoid the prop drilling. I think signals can help a lot with this approach


I think the parent wants to separate the V from the M/C. If you smuggle signals inside of components to avoid prop drilling, you would be coupling the M/C and the V. I suppose that's not what the parent has in mind.


Well, someone has to start. It's ok if you use the alternative with a subset of your contacts.


It has to overcome some critical mass, i.e. political inertia.


Using whatever platform you prefer with a subset of people is fine and doable, but you're lying to yourself if you think that it is the "start" of anything.


True, but considering that the extension was bought in 2022 by Avast, maybe it has its own tracking built in by now or will have something concerning done to it in the future. So even if the user does not care about cookies that much I would still recommend this new extension over "I don't care about cookies"


For panning you don't need a 3D view/reconstruction. This also allows translational camera movements, but only for nearby views. Maybe I am overly pedantic here, but for HN I guess thats appropriate :D


For a good slow pan, you don’t need 3d reconstruction but you DO need “Ashokan Farewell”


Should you optimize for resize performance? I guess that depends on the app. Use the tool that fits the requirements.


Resizing is not the optimization target, it just makes reflow performance visually apparent.


The problem is content exclusivity. It would be great if all the content or at least most would be available on all platforms. At least eventually. That would be great for consumers. Mergers like this typically not.


Like we had for music on the radio, compulsory licensing


We could do that by limiting copyright to just 10-14 years. All platforms could have all that content forever without paying a dime. New stuff and exclusives would still be a draw to attract people to one platform or another.


Give 10 years of copyright for free, then a $1000 fee for the next decade, and make every subsequent decade 100x more expensive.


Nah, there's no reason why trillion dollar companies should be allowed to pay anything to keep our shared culture locked up. Doing so only hinders innovation and the creation of new works. 14 years was long enough back when global distribution was unimaginable and any distribution at all was highly expensive.

Today you can instantly distribute media to the entire planet at near zero expense. If you can't make money after a decade you have only yourself or your product to blame. Also, it's not as if once something goes into the public domain all income stops either. With even a small amount of effort creators can continue to successfully package and sell their stuff to the fans even when it's avilable for free. It's worked on me several times in fact.


It would be great for consumers if it was just free


Another reason I can think of is the requirement not to introduce a breaking change. It is very frustrating if the codebase has a lot of hacky/bad code in it but a lot of it can't be changed...


Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.


> Because updates don't just include new features but also bug and security fixes.

This practice needs to change, although it will be almost impossible to get a whole ecosystem to adopt. You shouldn’t have to take new features (and associated new problems) just to get bug fixes and security updates. They should be offered in parallel. We need to get comfortable again with parallel maintenance branches for each major feature branch, and comfortable with backporting fixes to older releases.


I maintain both commercial and open source libs. This is a non starter in both cases. It would easily double if not triple the workload.

For open source, well these are volunteer projects on my own time, you are always welcome to fork a given version and backport any fixes that land on main/master.

For commercial libs, our users are not willing to pay extra for this service, so we don't provide it. They would rather stay on an old version and update the entire code base at given intervals. Even when we do release patch versions, there is surprisingly little uptake.


Are you just referring to backporting?


Semver was invented to facilitate that. Only if everyone adhered to it.


Semver doesn't help. The primary issue is effort. If it's an open source project with 1-2 devs, they probably won't be able to handle supporting multiple branches unless they're being paid to do this.


> Semver was invented to facilitate that

First time I've heard that. How does semver facilitate backporting?


Of course it doesn't provide backports by itself, it's a versioning system. But version number changes with SemVer are meant to indicate whether an update includes new fearhews or not (minor bump means new features, patch bump means bugfixes only).

Of course, the actual issue is that maintaining backports isn't free, so expecting it from random single-person projects is a little unrealistic. Bug fixes in new code often need to be rewritten to work on old code. I do maintain old release branches for some projects and backporting single patches can cause whole new bugs that were never present in the main branch quite easily.


IMO for “boring software” you usually want to be on the oldest supported main/minor version, keeping an eye on the newest point version. That will have all the security patches. But you don't need to take every bug fix blindly.


For any update:

- it usually contains improvements to security

- except when it quietly introduces security defects which are discovered months later, often in a major rev bump

- but every once in a while it degrades security spectacularly and immediately, published as a minor rev


> The government is.

Companies too.


Companies can't use violence against individuals who do things they don't like.


I think the problem is that they cannot communicate that they don't know something and instead make up some BS that sounds somewhat reasonable. Probably due to how they are built. I notice this regularly when asking questions about new web platform features and there is not enough information in the training data.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: