jsherwani

https://x.com/trq212/status/2048495545375990245

He is getting a refund along with an additional $200 credit from what I can see.

In California, the maximum personal income tax rate is effectively closer to 50%, which is where my mind went, but you're right, it's different for companies.

In my example, the tax rate isn't the point though, it was used just to illustrate the math.

The main point is that it makes no sense to require amortization of software development expenses. The idea that this letter is an attempt to restore rationality in the tax code.

For folks that don't know the background on this, here's a layperson summary:

- A business is usually taxed on its profits: you deduct your revenue from the cost of producing that revenue, and the delta is what you are taxed on.

- In software businesses, this usually means if you spend $1M in software development to develop a web app, and it makes $1.1M in that year, you'd get taxed on the $100K profits.

- However, a few years ago, the IRS stopped allowing the $1M to be deducted in the year it was incurred. Instead, the $1M was to be amortized over 5 years, so now the business can only count $200K as the deductible expense for that year. So now it's going to be taxed on "profits" of $900K. Assuming the tax rate is 20%, that means the business owes $180K in taxes, even though it has a total of $100K in the bank after the actual expenses were paid. So it would have to either borrow to pay taxes or raise venture capital, meaning that VC-funded companies would be advantaged over bootstrapped ones!

- The letter's goal is to bring things back to how they were (and how they are for all other businesses): let businesses deduct their actual expenses from their actual revenue, and tax that actual profit.

I am neither a lawyer nor an accountant, this is just my understanding of this issue.

Edit: Switched the tax rate to 20%. The logic is still the same.

I’ve been helping Omar on this and one of the hardest aspects of building this product has been finding users that can give actual feedback. Any ideas there would be super helpful

it would be nice if i could save my progress at every level so i could just keep working on one level at a time.

Yes, this is an issue!

And, zooming out a little more, free market healthcare is just part of the problem.

We have a system where we’re only treating people once they have a disease, and not working to prevent the disease, so it would be helpful to look at the effects of for-profit companies on making healthy people sicker. Fast food, snacks, alcohol, there are so many industries that are incentivized to succeed by making people sick.

This is the system “working” according to the current rule set.

It’s time to look for a better algorithm than a purely profit maximizing one.

Pop co-founder here. It warms my heart to hear this. Thank you for the appreciation!

The app is doing an http(s?) request, which includes more round trips than a simple ping. Also, the web server may be more loaded than the ping response would indicate.

Yes, and I think what’s interesting is to consider is that the ability to use a terminal is a very recent (and from a certain perspective, strange) skill, considered from the perspective of the kind of hardware we have for information access, storage and transmission.

What’s far more “normal” is storytelling (with heroes and villains), rhythm & rhyme, and lots of repetition. But even simple conversational interfaces are way more normal (and fit our mental hardware well) than terminal-y interactions.

Yes, that’s it! An easier and shorter read may be the final paper I published in that domain, which talks more about the difference between literate and low/non-literate users:

http://www.cs.cmu.edu/~jsherwan/pubs/orality-hcid-itid09.pdf

My PhD thesis focused on voice interface design for people with limited literacy skills. One of the most surprising discoveries for me was that menus and even lists of items aren’t natural concepts that exist outside of a context of literacy. Even for voice interfaces, a touch tone menu (“for X press 1, for Y press 2...”) was a lot harder to navigate than an equivalent voice-based menu (“would you like X, Y, or Z?”). As a side project during my final year of my thesis research, I wrote an iPhone app that unexpectedly propelled me into the world of entrepreneurship, so I ended up pursuing the startup life after I graduated. But this space is still fascinating to me.

We have a .deb and .rpm download, and also have an AUR package. Let me know if you need something else!

You’re absolutely right, and we do need to do a better job for lower spec machines. Lots of work left to be done, for sure!

Thanks for the positive words!

Thank you for the kind words!

Pop’s performance is something we have spent significant time improving, and we’ll continue to do so. My only ask is for folks to try the product and judge its performance (or lack thereof) on its own merits, regardless of presumptions based on our use of Electron. We have thousands of daily active users that continue to use the product happily.

Another commenter mentioned how VSCode's performance shows that Electron isn't terrible [1].

Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance.

[1] https://news.ycombinator.com/item?id=28230542

Agreed, it's quite an inspiration as to the best Electron can be. I think the trick for an app like ours is to offload the heaviest pieces to native code, and use Electron purely as a presentation layer. This is something we're now going to look into.

Thanks for the details!

Based on the feedback today, we're going to look into how we can reduce memory usage overall (especially when idle), and CPU usage especially when screen sharing. We already modify Electron, so we may be able to work out a good middle ground that reduces the footprint significantly, while still giving us the advantages of a shared codebase across our 4 platforms (Mac, Windows, Linux, web).

We're happy you're happy! Please try out the product and let us know if there's anything we can do to improve.

Similar discussion here: https://news.ycombinator.com/item?id=28224881

In short: when you need to see anything outside the IDE (e.g. a debugger, or even just seeing the running app alongside the IDE), a tool like Pop is very helpful. But you can also use it in conjunction with those IDE features, as Elijah in the above thread said he does.

Tuple's done a good job of their minimalist UI (it's largely modeled after Screenhero).

With Pop, you can minimize the control panel with 1 click. We'll soon also be adding the ability to remove the border around your shared screen entirely (some users have told us it gives them anxiety to not see something that clearly shows them that they're sharing their screen, but we've now heard the opposite perspective from enough people to realize we need to support both preferences).

We don't have investors — we're 100% bootstrapped, and have full control of all of our assets.

Please email us at hello@pop.com so we can figure out how this happened and fix it asap!

Glad to be back :D

Glad to have you back!

And honestly, the feedback on Pop as a name has been overwhelmingly positive :)

In Pop, if you add people to your contact list (or connect with Slack), you can see your contacts and team members' online presence, and can call them from within Pop.

Yes, that was ~3 years of learning (and pain) condensed into a short paragraph :D

I think one key piece worth emphasizing was: Screenhero's core strength was in its interactive screen sharing. Slack's main desire was in voice, then video, then screen sharing, then interactive screen sharing — and this "impedance mismatch" is somewhat responsible for where things ended up. By the time we got to the end of that roadmap, the appetite for the final feature was low, while the cost was very high.

Thanks for the provocative phrasing — I really like it!

The native module coupled with Electron could be a great solution to the performance issue: it would give native performance for the most critical part of the product, while still providing a cross-platform foundation for a shared user interface across 4 platforms (Mac, Windows, Linux & browsers).

Given the feedback today on performance and resource bloat, we're going to dive deeper into benchmarking our product against the competition, and will post an update on what we find.

Related anecdote: Screenhero's UI was originally totally native on the two platforms we supported (Mac and Windows). It was a night-and-day improvement (it looked better, had fewer bugs, was easier to build and maintain) when we moved from native UI to HTML5 (using Awesomium on Windows, and WebView on Mac). However, we'd then have issues on Mac where a user's UI would have glitches because their version of OS X or Safari (often both) weren't up-to-date. So it was always a little awkward to tell people that the reason their screen sharing app looked funny was because they needed to update their web browser.

Having said this, I think this discussion between Electron vs. Native is a false dichotomy. Performance and developer efficiency are both clearly important, and we don't have to maximize one dimension alone. I am confident we'll find a way to make Electron far more performant by switching off unnecessary features, such that it provides us just the surface area we need to be able to build great products that are indistinguishable from their native counterparts: except that they're quicker to build, easier to debug, are of higher quality (with fewer bugs), and cost less.

I know this sounds optimistic, but given the popularity of Electron, coupled with the issue of performance, this is an issue that is certainly going to improve over the coming months and years. Who knows, since ours is one of the more performance-hungry products, we may end up finding a solution that others can leverage as well.