ianstormtaylor

I think you're right, and that that be great in my opinion. I'd love for this to be the start of Google being less dependent on ads across some of their currently free products. If a "Google One" subscription guaranteed that Gmail and other services were no longer mined for ads, that would be a great thing. It might allow them to maintain the ads-based model for free users, while providing a single subscription for people who are willing to pay. In a way that offering subscriptions for each individual product wouldn't be feasible due to the complexity of marketing/managing so many at once.

I agree. If it is their attempt at "Prime", they're going to have a much harder time of it than Amazon, since they already have so many different subscriptions and price points. It'll be interesting to see how they try to manage it.

Not only that, but they'll have to decide where the borders of the subscription are—is YouTube a separate entity, and thus should keep it's own subscription model? or is it too valuable and thus should be part of Google One? Either direction will have complexity issues, either in continuing to have too many different subscriptions, or in trying to capture value with too many orthogonal benefits in a single pricing system.

I think this article is missing the bigger picture—this isn't about storage. This is Google trying to copy the success of Amazon Prime.

They're going to try to unify lots of different benefits under a single, high-value subscription. The storage plans and priority support are just the first benefit they've tied to the subscription.

> In addition to access to experts, the company also promises to provide subscribers with other benefits. Google One’s director Larissa Fontaine told me that those could include discounts on hotels you find in Google Search, preferred rates for other Google services or credits on Google Play. “We hope to build those out over time,” she noted.

That would make more sense as to why they're "rebranding" these plans an not just updating Google Drive's pricing plans. "Google One" isn't a single product, it's a single subscription across many products, just like Amazon Prime.

Of course, I could be wrong.

It does seem like a weird way to launch the subscription if that's what they're trying to do, since the announcement goes deep into the weeds of storage. And the low-end plans seem much too cheap to be able to add meaningful benefits to in the future.

Even the idea of multiple tiers of the subscription might be too complicated. One of the nice things about Prime is that although it's expensive, there's only one option.

Seeing as this is Google we're talking about, I could imagine this new subscription will have incredible amounts of churn in branding, pricing and benefits along the way, and probably end up as a confusing mess in the minds of customers. Amazon's Prime took a very different route. It started out as a very clear subscription service for cheaper shipping, and then added more and more benefits as time went on. These days it's a little confusing, but it didn't start that way. If Google already can't get the messaging to be clear, it doesn't bode well for them adding lots of orthogonal benefits in the future and keeping it all sane.

I bet we'll see a Stratechery article about Google One in the context of Amazon Prime soon.

Thanks! Glad to hear it :D happy to answer any questions if you do.

That makes sense re: teams, thanks!

Do you have any info on what makes the teams concept better than those in Notion / Google Docs / Paper?

I also have the vague feeling that those tools have hard to understand team permissions, but I'm unclear on how Slite solves this in a better way. Either way, sounds interesting. Congrats on the launch!

This.

The article should be flagged off the front page or edited by the mods to show that it's questionable.

This is a single person's test results, across versions that are known to have touched the battery/CPU slowdown logic, showing insane performance degradation across almost every aspect of the phone... it's super questionable. And right now it's #1 on HN despite all of that, just spreading misinformation.

What are HN's impressions of WeWork? I haven't rented one myself, but everyone I talk to seems to say think that they're expensive, that the environment creates a super distracting workplace, and that they only make sense for tiny teams or freelancers who want to meet people.

It feels like you didn’t read the article.

The author made clear multiple times that they were using cron jobs as a test bed for Kubernetes, and they chose to “overengineer” because they’re looking to use Kubernetes for more and more of their needs over time. You’re kind of arguing against a straw man.

I think it’s actually a great example of how Stripe thinks about technology choices.

They’re interested in choosing fewer tools that are better built and can grow to solve more needs. And they’re evaluating tools not just by “time to complete X random project”, but by other longer-term heuristics like maintenance levels. And the best way to do that is to start using the tool for a single need, investing more time in learning/research than is required for the need itself—ensuring that it really is a solid, foundational solution—with the understanding that you’re choosing technology for the long run. Then continue to expand your use of the tool over time, reaping benefits on your initial time investment.

How does this compare in file size to Moment? That's the only real issue I have with it.

If you haven't watched it before, I'd recommend "Simple Made Easy" by Rich Hickey. [0]

The reason I say that is because you say "conceptually simple" as if that's a bad thing. Maybe we have to agree to disagree, but in choosing a framework I would much, much rather go for the one that is conceptually simple (at the cost of some extra verbosity in certain cases) over one that is conceptually complex but covers up that complexity with a terse-but-incomplete API.

You're not going to understand the benefits of the Vue vs. React choice by looking at idealized code samples, which is all your comment is showing. You'll only know it once you get into the edge cases. For example for list iteration in Vue...

- ...how do you change that example to omit the last item?

- ...how do you change that example to render a different element for every other item?

- ...how do you render something different if there are no items?

That's what makes the JSX approach simple. Once you understand that you can use any Javascript expression you want, you don't need to learn further. All of those questions can be guesstimated by a newcomer.

But with Vue you have to learn each and every "directive" and "modifier", and consult the docs again each time you forget them.

[0]: https://www.infoq.com/presentations/Simple-Made-Easy

Which way are 90% of the Vue components, applications and examples written with?

The learning curve is only one place the choice ends up being worse. (Just read the Vue docs to understand.)

The other is that you now have "directives" that are defined elsewhere, in other files, that are included into templates via strings, instead of anything that is easily statically (or quickly) analyzable. Some of these directives ship with core, but some are third-party, so you have to remember which is which, and which your team has added.

But that's not it, those "directives" can have "modifiers" that can augment the already blackbox directives however they want.

Not only that, but it seems that bindings can actually execute arbitrary Javascript as expressions. Which is great, except apparently you can do that in strings too, so you end up writing code like:

    <div v-bind:id="'list-' + id"></div>

Now you're basically writing JSX, you're just doing it all inside of strings that are hard to lint, analyze, etc in the HTML attributes of your templates instead.

It all adds up to lots of redirection and re-inventing the wheel, when you could just be using Javascript itself. (Although I'm sure there's _way_ less redirection than Angular.)

> Adwords for Outdoor and Transit Advertising

> Billboards are still sold manually by sales teams. You literally cannot buy a billboard online. If people could buy them as easily as you buy an Adwords ad, maybe many more small companies would.

It's interesting how these ideas continually arise. And as described it seems like a virtuous idea. By solving the scaling issues of the marketplace, smaller and smaller companies can buy ads. Which is good because it evens the playing field and reduces monopolistic behaviors, making the market more free.

But by solving those scaling issues, you'd also be making it easier for bad actors to buy advertisements. (In this case huge billboards.) And without collecting a _lot_ more data, or allowing a company to policy free speech, there would end up being much less accountability for who is buying the advertisements, and who is seeing them. You end up with the same situation Facebook, Google and Twitter are answering for in Congress right now. [0]

I don't have a solution, other than to stop building these types of marketplaces, but it is disconcerting.

We keep creating systems that have positive benefits, but at the expense of rarer-but-huge negative consequences, that are often "solved" by infringing more and more on our privacy to prevent the black-swan events from occurring.

PS. If anyone has interesting reading along these lines, I'd love to hear it.

[0]: https://stratechery.com/2017/tech-goes-to-washington/

(Not familiar with Vue.)

When you talk about "template syntax" and "directives and filters" are those a non-full-JS-style of templates? As in can you execute arbitrary JS like you can with JSX? Just curious.

For me JSX is one of the biggest reasons that React is much, much better than Angular. I've found that once you get into re-implementing for loops, if statements, fallback defaults, etc., etc., for the sake of templating in an entirely new DSL, it becomes super complex and hard to learn/remember.

Very simple, but really cool. Well done!

Hey @zeveb, I appreciate the response!

But the grandparent actually mentions the short-lived approach, and is asking about cases where you want to have longer-lived tokens. And where you still want to be able to revoke them.

Stateless tokens can definitely speed things up. But if you end up needing to add state back into the equation for revoking tokens, then I'd argue that most web apps would be better off sticking with the much simpler mental model of non-stateless tokens. That is, until they decide that their lowest-hanging performance fruit is the extra validation work, and that it's worth complicating their architecture to remove it.

I think this is the biggest drawback to "stateless" JWT's that most people gloss over when championing. If you need to be able to revoke stateless JWT's, you probably shouldn't be using stateless JWT's in the first place, because you'll have to re-add state to the system to handle revocations. And at that point why not just go with the simpler mental model in the first place.

And since giving users (or you) the option to "log themselves out of other computers" on a fine-grained basis is often an important feature to provide, it essentially means stateless JWT's aren't a great solution for sessions in most web apps.

That's just what I've gathered personally. If anyone has a counter argument for this case I'd love to hear it!

A few more for your list: dataloader, draft-js, express-graphql, regenerator, relay, yoga

There are other popular Javascript packages that aren't mentioned:

    dataloader
    draft-js
    express-graphql
    flux
    graphql-js
    regenerator
    relay
    yoga

They'll probably stick with BSD+Patents, unless the pressure is kept on, which is unfortunate.

I'm curious, if you're willing to share, what were the projects you worked on that failed?

I don't think this question makes sense.

Netflix is clearly a "technology + entertainment" company.

The "technology" distinction isn't mutually exclusive with another vertical—exactly the opposite. Companies can outmaneuver competitors by applying "technology" to a specific vertical. The reason Netflix has been able to crush competitors is both because they get entertainment AND because they get technology.

The only pure "technology" companies I can think of are developer tooling products, or research labs.

Always excited to hear Stripe talking about versioning :D

For anyone else who's interested, they've written/talked about this a few times over the years, to fill out the picture:

- http://amberonrails.com/move-fast-dont-break-your-api/

- https://www.heavybit.com/library/video/move-fast-dont-break-...

- https://speakerdeck.com/apistrat/api-versioning-at-stripe

- https://brandur.org/api-upgrades

- https://news.ycombinator.com/item?id=13708927

It sounds like their YAML system has changed to be implemented in code instead, which maybe allows the transforms to be a bit more helpful/encapsulated. If anyone from Stripe is here, it would be awesome to know if that's true and why the switch?

And it looks like just today Atom has another release (1.19) that supposedly helps performance for large documents: http://blog.atom.io/2017/08/08/atom-1-19.html

Does anyone have a link to better explanation of the changes to `debugger`?

> The legacy command line debugger is being removed in Node.js 8. As a command line replacement, node-inspect has been integrated directly into the Node.js runtime. Additionally, the V8 Inspector debugger, which arrived previously as an experimental feature in Node.js 6, is being upgraded to a fully supported feature.

It sounds like `node debug` will no longer work? But it is replaced with something that's better? What is `node-inspect` and where can I learn about it?

If you use Heroku for production, using it for CI too means that a lot of the annoying configuration pieces involved in getting CI to match production exactly disappear.

In my opinion CircleCI's configuration UX is actually really poor—compared to what it could be, and what Heroku provides.

In CircleCI, you're configuring against a moving target installation of binaries, and whenever CircleCI decides to upgrade Postgres or Redis or whatever, your tests start failing and you don't know why. Then you have to try to figure out how they've configured the services, and what it will take to use Postgres 9.5.3 instead of 9.6.1—big hassle.

Then there's the little UX things—in CircleCI you can't read the config vars you've set previously from the interface, which means you have to go through the super tedious process running a new build, SSH'ing into it, and then reading them from there, just to remember what user your Postgres connection URI uses.

On top of that CircleCI's documentation is much worse than Heroku's, so re-learning how to do all the random configuration things you need to do each time is more difficult than it could be.

I think anything that reduces time spent messing with CI servers is a big plus, because that work is usually the most frustrating work there is. $10/mo is nothing compared to wasting a day dealing with CI configuration every once in a while.

Just wanted to say that for a project started on Friday, (or really any project), the readme is really well done!

What are the differences between Apollo and Relay Modern at this point?

Why/when should you choose one over the other?

Flagged.

This is obviously just poorly written clickbait to piss people off. Unicorns shouldn't be worried about Uber's down round unless they have as many skeletons in their closet as Uber does. Apples to oranges. I think Uber is a horrible company, but I also don't think that random clickbait should be getting up the ranks on HN.

Agreed! (Author here.)

I had originally started with just the few I'd used or researched in the initial stages. But folks opened issues in Slate asking for more comparisons, so I tacked on other libraries that people were interested in comparing. But I should really move those other libraries to another page in the docs somewhere with a better disclaimer.

Hey, author here, good question!

I'd guess that there are definitely some x-browser issues with Android right now because I haven't tested there at all. So far I've been working on the core pieces of the library, and making sure desktop works. A few folks have contributed iOS fixes for things like autocorrect. I'd love for any contributions that make things work better on Android! (Or other platforms.)

Thanks!