3 ms·

I see the point but I don't agree with the author. If I'm not mistaken that it took more than two years just to build their product and they're still pivoting i

I see the point but I don't agree with the author. If I'm not mistaken that it took more than two years just to build their product and they're still pivoting in a way that they can monetize their users. I'm not actually sure if this delay is caused by your minimalism approach but startups usually need to focus on their core business in order to be able to find the product-market fit. In an ideal world, we should be focusing only on our core business, not the tooling around the product. OK, you just set up a hook for your error events in your front-end code that lets you collect the errors as events but Sentry is doing much more than that. If it is the only feature that you need, that's OK but the reality is that as your application code grows, you will need many more features for your error tracking. Eventually, you will need the UIs that lets you understand the context of the user, aggregate multiple events as one exception, send the errors to the relevant people, etc. and you will spend much more time building out these features and the switching cost to a real error tracking tool will be much higher. The tools such as Sentry and Google Analytics provide an opinionated way to accomplish specific set of tasks for typical use-cases. The advantage is that they have seen many customers, use-cases and edge cases so adopted their product in order to cover them all. You don't need to the same unless it's your core business.

cpfohl 7y ago
Yeah, I came in here to call out the error tracking use case...a good error tracker needs to do a _lot_ more than that.
- anderspitman 7y ago
  Good for all projects, but how much does the project at hand actually require? And adding dependencies later is a lot easier than removing them.
- volument 7y ago
  I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
  - cpfohl 7y ago
    Yeah it needs to do that, but that likely means that deploying a particularly egregious bug will fill your inbox with repetitive and useless data. It should also give you information on the current user, the browser, locale, etc. None of that extra stuff is really extra, it's critical for quick debugging. It's also hard to get right, and doesn't preclude inbox zero in any way.
    - volument 7y ago
      Internally we use Redis sorted sets to merge the errors into one entry on the inbox. We get the browser info from server HTTP headers. It's a cute list of errors that we regularly run trough.
      - buremba 7y ago
        Well, your error tracking solution is not simple as a javascript snippet then.
smolder 7y ago
I think you're right generally, but not universally. There are cases where it makes sense to use a one size fits all dependency and cases where it doesn't. I think the author is right that at least some of the time, it's better to DIY certain features at the risk of needing more work later than to pull bloat into a project. Responsiveness matters for how polished an application feels. Someone web browsing with an i9-9900k computer and gigabit fiber won't notice at all, others will to varying degrees. Some people rely on Hughsnet satellite because no one will run cable to them and cell service is crap. It's my experience that people like that with slow connections or slow hardware have to frequently endure garbage-tier UX because developers preferred overwrought 3rd party tools to rolling their own features, to no apparent benefit. (Dev time included in some cases) Even in the middle ground, 300ms vs 150ms matters. While "disadvantaged users" may not seem like a low hanging fruit to go after, If you impress someone like that in your audience, standing out as having more polish than usual on your product, they'll assume the best about your engineering ability and maybe even turn into a grassroots marketer for you.

cpfohl 7y ago

Yeah, I came in here to call out the error tracking use case...a good error tracker needs to do a _lot_ more than that.

anderspitman 7y ago
Good for all projects, but how much does the project at hand actually require? And adding dependencies later is a lot easier than removing them.
volument 7y ago
I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
- cpfohl 7y ago
  Yeah it needs to do that, but that likely means that deploying a particularly egregious bug will fill your inbox with repetitive and useless data. It should also give you information on the current user, the browser, locale, etc. None of that extra stuff is really extra, it's critical for quick debugging. It's also hard to get right, and doesn't preclude inbox zero in any way.
  - volument 7y ago
    Internally we use Redis sorted sets to merge the errors into one entry on the inbox. We get the browser info from server HTTP headers. It's a cute list of errors that we regularly run trough.
    - buremba 7y ago
      Well, your error tracking solution is not simple as a javascript snippet then.

smolder 7y ago

I think you're right generally, but not universally. There are cases where it makes sense to use a one size fits all dependency and cases where it doesn't. I think the author is right that at least some of the time, it's better to DIY certain features at the risk of needing more work later than to pull bloat into a project. Responsiveness matters for how polished an application feels. Someone web browsing with an i9-9900k computer and gigabit fiber won't notice at all, others will to varying degrees. Some people rely on Hughsnet satellite because no one will run cable to them and cell service is crap. It's my experience that people like that with slow connections or slow hardware have to frequently endure garbage-tier UX because developers preferred overwrought 3rd party tools to rolling their own features, to no apparent benefit. (Dev time included in some cases) Even in the middle ground, 300ms vs 150ms matters. While "disadvantaged users" may not seem like a low hanging fruit to go after, If you impress someone like that in your audience, standing out as having more polish than usual on your product, they'll assume the best about your engineering ability and maybe even turn into a grassroots marketer for you.