38 Matching Annotations
  1. Last 7 days
    1. There are contradicting definitions: "dependence: one that is relied on", "dependency: something that is dependent on something else", "dependent: one that is dependent" which also says "archaic : DEPENDENCY" which is certainly the inverse of what is usually meant in technology... is it more correct to install the "dependences"? (wiktionary gives it as the plural)
    1. I'm afraid there's only so much the docs & tutorials can do about something like this actually. When you first read them, you don't get Svelte well enough (since you're reading a tutorial...) for this to make sense to you. Then you try something, encounter a behaviour, question it, understand better... That's learning.
  2. Oct 2020
    1. Could you please explain why it is a vulnerability for an attacker to know the user names on a system? Currently External Identity Providers are wildly popular, meaning that user names are personal emails.My amazon account is my email address, my Azure account is my email address and both sites manage highly valuable information that could take a whole company out of business... and yet, they show no concern on hiding user names...

      Good question: Why do the big players like Azure not seem to worry? Microsoft, Amazon, Google, etc. too probably. In fact, any email provider. So once someone knows your email address, you are (more) vulnerable to someone trying to hack your account. Makes me wonder if the severity of this problem is overrated.

      Irony: He (using his full real name) posts:

      1. Information about which account ("my Azure account is my email address"), and
      2. How high-value of a target he would be ("both sites manage highly valuable information that could take a whole company out of business...")

      thus making himself more of a target. (I hope he does not get targetted though.)

    1. One of Svelte's advantages, for me, is that I can test out ideas with relatively few lines of code. the #with feature could save me from adding a separate component for the content of an #each loop. I get frustrated when I have to create a new file, move the content of the #each clause, import it as a component, and add attributes and create exports for that, and implement events to send messages back, and event handlers, when I just wanted to test a small feature.
    1. JavaScript is, of course, a dynamic language that allows you to add and remove objects and their members at any point in time. For many, this is precisely why they enjoy the language: there are very few constraints imposed by the language.
    1. Just like elements can have children... <div> <p>I'm a child of the div</p> </div>...so can components. Before a component can accept children, though, it needs to know where to put them. We do this with the <slot> element.
    1. However, this would lead to further divergence. Tooling that is built around the assumptions imposed by template literals wouldn't work. It would undermine the meaning of template literals. It would be necessary to define how JSX behaves within the rest of the ECMAScript grammar within the template literal anyway.
    2. Template literals work well for long embedded DSLs. Unfortunately the syntax noise is substantial when you exit in and out of embedded arbitrary ECMAScript expressions with identifiers in scope.
    1. About the argument against it, "{@const will make code less consistent ": I think the same is true now, since people can come up with very different ways of dealing with the "computed value inside each loop/if function" problem. Some extract components, some use functions, some will prepare the array differently beforehand.
    2. This is exactly why I'm in favor of @const. Helpers are fine, except when they're not and turn into boilerplate.
    3. Right, because those are the only 3 instances where new "scopes" are created, which means you're seeing data for (probably) the first time.

      good point: means you're seeing data for (probably) the first time.

    4. I like this, mostly because it allows me to write small components without creating another separate sub-component for holding the value simple computation. I get annoyed every time I need to create a component just to hold a variable, or even move the computation away from the relevant location. It reminds me of the days where variables in C had to be declared at the top of the function.
    1. Putting a browserlist in the project will send a false signal to users. Svelte is only a lib, not an application. The consumer / implementer will have to decide what level of support he wants, according to its constraints/userbase and adjust its build process and polyfills implementation.
  3. Sep 2020
    1. A lot of instructions I read say things like npm install niftycommand and then niftycommand. But this will never work unless you have ./node_modules/.bin in your path, will it?
    1. Yes, they do but none of them allow arbitrary javascript anywhere in the template it is finely controlled. This deviates from that, in fact that is it's defining feature.
    1. We should also allow passing unrecognised props to the rendered component. eg: tabindex might be required on some instances of a component, and not all. Why should developers have to add tabindex support to their components just that it may potentially be used

      Glad to hear this is solved now: $restProps

    2. The language should work for developers, not the other way around.
    1. Adding my 2 cents to the discussion. Adding a class prop to a component doesn't necessarily mean it should apply the style to the root element, but it makes sense that it should apply it the main element visually. Let's take a modal component as an example.
    2. You're not trying to pass a class to a dom element. You're passing a class to a component. It's up to the component to define what that means for the components use case. In most cases it would be passed to a dom element.
    1. I don’t want my source to be human-readable, not for protective reasons, but because I care about web performance more. I want my website to arrive at light speed on a tiny spec of magical network packet dust and blossom into a complete website. Or do whatever computer science deems is the absolute fastest way to send website data between computers. I’m much more worried about the state of web performance than I am about web education. But even if I was very worried about web education, I don’t think it’s the network’s job to deliver teachability
  4. Aug 2020
    1. I think the conjugation is particularly helpful to see why it should be two separate words: "log in" -> "logging in" -> "logged in"
    2. You can also think about each one with the way we stress the different syllables slightly when we're speaking: "log in to host.com" sounds like "log + in + to host.com" (each word is pretty much evenly stressed) "log into host.com" sounds like "log + INto host.com" (the stress is on "in") "login to host.com" sounds like "LOGin + to host.com" (the stress is on "log")

      I wouldn't have thought about using the way we pronounce it to make a point about grammar, but somehow it seems to help slightly to make the point.

  5. Jul 2020
    1. It would be nice if the tests weren't so implementation specific, but rather tested the essence of the functionality. I tried to make them less brittle but failed. To that end, re-writing all the tests in rspec would be (IMHO) a brilliant improvement and pave the way for better tests in the future and more flexibility in implementation.
  6. Jun 2020
  7. May 2020
  8. Apr 2020
    1. I think it's useful to differentiate especially because there are many situations where "hack", and its conjugations, is the only effective term to describe something that has nothing to do with malicious violation of security measures or privacy.
  9. Mar 2020
    1. The whole point of not relying on debt excessively in normal times is precisely to be able to use debt massively and without hesitation in situations like this.