44 Matching Annotations
  1. Mar 2021
    1. The issue is kind of regression/trade-off for keep bundles get loaded same as the declaration order. The only thing this part added is the new BundleBind! command. Sure we should try fix issue by not introduce new feature/concept as possible as we can, but when the concept/complexity is just add a simple command without any argments to the configuration, and the benefit is clean, simple and efficient implementation, IMHO it is worth. That's why I finally chose this solution.
    1. That said, I wish more people would talk both sides. Yes, every dependency has a cost. BUT the alternatives aren't cost free either. For all the ranting against micropackages, I'm not seeing a good pro/con discussion.
    1. And trust us, we’ve been playing with different APIs for two years and this was the easiest and fastest outcome.
  2. Feb 2021
    1. This column and last month's article are about design. Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another.
    2. If you don't understand both sides of an issue, you cannot make an intelligent choice; in fact, if you don't understand all the ramifications of your actions, you're not designing at all. You're stumbling in the dark.
    3. My point is that you should not program blindly. You must understand the havoc a feature or idiom can wreak. In doing so, you're in a much better position to decide whether you should use that feature or idiom. Your choices should be both informed and pragmatic.
    1. Space: Suppose we had infinite memory, then cache all the data; but we don't so we have to decide what to cache that is meaningful to have the cache implemented (is a ??K cache size enough for your use case? Should you add more?) - It's the balance with the resources available.
    2. You have to guess when the data is not likely to be needed in memory. It can't be too short that the cache is useless, and too long that you'll get a memory leak.
  3. Jan 2021
    1. Progress is made of compromises, this implies that we have to consider not only disadvantages, but also the advantages. Advantages do very clearly outweigh disadvantages. This doesn’t mean it perfect, or that work shouldn’t continue to minimize and reduce the disadvantages, but just considering disadvantages is not the correct way.
    2. Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.
    1. As you already noticed, the extension does not go in an manipulate the hrefs/urls in the DOM itself. While it may seem scary to you that an extension may manipulate a URL you're navigating to in-flight, I think it's far scarier to imagine an extension reading and manipulating all of the HTML on all of the pages you go to (bank accounts, utilities, crypto, etc) in order to provide a smidgeon of privacy for the small % of times you happen to click a link with some UTM params.
  4. Nov 2020
  5. Oct 2020
    1. Yes, you cannot fully express a modern app through templates without sacrificing flexibility and code reusability.
    2. It might seem like a small thing but for me it is more than a valid reason to add an extra of 0.15–0.25 seconds to my app’s time-to-interactive.
    3. I guess when making decisions about the stack of the compiler, they made a tradeoff — how high the overhead is vs the benefits the community gets in exchange.
    4. But is overhead always bad? I believe no — otherwise Svelte maintainers would have to write their compiler in Rust or C, because garbage collector is a single biggest overhead of JavaScript.
  6. Jul 2020
    1. One way around this is simply linking to each SVG with an <img> tag, instead of embedding the actual SVG in the DOM. This way, the virtual DOM only needs to track one node per image, instead of hundreds for each SVG. Inline SVG [above] vs linked SVG. But in doing so we’ve crippled our ability to manipulate our SVGs. No longer can we add stroke, move shapes, remove nodes or change fill. In short, if you want :hover to change the fill color, you’re back in the stone age.
    1. You know the trade-off. Use the img tag to display an SVG, and you get clean markup — at the cost of styling the SVG using its properties like fill, stroke, SVG filters and more.
  7. May 2020
    1. This is exactly the approach that Chef has chosen. They built Omnibus, an automation system which spawns an army of VMs for building platform-specific packages. It works, but it's heavyweight and a big hassle. You need a big build machine for that if you want to have reasonable build time. And be prepared to make 20 cups of coffee.
    1. I will need to find a workaround for one of my private extensions that controls devices in my home network, and its source code cannot be uploaded to Mozilla because of my and my family's privacy.
    2. We must consider introducing sensible default options in Firefox, while also educating users and allowing them to override certain features, instead of placing marginal security benefits above user liberties and free choice.
  8. Apr 2020
    1. There will be those within organisations that won't be too keen on the approaches above due to the friction it presents to some users.
    2. This has a usability impact. From a purely "secure all the things" standpoint, you should absolutely take the above approach but there will inevitably be organisations that are reluctant to potentially lose the registration as a result of pushing back
    3. As such, they're not in clear text and whilst I appreciate that will mean some use cases aren't feasible, protecting the individuals still using these passwords is the first priority.
    1. One of the drawbacks of waiting until someone signs in again to check their password is that a user may simply stay signed in for a long time without signing out. I suppose that could be an argument in favor of limiting the maximum duration of a session or remember-me token, but as far as user experience, I always find it annoying when I was signed in and a website arbitrarily signs me out without telling me why.
    1. There's a tradeoff to be made between the false positive rate, the number of passwords checked, and the amount of disk/network bandwidth used.
    1. IDEs and standard *nix tools like sed can help, but you typically have to make a trade-off between introducing errors and introducing tedium.
  9. Dec 2019
  10. Nov 2019
    1. The chosen approach pushes a lot of complexity out of the core. As a result it might take more code to achieve certain functionalities. This is the price of flexibility. And that's the primary design goal of Reactabular.
  11. May 2019
    1. first target the patients at highest risk of relapse;

      Clinical trials will most certainly first include those patients with the highest risk of relapse. However, long term, everything will depend on the risk/ benefit trade off: if an effective, simple, well-tolerated and cost-effective treatment was available (let's imagine a single short low-dose PD1 for any early Melanoma patient) that prevented progression for most patients would be very different from a highly toxic, expensive treatment that doesn't work for everyone (think Ipi 10mg/kg adjuvant)- so everything is in the trade-off

  12. Jan 2019