mmckelvy

It's true that a lot of the optimism around tech startups has waned over the past few years, and this trend has accelerated during 2020. Not just here on HN but in the U.S. more broadly.

I think a big piece of it is that current the crop of tech startups going public are largely unprofitable companies whose only "innovation" in many people's eyes has been skirting laws and foisting negative externalities on the broader public. These companies have also risen while the cities in which they are based (i.e. San Francisco) have deteriorated substantially.

All in all, the perception is that the current startup ecosystem isn't producing the same innovative, profitable companies that "lift all boats" the way it used to, and the increasing negativity and cynicism here likely reflects that.

I think the original concept of using inline styles in your React components was truly a leap forward in terms of styling DX. It seems like most of the developments since (CSS in JS, Tailwind) have just been more inefficient ways of implementing that core inline styles concept. Ok, these new solutions give you pseudo classes, but those can easily be replicated in JS. Beyond that, I don't see the upside of the additional complexity these solutions bring vs plain inline styles.

Where are you (and these others you mention) moving to?

If you no longer have to commute to an office, presumably you can swap that 1 bedroom apartment for a house located a bit further afield.

Yeah from my perspective the fewer tools the better. If I could record and edit in the same place I'd like that.

Looks great! Question regarding the features. Do I need to record my videos using something else or can I do the actual recording using your product?

What's the latest on SEO and single page apps (SPAs)? I've heard conflicting things on this front. Do we still need to be creating static content or can we just serve a skeleton HTML page and let client side JS do the rest?

I think the key leap they took to generate revenue was to build out a fully-baked, batteries-included product based on their open source library. Sure you could build out the components in Tailwind UI yourself, but a lot of people will pay the $250 to have a solution that "just works".

Great story. Also debunks the commonly held belief that developers won’t pay for code / libraries / components.

If you’re an open source maintainer, this is a pretty good example of how to monetize your work.

Not many people use spreadsheets on a phone. OP, beyond some basic view only functionality, I wouldn't prioritize mobile.

This is huge. I’ve been looking for a way to easily use a spreadsheet interface for data intensive applications, and was starting to look at making API calls from the Google Sheets API. This would be much better.

What is the timing for adding formulas / calculations?

Sounds great. Thanks for the detailed response.

Looks great. How much easier is this than say, writing E2E tests with Cypress?

You just don't understand it. See my comment above.

Instead of "borrowed" you could say "owed" as you state. The basic idea is it represents money you have that you're on the hook for. Could be deferred revenue, accounts payable, bank debt, etc. I say "borrowed" because that's a concrete term that maps to a transaction with which most people are familiar.

I'd also argue that you can work through even the most complicated accounting transaction and build the most complex financial statements by repeatedly asking the questions I've outlined in the above framework. Accounting was meant to be simple and accessible for the layman, but for some reason every Accounting 101 class teaches things like "debit means left and credit means right," which causes most people to throw up their hands and just rely on bookkeepers and accountants for all things money related.

For those still confused about Assets, Liabilities, Equity, Credits, and Debits, let me see if I can give you a more intuitive primer:

Assets = Money you have. Liabilities = Money you borrowed from someone else. Equity = Money you earned.

All the money you have you either (i) borrowed from someone else or (ii) earned. In other words:

Assets (money you have) = Liabilities (money you borrowed) + Equity (money you earned).

When recording a transaction all you have to do is ask yourself two questions:

1. Where did the money come from? (what is the Source) 2. Where did the money go? (what is the Use)

Suppose you borrow $100 from a bank:

1. Where did the money come from? -> you borrowed it from someone else, so increase Liabilities by $100. 2. Where did the money go? -> to your checking account (money you have), so increase Assets by $100.

Adjustments to Source accounts (where money comes from) are Credits, adjustments to Use accounts (where money goes) are Debits, so we could revise the above statement to:

1. Credit Liabilities $100 2. Debit Assets $100

That's basically it. The rest is just breaking things down into sub accounts (e.g. Assets:Checking or Equity:Income).

Hope that helps.

I like the concept of "learning to express different and deeper ideas in technologies you already know", but I'd suggest going deeper in a particular business domain or industry instead of another area of the CS universe.

In other words, become an expert at solving specific business problems with technology, not a technology expert looking for business problems to solve.

RE: the "Extract & parse content" feature, does this mean you can parse and extract data from PDF documents like bank statements or invoices?

I'd agree with a few of the other comments here. I read it and can't say that I found it particularly helpful. I've deployed a lot of Node.js apps to Heroku and Digital Ocean, and was looking for something to help me "level up" to AWS. I was left thinking that maybe I should just stick to Heroku.

I've said it a few times here on HN that I think the best UX for many web apps (particularly business apps) would be a spreadsheet connected to an API (or better yet, multiple APIs).

Of course most web apps don't expose an API, so here we are.

What about OCR'ing (or extracting from an electronic PDF) your bank statement each month and then parsing the data into your desired format? You could add tags, metadata, etc. as well.

I'm thinking of something where you download your statement (usually available in PDF form) and then drag it to a web interface where it then gets OCR'd and processed.

A bit more manual, but the upside is you're not leaking your creds and you should also have access to more data (banks have to provide statements and they usual provide them going back many years).

Excel has an JavaScript API now as well right? At least I heard rumblings to that effect. Not sure how hard / easy it is to get data into / out of though.

I think building apps with spreadsheets makes sense, but to me the spreadsheet works better as the UI, not the database. In other words, you still store your data in a plain RDBMS, but you access and manipulate that data via spreadsheet formulas or custom functions.

So a lot of that sounds good, and the Houdini stuff looks interesting, but how does "extending CSS" with JS or worklets solve the two main problems of CSS, namely the ability to define local styles and the ability to dynamically change or define styles on the fly?

Also, it doesn't look like browser support for those new APIs is going be very good for quite some time.

Can you elaborate? Specifically curious about how you get local styles and dynamic styles in vanilla CSS.

CSS felt "solved" for me when the React team introduced inline styles. I've been using them ever since and it has made styling a breeze. I know people balk at inline styles, but I still haven't heard a convincing argument as to why they are a bad thing.

A lot of these answers seem to focus on app analytics (e.g. collecting clicks, page views, etc. from Segment). How are people collecting / integrating financial data (e.g. sales, subscriptions, expenses)?

Man made noise is certainly a nuisance, but I think “nature” is not always as quiet as we like to think.

A few years ago I spent a week out in the middle of the Costa Rican jungle — miles from anyone. One thing that stuck with me was how loud the jungle was, especially at night. The bugs would start buzzing around dusk, the frogs would add to the chorus around midnight with loud croaking, and then in the wee hours of the morning we’d be treated to the piercing shrieks of monkeys.

Not exactly an ideal soundscape for a peaceful night’s sleep or quiet reflection.

Long time React user here, have started experimenting with hooks. My general sense is the useState hook is a pretty neat idea, but useEffect and friends need some work. Definitely doesn't have that same "completely makes sense, this is a great API" feel that I typically associate with React.

I'm not sure an ORM adds much in the way of casting data or preventing malicious input. Both of those features are readily available in Postgres itself. As far as formatting, the usual drivers (e.g. node-postgres) return rows as simple arrays of objects with keys corresponding to column names. That format seems easy enough to work with.

RE: number-crunching, I was referring to the fact that leaning more heavily on Postgres allows you to skip the number crunching altogether and just output the end results (e.g. using aggregates, window functions, CTEs, lateral joins, etc.).