244 Matching Annotations
  1. Last 7 days
  2. Oct 2020
    1. Indeed, it looks like svelte-hooks did add support for clean-up functions to their useEffect in devongovett/svelte-hooks@1d39d95! ... which is great, though @DylanVann's much simpler and zero-dependency version is even better in some ways.
    1. mixing the turing complete of javascript with the markup of HTML eliminates the readability of JSX so that it is actually harder to parse than a solution like hyperscript
    2. 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.
    1. Then at some moment I just stumbled upon limitations and inexpressiveness of templates and started to use JSX everywhere — and because JSX was not a typical thing for Vue I switched to React over time. I don’t want to make a step back.
    1. Solid is similar to remoteStorage in that it allows apps and services (including unhosted web apps) to store the user's data under the user's control.
    1. Long, H., correspondentEmailEmailBioEmailFollowEmail, H. L., Dam, rew V., Fowers, rew V. D. focusing on economic dataEmailEmailBioEmailFollowEmailAlyssa, visualization, A. F. reporter focusing on data, data, analysisEmailEmailBioEmailFollowEmailLeslie S. S. reporter focusing on, & storytellingEmailEmailBioEmailFollowEmail, multimedia. (n.d.). The covid-19 recession is the most unequal in modern U.S. history. Washington Post. Retrieved October 2, 2020, from https://www.washingtonpost.com/graphics/2020/business/coronavirus-recession-equality/

  3. Sep 2020
    1. Next.js is a React framework from Vercel (formerly ZEIT), and is the inspiration for Sapper. There are a few notable differences, however:
    1. for example, reactive declarations essentially do the work of React's useMemo, useCallback and useEffect without the boilerplate (or indeed the garbage collection overhead of creating inline functions and arrays on each state change).
    2. In Vue, your markup must be wrapped in a <template> element, which I'd argue is redundant.
    1. Allow creating custom components with the same abilities as native dom. By all means keep the same level of encapsulation, don't push class on components, but allow a component to mark the class property or another as a CSS Class property, in which case you could pass it through the same transformation that native elements go through
    1. I think Svelte's approach where it replaces component instances with the component markup is vastly superior to Angular and the other frameworks. It gives the developer more control over what the DOM structure looks like at runtime—which means better performance and fewer CSS headaches, and also allows the developer to create very powerful recursive components.
    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. In most component frameworks, you need to write some code to define your component. With React, the simplest component is an empty function. In other frameworks, you need to import a library and call a special function to define and create your component. With Svelte, you just create a new .svelte file.

      If you compare these two:

      • With React, the simplest component is an empty function.
      • With Svelte, you just create a new .svelte file.

      Creating a new empty function is actually easier/faster than creating and importing a new file. Because you don't have to create a new file just to create a new one-line component. You can create simple helper components within the same file as the main component they help with, and sometimes it is nice to have the flexibility and freedom to compose your files however you want, including the freedom to group multiple closely related components together in the same file.

      In fact one thing I've sometimes found very useful and handy is to be able to define very simple helper components (functions) within the definition of my main component.

      So I would actually put this comparison in the "win" category for React, not Svelte.

    1. he will crush[j] your head,(BL)    and you will strike his heel.”

      God curses the serpent after deceiving Eve in the garden, and creates "enmity between [the serpent] and the woman." In the "Harry Potter" series by JK Rowling, the serpent is a symbol of evil, and near the end of the books, is the only piece of evil left to destroy before good can truly be restored.

    1. The previous example contained a default slot, which renders the direct children of a component. Sometimes you will need more control over placement, such as with this <ContactCard>. In those cases, we can use named slots.

      This is a nicer solution than react children props, which is only clean if you pass in a single child.

      The React children prop is an unregulated wild west where people are free to use the prop almost any way they want (including passing in a function).

      I kind of like how Svelte provides a standard, consistent API, which doesn't have the limitations of React childern.

  4. Aug 2020
    1. Lozano, R., Fullman, N., Mumford, J. E., Knight, M., Barthelemy, C. M., Abbafati, C., Abbastabar, H., Abd-Allah, F., Abdollahi, M., Abedi, A., Abolhassani, H., Abosetugn, A. E., Abreu, L. G., Abrigo, M. R. M., Haimed, A. K. A., Abushouk, A. I., Adabi, M., Adebayo, O. M., Adekanmbi, V., … Murray, C. J. L. (2020). Measuring universal health coverage based on an index of effective coverage of health services in 204 countries and territories, 1990–2019: A systematic analysis for the Global Burden of Disease Study 2019. The Lancet, 0(0). https://doi.org/10.1016/S0140-6736(20)30750-9

    1. Vogels, C. B. F., Brackney, D., Wang, J., Kalinich, C. C., Ott, I., Kudo, E., Lu, P., Venkataraman, A., Tokuyama, M., Moore, A. J., Muenker, M. C., Casanovas-Massana, A., Fournier, J., Bermejo, S., Campbell, M., Datta, R., Nelson, A., Team, Y. I. R., Cruz, C. D., … Grubaugh, N. (2020). SalivaDirect: Simple and sensitive molecular diagnostic test for SARS-CoV-2 surveillance. MedRxiv, 2020.08.03.20167791. https://doi.org/10.1101/2020.08.03.20167791

    1. Aspelund, K. M., Droste, M. C., Stock, J. H., & Walker, C. D. (2020). Identification and Estimation of Undetected COVID-19 Cases Using Testing Data from Iceland (Working Paper No. 27528; Working Paper Series). National Bureau of Economic Research. https://doi.org/10.3386/w27528

  5. Jul 2020
    1. Why don't you allow a range without end, like (1..)? There are two advantages. First, we can write ary[1..] instead of ary[1..-1]. The -1 is one of the most I dislike in Ruby. It is very magical, ugly, redundant, and disappointing. I envy Python's ary[1:]. I know that ary.drop(1) is slightly fast, but too long for such a common operation, IMO. Second, we can write (1..).each {|n| ... }.