vimslayer

Zero downtime deployments is not the same as zero downtime generally ever.

We deploy to production several times a day. We have an in-house product that our own emplyees use and they absolutely love that they can ask a feature in the morning and get it in a few hours (in best case scenario). That wouldn't be at all feasible if all those deployments caused errors to users. Luckily that's not a problem, because these days it's really easy to get zero downtime deployments with all this containers and "serverless" functions and whatnot.

What are you using now? I have a ThinkPad T470p and really like it. The keyboard feels really great, although the fn key placement is a bit annoying.

The thing definitely needs to be opt-in instead of opt-out. BAT just recently got some backlash when Tom Scott tweeted that (I'm paraphrasing) he doesn't really like how Brave is using his identity to collect money without his consent.

Sure, as long as the amount of those buffets stays within reasonable limits. If I stumble to a site from Google, there's no way I'm just going to register to their monthly subsciption plan, no matter how useful their content was. But if I was happy with the content, I could maybe make a one-time donation or payment.

I'm afraid that embracing periodic "buffet-style" pricing also embraces big centralized platforms, like Medium, that can provide me enough content to consume for the whole billing period and then they can distribute the profits among content creators. Maybe that could work, but I'm sure HNers have a thing or two to say about the idea of making Medium the buffet where everyone's going to eat.

I think one major issue with this is that ES basically can't break backwards compability, ever. Observables are a good example, actually. If we look at RxJS, which is sort of the inspiration behind observables I guess, we'll see that they are now at 6th major version of the library. Migration from 4th to 5th made bunch of renamings and other breaking changes, which just wouldn't work in ES. Migration to 6th includes an additional compability layer, which again would be permanent piece of bloat if it was in ES standard.

And all this while some other HNers are saying that the browsers are too complicated and its so sad that there won't ever be completely new independent browsers... :)

Most bundlers have ways of splitting the bundle into smaller pieces that can be cached (and cache-busted with the hash in filename) independently. I think that's what the parent commenter was talking about. So you don't have to choose between one huge bundle and hundreds of individual non-bundled files, with code splitting and lazy loading, you can do something in the middle and have like 3-30 "minibundles". Then, if you make a modification that only affects one of those bundles, only that bundle needs to be reloaded and others can still be served from cache.

Am I misunderstanding your comment or are you implying that the missing "pull to refresh" feature is somehow the website developers' fault?

Because it's 100% just a missing feature in Firefox mobile, there's nothing website developers should add to "make it work" on it.

A few more random thoughts that popped into my head:

Flow's Windows support is pretty buggy. We have some team members who prefer Windows as their dev machine and it looks... painful.

Flow supports the upcoming `?.` operator and overall they seem more open to introducing features that are in a development phase and might be changed/deprecated in the future. I guess it's a matter of perspective if that's good or bad, but man I'm going to be sad if we end up making the change and I have to convert all those nice and clean `foo?.bar?.baz` chains into some unreadable multiline monstrosity or calls to some random getter library.

Flow's exact object types [1] are really useful and have prevented actual bugs when used with optional properties. TypeScript's concept of "freshness" [2] does prevent many if not most of these bugs though.

[1]: https://flow.org/en/docs/types/objects/#toc-exact-object-typ...

[2]: https://basarat.gitbooks.io/typescript/docs/types/freshness....

There have been a few posts like this, and the discussion always seems to focus on plain JavaScript vs TypeScript. I'd like to see some talk about Flow vs TypeScript instead. We have what I'd call a medium-sized project (~30k loc) written with Flow and TypeScript's superior tooling is indeed attractive enough that we too have been thinking about making the switch.

Having used both, there are a few features in Flow that I'd miss. I think classes being nominal is a good approach and the ability to declare new nominal types is useful. Otherwise Flow's type system is structural, like TypeScript's. Function parameter type inference is also very nice feature, so I can make simple module- or function-local helper functions without needing to specify the parameter types explicitly. Having a syntax for specifying parameter variance allows for a more sound type system in some areas.

Performance has historically been pretty bad but it's been getting better with every release. The tooling has also seen some improvements after Facebook nuked their own Nuclide-editor project and moved on to endorsing Language Server Protocol and VSCode. It's still far, far behind TypeScript, though. It's also a bit worrying that the community seems to be getting smaller, not bigger, with posts like this popping up.

That sounds a lot like what people are saying about PHP and its newer versions. But the thing is, now that we have great alternatives (Kotlin, C#, Scala, Go, Dart...), what does Java have that those don't?

Fun fact: the line of the ad was twisted by internet people for meming purposes. The actual line is "You wouldn't steal a car".

I'm the opposite with tabs, I try to keep them as minimal and just away as much as possible. Thankfully ff is pretty customizable so my setup is fine now, but the default top bar felt just gigantic and distracting coming from Chrome.

Offtopic, but I've been wondering where people are getting all this free beer from? Where I come from beer is quite expensive.

ITT people giving completely contradictory opinions on what features markdown should or should not have.

Markdown is (relatively) simple and opinionated. If you don't like it, use a different markdown flavor or different markup language. But don't expect other people to agree with you on the superiority of that markup language, because they probably would have wanted a different one.

Are you transpiling your async functions away? IIRC there's been a lot of work on async function stack traces in V8 but it's obviously useless if they are compiled to some state machine monstrosoty before getting executed.

The parent commenter was comparing the bad UI of NoScript to the bad UI of Gmail. Seems fair comparison to me if the UIs are similar. What does JavaScript have to do with it? People are quite capable of creating bad UIs with or without JavaScript.

Just a tip in case you don't already know: uBlock Origin would allow you to permanently delete elements by a selector.

Eh, most people can do without 100% of the internet, but they don't want to. And why should they? It's easy to opt out of ads - just don't use sites that have them. But if person A wants to watch some ads in exchange of "just" entertainment (which is downplaying the importance of entertainment, but whatever), why should that bother me?

Assuming of course that person A is fully aware of what they are giving said ad company, which currently is often not the case.

I have some hobby projects that are very infrequently accessed by me and my friends andy family. Relative to their usefulness, $10/mo would be way too expensive. With S3 and lambdas, my aws bill has been more like $1 to $3, depending on traffic and amount of active side projects.

Edit: those don't include a propoer DB, though, I have been basically using S3 as the DB. Not sure how much a RDS instance or something would add to the bill.

This. So many people in this thread seem to think that an email needs to be from a Nigerian Prince to be spam.

I don't quite understand what that has to do with the parent commenter's language suggestions. Simple TCO is easy to implement in the compiler level. ReasonML, for example, is quite capable of optimizing the usual recursive fibonacci example into a while loop [1].

[1]: https://reasonml.github.io/en/try.html?rrjsx=true&reason=DYU...

Yep, Linus has been quite vocal about his distaste for GitHub pull requests.

https://github.com/torvalds/linux/pull/17#issuecomment-56546...

Class field declarations are a stage 3 proposal for EcmaScript, btw, and already supported in Chrome. So

  class Foo {
      foo;
      constructor() {
          this.foo = 42
      }
  }

Will be both valid ES2019 or ES2020 and TypeScript.

In addition to what others have said here, "peloton" also means "fearless" in Finnish.

I have no idea if or why they would've used that or if they're just referring to the cycling thing, but I guess "fearless" could also be kind of fitting for this project.

I don't think the main gripe people have with Electron has ever been performance, V8 is plenty fast after all, it's more about the memory footprint.

I agree. I'm constantly switching between Netflix, HBO and Viaplay (streaming service in the Nordics) when one of those has a show I want to watch next and the other ones don't have that exact show. I've also started to fall back to renting and (gasp) torrenting movies again because I usually first come up with a movie I want to watch and only then start browsing the services for that movie, not the other way around.

Right, because while b and c will be undefined, they are taken from an existing array, not from null/undefined. This will throw

    var [a, b, c] = null

and this (destructing a nested array)

    var [[a]] = []

the point of the "elvis" ?. operator is to make accessing properties _of_ optional values or other optional properties easier.

"Either way, I'd highly recommend just using TypeScript."

Sure, I'd recommend that too, but in this case it "only" helps us by moving the error from runtime to compile-time, nested optional property access remains ugly in the TS world, too. The ?. operator will come to TypeScript as soon as it comes to EcmaScript.

Basically, but with type safety and a decent runtime performance

That would work, but what if the `Person` type's address can also be null? The following would be an error either at runtime or - in the case of TypeScript - at compile time.

    var person = {address: null}
    var {address: {country: countryName}} = person

Luckily, we'll probably get it sooner or later [1]. There are also a bunch of typesafe getter function utility libraries that are better than nothing [2-3].

[1] https://github.com/tc39/proposal-optional-chaining

[2] https://github.com/pimterry/typesafe-get

[3] https://github.com/yayoc/optional-chain