362 Matching Annotations
  1. Last 7 days
    1. Especially when rollup is configured with multiple outputs, I find this particular onwarn to be helpful in reducing warning clutter. It just displays each circular reference once and doesn't repeat the warning for each output:
    2. I think my personal preference would be to see them all at once. Or maybe limit it to up to 10 messages and then list the count of how many more messages were not displayed. Pick your reaction
    3. Another thing we could do to limit output would be to only every show the first circular dependency warning. I think we already do this for other types of warnings. Then you would need to tackle the warnings one-by-one, though.
    1. Note that these are not hyperlinks; these URIs are used for identification. This is a machine-readable way to say “this is HTML”. In particular, software does not usually need to fetch these resources, and certainly does not need to fetch the same one over and over!
    2. You might think something like “don’t request the same resource thousands of times a day, especially when it explicitly tells you it should be considered fresh for 90 days” would be obvious, but unfortunately it seems not.
    3. Any software that makes HTTP requests to other sites should make it straightforward to enable the use of a cache.
    1. Adding an API for something is an endorsement of that approach.
    2. 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.
  2. Oct 2020
    1. formvalidation: path.resolve

      Why use resolve.alias to point to 'vendors/formvalidation/dist/es6'? Why not just use an npm package and have package.json name module: 'vendors/formvalidation/dist/es6'

      Then (I think) the examples below like

      import luhn from 'formvalidation/algorithms/luhn';

      would work the same but without that workaround.

    1. I'm okay with an overall design that allows people to plugin the parts they need in order to be able to generically support a compile-to-javascript language, but to bake in support for one singular solution because its popular is simply bad engineering.
    2. Of all the compile-to-languages, the one that strikes me as having the least merit is JSX. It's basically a ton of added complexity for the sake of what boils down to syntax. There are no real gains in terms of language semantics in JSX.
    3. Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
    4. If the react cargo cult didn't have the JSX cowpath paved for them and acclimated to describing their app interface with vanilla javascript, they'd cargo cult around that. It's really about the path of least resistance and familiarity.
    5. hyperscript is more concise because it's just a function call and doesn't require a closing tag. Using it will greatly simplify your tooling chain.

      I suppose this is also an argument that Python tries to make? That other languages have this con:

      • cons: closing tags make it more verbose / increase duplication and that Python is simpler / more concise because it uses indentation instead of closing delimiters like end or } ?
    6. hyperscript is much simpler to refactor and DRY up your code than with JSX, because, being vanilla javascript, its easier to work with variable assignment, loops and conditionals.
    7. I wasn't aware react-hyperscript existed!
    8. @subfuzion That error looks unrelated to the existing discussion.

      I assume they locked it in reaction to someone posting something unrelated / off-topic.

    9. This is the problem with baking in support for frameworks with special cases in the codebase. You can never support all the frameworks. :-(




    1. Alfred Korzybski remarked that "the map is not the territory" and that "the word is not the thing", encapsulating his view that an abstraction derived from something, or a reaction to it, is not the thing itself.
    2. The map–territory relation describes the relationship between an object and a representation of that object, as in the relation between a geographical territory and a map of it.
    1. The default groups, that we talked about before, like domain users and domain admins are security groups. They're used to grant or deny access to IT resources.
    2. A distribution group, is only designed to group accounts and contacts for email communication. You can't use distribution groups for assigning permission to resources.
    1. The service that hosts copies of the Active Directory database are called domain controllers, or DCs
      • Hosts a replica of the Active Directory database and group policy objects.

      • Serve as DNS servers to provide name resolution and service discovery to clients.

      • Provides central authentication through a network security protocol called Kerberos

      • Decides whether or not clients have access to shared resources like file systems and printers

    2. Active Directory has been used to centrally manage networks of computers
      • A native service for Microsoft Windows
      • Knows how to speak LDAP protocol and can interoperate with Linux, OS-X and other non-windows hosts
      • Central repository of Group Policy Objects (GPOs)
    3. One of the most common methods for this authentication is using Kerberos.
      • Kerberos is a network authentication protocol that is used to authenticate user identity, secure the transfer of user credentials, and more
    4. role-based access control, or RBAC
      • Is an approach to restricting system access to authorized users.

      • Controlling access to resources isn't all you can do. You can also centralize configuration management.

        You wouldn't want to setup printers or software for each and every user.

    1. via ruanyifeng http://www.ruanyifeng.com/blog/2020/09/weekly-issue-127.html

      漫画家斯科特·亚当斯(Scott Adams)曾经提过一种建立个人护城河的方法,就是找到自己最擅长的2个~3个事物的交集。比如,他既不是最好的漫画家,也不是最好的作家,也不是最好的企业家,但他可以是最好的商业类漫画短文作者,这就是他的护城河。

    1. I actually wasn't trying to promote this like I usually promote my articles.
    2. I wasn't really intending this article to get spread as far as it did without context. I never tagged it, I didn't make it a general post on Social media or on Hacker News
    3. you expect some hyperbole during these presentations and you should of course question and verify the claims being made.
    4. helped me carve a niche for what would become SolidJS. I still see that space today, so I'm glad that I did.
    5. If there was a place I thought reactivity would be weak, I embraced it and I worked on it until I was happy with the results.
    6. but everything they were doing started to make sense
    7. This was the piece that made all their other recent work all gel and I gazed into the sun for the beauty that was there.
    8. I started Solid years ago before I thought anyone would be interested in using it. I only started promoting it because it had already achieved the goals I had set out for it.
    1. React does not attempt to provide a complete "application library". It is designed specifically for building user interfaces[3] and therefore does not include many of the tools some developers might consider necessary to build an application.
    1. I'm glad they added this site. Instead of just closing such questions as "off topic" on StackOverflow or SuperUser without having them some place appropriate to send them.

  3. Sep 2020
    1. By default, npx will check whether <command> exists in $PATH, or in the local project binaries, and execute that. Calling npx <command> when <command> isn't already in your $PATH will automatically install a package with that name from the NPM registry for you, and invoke it. When it's done, the installed package won’t be anywhere in your globals, so you won’t have to worry about pollution in the long-term. You can prevent this behaviour by providing --no-install option.
    1. export let client; setContext("client", client);

      Wouldn't this set context to undefined initially? And reassigning a new value to client wouldn't update the value stored in the context, would it? It would only update the let client variable.

      Where does this let client actually get set to the client from async function preload? I guess I need to understand Sapper more to know how this works, but it doesn't seem like it could.

      Update: I think I found the answer (it runs before):


      It lives in a context="module" script — see the tutorial — because it's not part of the component instance itself; instead, it runs before the component is created, allowing you to avoid flashes while data is fetched.

    1. This is so common that ECMAScript 2020 recently added a new syntax to support this pattern!export * as utilities from "./utilities.js";This is a nice quality-of-life improvement to JavaScript, and TypeScript 3.8 implements this syntax. When your module target is earlier than es2020, TypeScript will output something along the lines of the first code snippet.
    2. If you’ve used Flow before, the syntax is fairly similar. One difference is that we’ve added a few restrictions to avoid code that might appear ambiguous.
    1. But this is only a halfway decent way to clarify that this is an external dependency, because the only way to resolve a peer dependency warning is to install react from npm—there's no way to notify npm that you resolve the dependency to a browser global. So peer dependencies should be avoided in favor of external declarations. Then Rollup will take care of warning about "unresolved dependencies", even if external declarations can't express a particular version range with which your library is compatible like peer dependencies can.

      Interesting. Didn't realize. From my perspective, I usually do install packages via npm, so wouldn't have known about this problem.

      npm and rollup both try to solve this problem but in different ways that apparently conflict? So if a lib author lists peerDependencies then it can cause problems for those getting lib via browser (CDN)? How come so many libs use it then? How come I've never heard of this problem before?

    1. Then, the projects that use these libraries get to process these import statements how they like when they are bundled. For the ones that wish to load jQuery from a global, we again mark 'jquery' as an external—since we still don't want Rollup to bundle jQuery—and as a global.
    1. Luckily, there is absolutely no good reason not to use strict mode for everything — so the solution to this problem is to lobby the authors of those modules to update them.
    1. Basically, the idea is that a train tried to start with the caboose brakes stuck on. After releasing the caboose, the train still could not start. The problem was that when the train attempted to start with the caboose brake on, it stretched all the inter-car couplings so that the whole train was just like one big car. At this point, the friction from the engine train wheels was not enough to get the whole thing going. Instead, you need to just get one car moving at a time - this is why there is space between the couplings.
    1. DX: start sapper project; configure eslint; eslint say that svelt should be dep; update package.json; build fails with crypt error; try to figure what the hell; google it; come here (if you have luck); revert package.json; add ignore error to eslint; Maybe we should offer better solution for this.
    2. When the message say function was called outside component initialization first will look at my code and last at my configuration.
    1. This isn't really a bug, because if you have an async function that returns a function, it doesn't really return a function - it returns a promise. I don't remember whether the Svelte internals currently check for the onMount callback's return being a function or whether they check for it being truthy. Maybe there's some adjustment to be made there.
    1. Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
    2. The main rationale for this PR is that, in my hones opinion, Svelte needs a way to support style overrides in an intuitive and close to plain HTML/CSS way. What I regard as intuitive is: Looking at how customizing of styles is being done when applying a typical CSS component framework, and making that possible with Svelte.
    3. Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
    4. The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
    5. margin, flex, position, left, right, top, bottom, width, height, align-self, justify-self among other is CSS properties that should never be modified by the child itself. The parent should always have control of those properties, which is the whole reason I'm asking for this.
    6. new style RFC




    1. This has already forced me to forgo Svelte Material because I would like to add some actions to their components but I cannot and it does not make sense for them to cater to my specific use-case by baking random stuff into the library used by everyone.
    2. The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.
    1. Does it look like a decorator plugin in Ractive, right
    2. Lets not extend the framework with yet another syntax
    3. Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.
    4. I totally get not wanting to extend the syntax. I tried doing these things and in practice it was not easy or pretty. Actions provide a much cleaner and easier way to accomplish a certain set of functionality that would be much more difficult without it.
    1. And to illustrate another way actions are helpful, take your above example and put the button into a {{#each}}. It gets more complicated.
    2. I'm just pushing on the "is this really a good idea" front
    3. If this was tied into Svelte's flow with hooks this would not be necessary since it would know when it was being removed from the DOM.
    4. Another problem I ran into was knowing when an element is removed. I had to add a MutationObserver on the current tooltip target so if it gets removed by Svelte while the tooltip is visible (e.g. if a click moves to another route) the tooltip isn't left hanging around on the screen. No mouseleave/mouseout events are dispatched on elements that are removed.

      First sighting: MutationObserver

    5. You must: reference each element you are extending using refs or an id add code in your oncreate and ondestroy for each element you are extending, which could become quite a lot if you have a lot of elements needing extension (anchors, form inputs, etc.)
    6. This is where hooks/behaviors are a good idea. They clean up your component code a lot. Also, it helps a ton since you don't get create/destroy events for elements that are inside {{#if}} and {{#each}}. That could become very burdensome to try and add/remove functionality with elements as they are added/removed within a component.
    7. I would be willing to take a stab at it if you think it would be a task within reach.
    1. Re Object.keys(undefined), I think I'm ok with that failing. AFAIK it would also fail in React
    2. The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)
    1. When a component reaches such a size that this becomes a problem, the obvious course of action is to refactor it into multiple components. But the refactoring is complex for the same reason: extracting the styles that relate to a particular piece of markup is an error-prone manual process, where the relevant styles may be interleaved with irrelevant ones.
    1. You can help ensure your RFC is reviewed in a timely manner by putting in the time to think through the various details discussed in the template. It doesn't scale to push the thinking onto a small number of core contributors.
    1. There are tools in Svelte that break this expectation to a degree, but they are a bit annoying to use, which makes it an active decision on the part of the developer. The API hints at the way we want you to do things because we feel that this will give the better experience.
    2. There is an escape hatch in :global() that facilitates this. It is verbose, and we are okay with that, we don't want it to be too pleasant to use. We don't want people doing this at all, but it is there when needed.
    3. I understand what you're getting at, but we shouldn't miss out on useful features just because a few developers will abuse it...
    1. If your reaction to the video was 'fine, but if we use TypeScript and write plugins for each editor then we can get all the autocomplete and syntax highlighting stuff' — in other words, if you believe that in order to achieve parity with CSS it makes sense to build, document, promote and maintain a fleet of ancillary projects — then, well, you and I may never see eye to eye!
    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
    1. Now of course we know how React handles this conflict: it takes the new nodes in your virtual DOM tree — the waters in your flowing river — and maps them onto existing nodes in the DOM. In other words React is a functional abstraction over a decidedly non-functional substrate.

      To me this is a warning sign, because in my experience, the bigger the gap between an abstraction and the thing it abstracts, the more likely you are to suffer what programmers like to call ‘impedance mismatches’, and I think we do experience that in React.

    1. Now I know what you're thinking, "this is an atrocity, what a horrible mess!" and you're right, it's kind of ugly. In fact it's just about impossible to think this is a good idea the first time you see it — you have to actually try it.
  4. Aug 2020
    1. If you are a senior, try talking to a junior or someone less experienced than you. Many companies are running what is called ”reverse mentoring” programs where juniors coach senior members of a company. Senior’s experience is traded for a fresh perspective from a junior. You’d be amazed at how much you could learn and share.
    1. We share our labor of love

      Here's something to share from the margins--George Carlin. Like Carlin, we in the margins need is to crash into the open and yoke academic power (good ideas, clearly expressed, and openly political) to systemic change. Open education seems too tame to do that. Prove me wrong.


    1. Fix it, please, if it's incorrect.
    2. FWIW, I would have raised it earlier if I thought it would have made a difference.

      This is different from apathy; it's more like powerlessness.

    3. If we've gone more than a year without this being a problem in the slightest, I don't see how the next year would be any different.
    4. +1 for taking the language back.
    5. Can't upvote this enough. It is highly irritating to see language destroyed (and we wonder why kids bastardize the language..).
    1. my point is that using "into" in such a case is just as incorrect as using "inas" would be. The fact that people make mistakes doesn't change this.

      "Log in" is the only correct way to spell the verb, and the only way to be consistent with 1000s of other phrasal verbs that are spelled with a space in them.

      We don't need nor want an exception to the general rule just for "login" just because so many people have made that mistake.