we had to change society

For example, we might request some data from a stock exchange API, and along with our usual API parameters, we give it a callback, like ?callback=callThisWhenReady. The web service then wraps the data with our function and returns it like this: callThisWhenReady({...data...}). Now as soon as the script loads, your browser will try to execute it (as normal), which in turns calls our arbitrary function and feeds us the data we wanted.

It’s all very well telling Canonical what to do, but someone needs to pay those developers for their time. It’s not free.

Repeatedly posting in this thread that there are problems, won’t actually get anything fixed.

The best place to let the developers know, and track those bugs is in the bug tracker. There are hundreds of forums online, all over the place in many languages. We can’t be expected to read all of them. Anyone with a launchpad ID (thus, anyone who has an account on this discourse instance) has the capability to file a bug. I’d strongly recommend doing so, for each specific issue. Taking just a few minutes to do that will help tremendously.

Just saying “snaps are slow” is not helpful to anyone. Because frankly, they’re not. Some might be, but others aren’t. Using blanket statements which are wildly inaccurate will not help your argument. Bring data to the discussion, not hearsay or hyperbole.

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.

Only folks who help package Chromium get to decide how Chromium gets packaged. This gives anyone two options: You can get involved and help package Chromium so you have a voice in the decision-making, or not.

Get back to Chromium : how its evolution will be handled by Debian ? How its cousin-sister-child projects will be handled ( vivaldi, brave, electron… ) ?

They may skim books for what they’ll “need to know.” They’re less likely to wonder, say, “How can we be sure that’s true?” than to ask “Is this going to be on the test?”

Explained: Reason for the “The following packages have been kept back” error and how it was fixed The above suggested fix should solve the problem for you. But are you curious what caused the error and how was it fixed? Let me explain that to you. Normally, when you run the sudo apt update and sudo apt upgrade commands, it updates all the installed packages to their available newer versions. However, if the dependencies of an installed package have been changed such that it requires installation of new packages, the installed package won’t be upgraded with the system update and you’ll see package kept back error.

but you're probably better off learning a bit more about APT and resolving the dependency issues "by hand" by installing and removing packages on a case-by-case basis. Think of it like fixing a car... if you have time and are handy with a wrench, you'll get some peace of mind by reading up and doing the repair yourself. If you're feeling lucky, you can drop your car off with your cousin dist-upgrade and hope she knows her stuff.

Small components can set the size of their corner shape using a percentage of the absolute height of the component. This means the corner shape will change as the component height changes.

Dialogs use text buttons because the absence of a container helps unify the action with the dialog text. Align text buttons to the right edge for left-to-right scripts.

Text buttons are often embedded in contained components like cards and dialogs, in order to relate themselves to the component in which they appear. Because text buttons don’t have a container, they don’t distract from nearby content.

The trouble with leaving the verb off is that if a user experiencing low or no vision is browsing with the aid of a screen reader, they may not be able to determine what the noun is for. Screen readers can scrape the current page and create lists by content type (headings, links, buttons, etc.) for easer navigation. Static text that is placed in visual proximity to the download links will not come along for the ride if accessed via this method. While it might seem redundant to show the word “download” over and over again, including it can go a long way to providing context for users navigating without visual aids, or who have zoomed the page’s content to the point where the layout may not communicate the visual relationship.

What if your download UI element isn’t just for a single static asset, but is actually generating a custom file when you press it? For example, if you have a list of files, you can check as many as you want, and pressing a download UI element zips those files together and then downloads that one file. In this case, we’d be using JS anyway, and the UI element is triggering more than just the link, it is ‘performing actions’, so a button would make sense, right?

One lesser-appreciated user-behaviour is when a user would like to choose an alternative download location. On a download link, your user can right-click -> “save link as…” and place the download directly into a folder of their choice. Handy if you want something to go directly to removable media, for example. On a download button, there’s no such option.

We can lay blame for this semantic drift squarely at the feet of trend. Designers and developers eager to try the latest and greatest invite ambiguity in with outstretched arms. Leadership chases perceived value to stay relevant.

Some may feel that the presence of the download attribute is redundant when applied to links the browser already knows to store. I disagree.

However, the W3C provides us with an important clue as to who is right: the download attribute.

The debate about whether a button or link should be used to download a file is a bit silly, as the whole purpose of a link has always been to download content. HTML is a file, and like all other files, it needs to be retrieved from a server and downloaded before it can be presented to a user. The difference between a Photoshop file, HTML, and other understood media files, is that a browser automatically displays the latter two. If one were to link to a Photoshop .psd file, the browser would initiate a document change to render the file, likely be all like, “lol wut?” and then just initiate the OS download prompt. The confusion seems to come from developers getting super literal with the “links go places, buttons perform actions.” Yes, that is true, but links don’t actually go anywhere. They retrieve information and download it. Buttons perform actions, but they don’t inherently “get” documents. While they can be used to get data, it’s often to change state of a current document, not to retrieve and render a new one. They can get data, in regards to the functionality of forms, but it continues to be within the context of updating a web document, not downloading an individual file. Long story short, the download attribute is unique to anchor links for a reason. download augments the inherent functionality of the link retrieving data. It side steps the attempt to render the file in the browser and instead says, “You know what? I’m just going to save this for later…”

What best describes a download? Is it a triggered action, and therefore should be in the domain of the <button> element? Or is it a destination, and therefore best described using an <a> element?

The only solution that I can see is to ensure that each user gets their own set of stores for each server-rendered page. We can achieve this with the context API, and expose the stores like so: <script> import { stores } from '@sapper/app'; const { page, preloading, session } = stores(); </script> Calling stores() outside component initialisation would be an error.

Preload functions are typically used to load data that the page depends on, hence its name. This avoids the user seeing the page update as it loads, as is typically the case with client-side loading.

# fix a bug in one of your dependencies vim node_modules/some-package/brokenFile.js # run patch-package to create a .patch file npx patch-package some-package

Maybe something more neutral just meaning a virtual element / no-element container would better express the intention? And regarding the syntax, maybe it would also feel less repetitive / boilerplaty than <svelte:slot slot="name" />... Maybe something like <svelte:fragment slot="name"> or <svelte:virtual slot="name">?

Also agree that <svelte:slot> is perhaps a little confusing since it replaces the slot attribute rather than the slot element, so <svelte:fragment> would make more sense

Just to reiterate the discussion on the RFC, there was a suggestion that we change <svelte:slot slot="foo"> to <svelte:fragment slot="foo">, since it's the counterpart to a <slot> rather than an equivalent to it

customizable communities that feel good

It’s worth mentioning that Svelte limits its scope to being only a UI component framework. Like React, it provides the view layer, but it has more batteries included with its component-scoped CSS and extensible stores for state management. Others like Angular and Vue provide a more all-in-one solution with official routers, opinionated state management, CLIs, and more. Sapper is Svelte’s official app framework that adds routing, server-side rendering, code splitting, and some other essential app features, but it has no opinions about state management and beyond. Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.

Regardless of measurable impact, Svelte resonates with our emotions and it makes for a good story.

but really, the whole is what feels so good.

Making UIs with Svelte is a pleasure. Svelte’s aesthetics feel like a warm cozy blanket on the stormy web. This impacts everything — features, documentation, syntax, semantics, performance, framework internals, npm install size, the welcoming and helpful community attitude, and its collegial open development and RFCs — it all oozes good taste. Its API is tight, powerful, and good looking — I’d point to actions and stores to support this praise, but really, the whole is what feels so good. The aesthetics of underlying technologies have a way of leaking into the end user experience.

A listener watches for an event to be fired. For example, a KeyListener waits for KeyEvents, a MessageListener waits for messages to arrive on a queue and so on. The handler is responsible for dealing with the event. Normally, listeners and handlers go hand-in-hand. For example, the KeyListener tells the ExitHandler that "the letter Q was pressed" and the handler performs logic such as cleaning up resources and exiting the application gracefully. Similary a ButtonClickListener would tell the same ExitHandler that the "Exit button was clicked". So, in this case you have two different events, two different listeners but a single handler.

The most basic difference is the association Listener is associated with Event Source (Ex: key board) Handler is associated with an Event (Ex: keydown)

Trying to find a new day job is full-time work

Please use a sanitize library, like DOMPurify (recommended), sanitize-html or insane on the output HTML!

There's a huge area of seemingly obvious user-centric products that don't exist simply because there isn't a working business model to support it.

No program is an island. Every program has to hook into the operating system at some point, if nothing else.

Svelte by itself is great, but doing a complete PWA (with service workers, etc) that runs and scales on multiple devices with high quality app-like UI controls quickly gets complex. Flutter just provides much better tooling for that out of the box IMO. You are not molding a website into an app, you are just building an app. If I was building a relatively simple web app that is only meant to run on the web, then I might still prefer Svelte in some cases.

That’s how developers create buttons — they add padding to their div containers, not heights.

You should always take the line hight of the font you are using and add a unit to it. For example: “My button’s label has a line height of 20px and vertical padding of 8px”.

Choose sentence case or title case over uppercase. (This being said, Material Design does use buttons with uppercase labels.)

For use$ since svelte is never going to support actions for components, i designed something that reminds React hooks that will in some ways replace this feature.

from my point of view, it is (by far) the best way, to build a layer on top https://github.com/material-components/material-components-web . This is also the path that the Angular Material team has taken, although they have already made a huge effort to create the components themselves.

As mentioned in #2937, this is the sort of thing that happens when you have two copies of Svelte's internal scheduler running. If you're importing the compiled version of an external Svelte component into another Svelte component, this is what you end up with. There's a svelte field in package.json that's respected by rollup-plugin-svelte and which is intended to point at the uncompiled Svelte source, so that the external component can be bundled together with the main app, without any duplicated internals.

is not required to point to "svelte": "src/main.html" if you're bundling for es, "module": "dist/main.mjs" would suffice. I mean, it's a good thing to provide a single file, not the whole sources again.

positive feedback loops, in which a change in a given direction causes additional change in the same direction.For example, an increase in the concentration of a substance causes feedback that produces continued increases in concentration. negative feedback loops, in which a change in a given direction causes change in the opposite direction.For example, an increase in the concentration of a substance causes feedback that ultimately causes the concentration of the substance to decrease.

Addition; Please add this variables to environment if you don’t want to change code. This is a better option. Add RAILS_ENV=production , NODE_ENV=production, RAKE_ENV=production

By default the current directory is used, but it's recommended to pass a value in your configuration. This makes your configuration independent from CWD (current working directory).

Linear mixed models are an extension of simple linear models to allow both fixed and random effects, and are particularly used when there is non independence in the data, such as arises from a hierarchical structure

You may not want to go straight to that number and cause the kernel to allocate memory to track a million user file watch slots; instead, just take the current value and double it until the problem stops occurring.

Never use x && y || z when y can return a non-zero exit status.

Man, for some reason, I really like this answer. I recognize it's a bit more complicated, but it seems so useful. And given that I'm no bash expert, it leads me to believe that my logic is faulty, and there's something wrong with this methodology, otherwise, I feel others would have given it more praise. So, what's the problem with this function? Is there anything I should be looking out for here?

If you were to check the return status of every single command, your script would look like this:

true && { echo true; false; } || { echo false; true; }

true && ((i++)) || ((i--))

obviously it's too late, but it's a good practice to keep the 3rd party dependencies mirrored in your own infrastructure :) There is NO GUARANTEE that even a huge site (like launchpad for downloading DEBs) won't go down over a period of time.

docker build --cache-from=base_image:2.2.1,custom-gource:0.1 . -t custom-gource:0.2

So let's say we pull down evil/foo which is FROM ubuntu followed by RUN apt-get update except with a small surprise included in the image. Subsequent builds using those same commands will be compromised.

which are passed onto controller actions.

With the advent of JavaScript modules (import and export), it's possible to build libraries that are tree-shakeable. This means that a user of your library can import just the bits they need, without burdening their users with all the code you're not using.

Avoid transpilers like Babel and Bublé (and if you're using TypeScript, target a modern version of JavaScript)

Don't create instances of things on initial evaluation — instantiate lazily, when the functions you export are called

this is the problem with that method.

I would suggest that if you want the behaviour you get when you specify initial-scale=1, then specify initial-scale=1.

I wondered about that. But as you mention, the control flow makes it tricky, because it's not really a template literal — it's a DSL. I thought perhaps it's better to have something that's explicitly different, than something a bit 'uncanny valley'.

That said, supporting this syntax on elements as well as components could make sense.

Decode of jq command:

Start by reading this post (Final Form + Fonk)

The most dangerous kind of assumption is the one we don’t know we have. In Rumsfeldian, that’s an “Unknown unknown.”

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)

This is a philosophical issue, I think. People (and presumably form libraries) have different definitions of what "dirty" means. Yours: "The field has ever been edited" Mine: "The value of the field is different from the initial value"

I too have been confused by behavior like this. Perhaps a clearly defined way to isolate atomic units with synchronous reactivity would help those of us still working through the idiosyncrasies of reactivity.

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.

But for big projects it should work out to just apply this techniques to certain sub-folders in your project where this problems occurs, as-if they are stand alone libraries.

Examples of this include: requiring base classes or reading from imported variables that have not been initialized yet.

as soon as you have a (indirect) circular dependency, you might be interacting with a half loaded module in your code.

Replaced nested `require` statements with `import` declarations for the sake of a leaner bundle. This entails adding empty imports to three files to guarantee correct ordering – see https://github.com/styled-components/styled-components/pull/100

Restart from scratch. Create a new program, adding in only what is needed to see the problem. Use simple, descriptive names for functions and variables – don’t copy the names you’re using in your existing code.

Divide and conquer. If you’re not sure what the source of the problem is, start removing code a bit at a time until the problem disappears – then add the last part back.

But many of these systems continue to re-request the same DTDs from our site thousands of times over, even after we have been serving them nothing but 503 errors for hours or days. Why are these systems bothering to request these resources at all if they don’t care about the response?

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...

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.

Returns a Promise<?Object> that resolves with no value on success or resolves with an Object of submission errors on failure. The reason it resolves with errors is to leave rejection for when there is a server or communications error.

Wondering how to get field state from multiple fields at once? People coming from Redux-Form might be wondering where the equivalent of Redux Form's Fields component is, as a way to get state from several fields at once. The answer is that it's not included in the library because it's so easy to write one recursively composing Field components together.

You can think of this as a single speaker talking at a microphone in a room full of people. Their message (the subject) is being delivered to many (multicast) people (the observers) at once.

One of the significant differences between the two is that a call to a partially applied function returns the result right away, not another function down the currying chain; this distinction can be illustrated clearly for functions whose arity is greater than two.

As such, curry is more suitably defined as an operation which, in many theoretical cases, is often applied recursively, but which is theoretically indistinguishable (when considered as an operation) from a partial application.

Also, if you don't put that implementation of URLSearchParams in the global scope you're not using it as a polyfill but a ponyfill, and those are meant for your code, not for external dependencies.

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.

Once again, this isn’t good or bad, it’s just the most efficient way to create something that is similar to something else

This isn’t to say that multiplying code is good or bad – it’s a characteristic of all code regardless of quality.

For years, I’ve shared with friends and clients what I call the bunny theory of code. The theory is that code multiplies when you’re not looking, not unlike bunnies that tend to multiply when you’re not looking.

Not all application state belongs inside your application's component hierarchy. Sometimes, you'll have values that need to be accessed by multiple unrelated components, or by a regular JavaScript module.

A store is simply an object with a subscribe method that allows interested parties to be notified whenever the store value changes. In App.svelte, count is a store, and we're setting count_value in the count.subscribe callback.

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.

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

andrewdeandrade commented on Jul 31, 2015

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.

Supporting JSX out of the box is the engineering equivalent of Mozilla supporting DRM out of the box in FireFox.

I agree that "it feels gross" is a bad reason. "not paving a bad cowpath" is a much better reason.

Create HyperText with JavaScript

const { getByRole } = render(<input bind_value={text}>)

const { getByRole } = render(html`<input bind:value=${text} />`)

render(html`<${Button} on:click=${() => (clicked += 1)}>Click Me!<//>`)

debt ... which is not a straight bad thing but something that could provide some "short term financing" get us to survive the project (how many of us could afford to buy a house without taking out the mortgage?).

Right, and if most uses of an FTP service use new FtpService() the one that sets an alternate port will stand out (service.SetPort(12345))

Good risk management is inherently simple; adding too many complexities increases the likelihood of overlooking the obvious.

by using tagged templates we can inline function calls

require('modules') in the browser

Use a node-style require() to organize your browser code and load modules installed by npm.

Encoding examples:

Escaping is a subset of encoding: You only encode certain characters by prefixing a special character instead of transferring (typically all or many) characters to another representation.

Escaping is a subset of encoding, where not all characters need to be encoded. Only some characters are encoded (by using an escape character).

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.

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.

Why not Template Literals?

Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.

A program somewhat controlling it's own flow. That's the key feature that makes a programming language Turing complete.

Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough

Moreover, React team even removed the “highlight updates” feature from dev tools because people used to obsessively haunt wasted renders with no reasoning behind it

This would be like an executable proposal. I understand that it's beyond the original intent of having canonical patterns on the Svelte site, but it would facilitate the community to express their own patterns. Now that we have markdown preprocessors , the documentation itself can be an app.

I'm suggesting that the cookbook apps be self-contained & forkable. 3rd parties could host their own cookbook recipes, possibly using a forked cookbook from an already established pattern.