If you want a reference to the global object that works in any context, you can read this from a directly-called function. const global = (function() {return this})();. This evaluates to window in the browser, self in a service worker and global in nodejs.

If the client JS is disabled, then handleSubmit will never be executed and you have to care that your /api/fakeBackendRoute will handle the data exactly how the client would.

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.

Unfortunately it is not just the semantic that is broken. There are lot of things.For example if you look at some of the examples (https://flutter.github.io/samples/#/) - you can see that indeed there are some div and p tags but it is not entirely normal DOM elements. For example you can't even select text anywhere on the screen. And there are more and more little things like that.Just to be clear - Flutter for web is great, I'm happy it exists, but it is not comparable to React/Vue or Svelte.IMO Flutter for web is good to post live examples of Flutter code or maybe some last-minute-boss-request to make a web version of existing app, but for not for full-blown web app. :)

All projects here are completely frozen, though feel free to fork and continue using them on your own.

One last bonus: CSS variables can be written in a way that makes it easier for human programmers to understand. If you just see hex code #93e9be, you won’t know what color it produces, while --brand-green makes clear the purpose of the variable.

Fallback values aren't used to fix the browser compatibility. If the browser doesn't support CSS custom Properties, the fallback value won't help.

An additional benefit is semantic identifiers. For example, --main-text-color is easier to understand than #00ff00, especially if this same color is also used in other contexts.

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

passive: true instructs chrome that no body will call e.preventDefault() so chrome can optimized scrolling just because no body will call e.preventDefault and so there is no need to wait listeners...

@monkeythedev can your work be used already? I would suggest not yet, i'm still doing core changes every day

What was it like to be a software engineer at NeXT?

After some attempts mapping with Svelte, I missed using canvas instead of SVG

In the past, I tried to create some proof of concepts with svelte, but I usually ended up missing some of the features that RxJS provides. Now that I know that they complement each other well, I will grab this combination more often

Svelte makes the pit of success larger because it hides all of this from us at compile time.

At the start this is hard to get right, and bad practices will sneak into the codebase.

I find the binding of Mini Express pleasant.

What vaults this well past SNCF for me (setup time aside), is the limited company choice; it prevents a feedback loop of sorts where a game devolves into running each company in the ground.

Who’s Using Snowpack?

So handling the interop upfront will avoid users writing invalid ES6 and make sure that they write ES6 that loads CommonJS in the right way.

If everyone did this, the repair shops would be out of business.

While there have always been server listings on joinmastodon.org, this is a break from our previous practice of listing servers. Before the Server Covenant we pulled a list of servers from a 3rd party provider called instances.social. However, instances.social was a 3rd party and automated service. The one thing that it could not do was any kind of quality control as it simply listed every instance submitted–regardless of stability or their code of conduct. As Mastodon has grown it has become increasingly clear that simply listing every possible server was not in our interest as a project, nor was it in the interest in the majority of the communities running Mastodon.

Used by folks at

There was a major refactoring in the resolver (https://github.com/webpack/enhanced-resolve). This means the resolving option were changed too. Mostly simplification and changes that make it more unlikely to configure it incorrectly.

Bringing this back to filtering, not only am I saving time and preserving focus by batch processing both the collection and the consumption of new content, I’m time-shifting the curation process to a time better suited for reading, and (most critically) removed from the temptations, stresses, and biopsychosocial hooks that first lured me in.I am always amazed by what happens: no matter how stringent I was in the original collecting, no matter how certain I was that this thing was worthwhile, I regularly eliminate 1/3 of my list before reading. The post that looked SO INTERESTING when compared to that one task I’d been procrastinating on, in retrospect isn’t even something I care about.What I’m essentially doing is creating a buffer. Instead of pushing a new piece of info through from intake to processing to consumption without any scrutiny, I’m creating a pool of options drawn from a longer time period, which allows me to make decisions from a higher perspective, where those decisions are much better aligned with what truly matters to me.

This is the real issue here, and it's a bug with chrome devtools, fixed in Chrome 46.

If this PR merges and it has unforseen bugs / issues, I'm not sure anyone would have the time to jump in and fix it. So, that's why I'm being cautious about approving/merging it.

And the App will be responsible for display a list of users adding/removing users of said list

Tell you why tree-shaking fails, if it does.

What it doesn't do

I see this issue has 2 open PR's is this going to be finalized anytime soon?

I guess I was just waiting for some interest from a maintainer, since there's not much point in wasting my time on developing this if the maintainers aren't even interested in this feature.

Furthermore, how come there's a PR open since 3 months, at what seems to be the authoritative repo for Svelte?

There are a few intentional behavioral differences between Dart Sass and Ruby Sass. These are generally places where Ruby Sass has an undesired behavior, and it's substantially easier to implement the correct behavior than it would be to implement compatible behavior. These should all have tracking bugs against Ruby Sass to update the reference behavior.

Sass makes CSS fun again.

When you use a function like color(). it’s impossible to know exactly where it was defined. Which @import does it come from?

// replace css-loader with typings-for-css-modules-loader environment.loaders.get('moduleSass').use = environment.loaders.get('moduleSass').use.map((u) => { if(u.loader == 'css-loader') { return { ...u, loader: 'typings-for-css-modules-loader' }; } else { return u; } });

Maybe it's also a bug because every warning should be ignorable? Not sure.

Obviously we shouldn't rush into anything. But changes like these are best made earlier on in a project's lifecycle, so I'm eager to hear what people think so that we can start making some progress.

In principle, this information is already available through other means, but it is actually a fair amount of work to gather it in this form, and I think it could be useful to open it up to programmatic consumption.

Over 4 million people trust CloudApp

Looking at all those bearing, heading, orientation, navigation, position, direction, etc. I think we have a bigger problem here. Someone has decided how to use tag (e.g. orientation is about page orientation), but there are 100 other cases. Imho, to disallow misusing there should be no "heading", but rather "html-heading", "gps-heading", "whatelse-heading", which make mistakes impossible. So yes, "heading" should go.

If you have a better/simpler/"more official" solution, I'd still love to see it!

I'd be happy to take on this issue, if no one else has up to this point!

Focus on your application: forget about forms details like I'm dirty, field touched...

You can try to build a solution to tackle these issues on your own, but it will cost you time and money... why not use a battle-tested solution to handle all this complexity?

If you want to implement a form with a superb User Experience, you have to take care of many variables:

Form validation can get complex (synchronous validations, asynchronous validations, record validations, field validations, internationalization, schemas definitions...). To cope with these challenges we will leverage this into Fonk and Fonk Final Form adaptor for a React Final Form seamless integration.

Managing Form State (holding field information, check if a control has been touched, if the user has clicked the submit button, who owns the current focus...) can be tedious and prone to errors. We can get help from React Final Form to handle these challenges for us.

Unfortunately, it is an expression mired with a negative context because of how Rumsfeld used it to lie.

But it sounds like the library could use some way to setTouched()

you took 4 hours to respond, so I implemented it myself

If that one somehow ends up being deemed an intended behavior rather than a bug, then it should definitely get explained in the docs too.

I'm not sure yet how much of this is a bug.

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.

This isn't a bug. Svelte's reactivity is triggered by assignment, so it won't re-render on mutations like array pushing.

We want arr.push(foo); arr = arr; to work, and this is a bug.

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:

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

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.

Modules from the following layer can require anything from all the previous layers, but not vice versa.

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!

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.

Any software that makes HTTP requests to other sites should make it straightforward to enable the use of a cache.

Adding an API for something is an endorsement of that approach.

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.

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.

formvalidation: path.resolve

import luhn from 'formvalidation/algorithms/luhn';

The reason for this is very simple: once code gets checked-in, it takes on a life of its own.

Checking in is akin to sharing your code with others, and once out in the world, it’s hard to predict what that code will do.

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.

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.

Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.

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.

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.

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.

I wasn't aware react-hyperscript existed!

@subfuzion That error looks unrelated to the existing discussion.

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

However, in function components there really isn't much need for this pattern since you can just use JS default arguments

This is a very unusual pattern and most people don't know you can.

http://facebook.github.io/jsx/#why-not-template-literals (respectfully disagree)

code is read much more often than it is written.

With or Without ‘export’

But the vast majority of things that our apps are doing are just conditional and list rendering.

Svelte chooses a reverse approach.

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

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.

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.

When using TypeScript, cast the type of file.contents on your side.

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.

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.

The service that hosts copies of the Active Directory database are called domain controllers, or DCs

Active Directory has been used to centrally manage networks of computers

One of the most common methods for this authentication is using Kerberos.

role-based access control, or RBAC

A component shouldn’t break because it’s rendered more or less often.

Keep the local state isolated.Think about which state is local to a particular UI representation — and don’t hoist that state higher than necessary.

Even if a component is rendered just once, your design will improve if rendering twice doesn’t break it.

I'm suggesting there should be a way to write lifecycle related code that also responds to changing props, like how useEffect works. I think how React handles this could be a good source of inspiration.

While react hooks were one of the catalysts for v3 we don't agree with with the APIs or the model and won't be emulating it.

It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.

Disclaimer: I’m new to Svelte so this isn’t so much a recommendation as it is a “I guess this is a way to do it 🤷‍♂️”

I actually wasn't trying to promote this like I usually promote my articles.

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

you expect some hyperbole during these presentations and you should of course question and verify the claims being made.

helped me carve a niche for what would become SolidJS. I still see that space today, so I'm glad that I did.

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.

but everything they were doing started to make sense

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.

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.

JSX is an XML-like syntax extension to EcmaScript (https://facebook.github.io/jsx/). It is not a language or runtime.

Templates are prone to unnoticed runtime errors, are hard to test, and are not easy to restructure or decompose.

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.