kellysutton

Joined 16 years ago

Karma
1,149
Submissions
250
Member since
Jul 28
CTO/Co-founder at Scholarly

https://twitter.com/kellysutton https://kellysutton.com https://scholarlysoftware.com

View on Hacker News

Recent submissions

Comment · 2 days ago
Comment · 5 months ago
Comment · 6 months ago
Comment · 1 year ago
Comment · 1 year ago
Comment · 1 year ago
Comment · 1 year ago
As a PlanetScale MySQL user for the past 2 years, this is really exciting for the Postgres community. (Worked at a company that ran both, was a bummer our tooling didn’t match.)

Using PlanetScale for db management is like using an iPhone after being accustomed to a Treo. The experience is just better in every way.

Congrats to the PlanetScale team!

Comment · 1 year ago
Comment · 1 year ago
> Why did you do this again?

> Because I was so preoccupied with whether or not I could that I didn’t stop to think if I should.

A+. A great hack.

Comment · 1 year ago
Sorry. Will try to fix
Comment · 1 year ago
I'd encourage you to spend an afternoon kicking the tires on Turbo/StimulusJS, HTMX, Laravel Livewire, or Phoenix LiveView!
Comment · 1 year ago
The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend.

If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following:

- Make the change on the server to support the new functionality. Deploy.

- Make the change on the client to adopt the new functionality. Deploy.

- Remove the old functionality from the server (optional)

Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer.

With server-authored HTML, this separate client + server deploy is not required.

Comment · 1 year ago
I don't have a reason for switching away from Ruby at this point in my career. Things can always change down the line. Maintaining multiple languages at the same layer sounds like a personal nightmare to me. I'd rather learn to write PHP and have that be the only language, than to write Ruby+another language on the server-side.

We're building our company on Rails because we think it's the best choice for a young company, since it allows us to respond to customer feedback more quickly. That's what we're optimizing for right now!

Comment · 1 year ago
Yes
Comment · 1 year ago
Haven't written much TS, so can't speak to that.

I should have made the distinction between client-side and server-side JS/TS. Familiarity and expertise will be a main driver of productivity for a team, regardless of language/framework. For us, that's RoR.

Client-side JS however has a multiplying property, where we often need to write more server-side code to accommodate the growth in client-side code. If the client-side code is providing undifferentiated value (e.g. authoring HTML), we now have more pieces in our system to accomplish our goal (author HTML). What's been surprising to me is that you don't need to author HTML client-side to have a reactive experience. With Turbo, Stimulus, and server-rendered HTML, a great experience is possible with fewer layers.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton