Frizi

There is an equivalent syntax in Rust to both of those examples, and in both cases I find it less verbose. The template variant is roughly equivalent to:

    fn func<T: FloatingPoint>(fp: T) { ... }

And the "auto" variant is similar to impl argument in Rust:

    fn func(fp: impl FloatingPoint) { ... }

From your description, it sounds like they decided to use a "number" typed field for the post codes. This is of course incorrect, post codes are really just strings. While the bug manifests itself on firefox, it is hard to blame it for implementing the field according to spec [1]. Chrome decided to ignore the spec and leave the field more free-form, which in turn enables developers to use it incorrectly without detecting the compatibility bug.

[1]: https://www.w3.org/TR/html52/sec-forms.html#number-state-typ...

> User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number. If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user’s selection as a floating-point number.

Electron is pretty much the same nightmare anyway. Just because it runs in chromium doesn't mean it preserves the sandbox. All electron apps have full access to your filesystem and os, even from their chromium window context.

Fuzzing isn't really practical if all you do is just generate a totally random bit stream for input. There are many much more clever and robust strategies to hit as many edge cases as possible. Check AFL[1] for some details on generating smart random input files. You can also combine that with pretty advanced dynamic execution analysis to fuzz against unknown processor instruction sets, like in sandsifter[2].

[1]: http://lcamtuf.coredump.cx/afl/

[2]: https://github.com/xoreaxeaxeax/sandsifter

Well, the support is pretty decent in evergreen browsers (and it already was for a while), and in case of electron, you have precise control over your runtime, so it's not really a problem. Also many engines have already done quite substantial optimizations for handling wasm modules in combination with JavaScript. It's all done with backward compatibility in mind, so what works today will continue to do so.

There exist a great one, which is called Figma. They use electron in combination with WebAssembly to make it fast. I'd say that's a pretty decent choice.

There is also Figma, which is a direct competitor to sketch that is multiplatform, and they indeed run on electron (and even directly in browser). For me that's a great example of electron app done right, as you won't really notice any performance issues.

The "need more pixels" message is quite frustrating. I get that it might be not practical to support small resolutions, but I was unable to see the demo even on "desktop mode" in landscape on a really big phone. How many pixels do you need? If it's still not practical to support that, a demo video player would be a great fallback.

The DNT header reminds me of evil bit RFC [0]. It was funny back then, but times change I guess.

[0] https://www.ietf.org/rfc/rfc3514.txt

VSCode is indeed awesome for Vue. It supports pretty much any lang in any block properly, due to its support for embedded language contexts. If you have template lang="pug" and pug grammar plugin, it just picks it up. Also Vetur extension adds a lot of autocompletes and typescript support.

Which in turn JIT compiles the code down to your specific hardware, possibly doing some extra optimizations along the way as it cares only about a single processor at a time. I do think languages like Rust are really superior to what we have in JS land, but the VMs there are truly a marvel of modern engineering.

Or, you know, just use GraphQL as your protocol and be done with this. Everything that's problematic in REST is clearly specified here and stays very easy to use. You can focus on real problems from now on.

If you want to work with REST APIs, it might be good for you to create a SPA application. The easiest thing to start seems to be Vue right now. With vue-cli with it's build command.

https://github.com/vuejs/vue-cli/blob/master/docs/build.md

Just create a single `.vue` file, run it with `vue build file.vue` and you can immediately just start hacking around. It can be even built that way for production.

Feels simple like in the old days with single index.html, but you aren't missing any features of modern frontend stack.

If you need a frontend developer to realize your idea, become one or change the idea. There are many people who like to code just for fun, but they have plenty of ideas already. In the end time is the most limiting factor for many of us. You have to pick what are you using that time for very carefully.

Not really. Diffing and rendering still cost a little, and pointless renders that results in zero differences often indicate a possible performance problem. This tool highlights such situations. If there is no difference after an action, it shouldn't happen.

You should check out Vuelidate. It tries to avoid any extra fluff.

Disclaimer: I'm one of the authors

That's what CDNs are for. If you control your proxy, nothing prevents you from giving it access to your https by setting up your private key on it. Https is also tapable, but only by servers you trust.