241–250 of 259 posts
TiDB could be considered as a scale-out MySQL and CRDB a scale-out Postgres. They are all Spanner-inspired solutions that can help avoid manual sharding.
Earlier quoted context omitted.
I wouldn't read too much into the reception of Hey at this stage. It has only been opened up to people who pre registered, which is to say followers of dhh/Basecamp, who are predisposed to like it.
I'm sure they've allowed in all pre-registrants at this point. I registered sometime in the last week and was allowed in yesterday. I'm pretty sure DHH said the other day they'd open it up to the public this week sometime.
Has anyone managed to find a needle in the HEY stack?
What I think is even more significant than Hey’s backend stack is its _frontend_ stack. There’s no complex JavaScript framework; it’s all server side rendered HTML with a few touches of lightweight JS (mostly Turbolinks and StimulusJS, afaik) on the client to add basic interactivity. And it feels just as fast—if not faster—than any other modern, well-built web app. It goes to show that libraries like React and Vue ar…
> It goes to show that libraries like React, Vue, and Angular are _not_ necessary to build smooth, modern, and fully-featured web interfaces. The main selling point of these libraries is the clear separation of concerns - frontend code is clearly isolated from the backend code. Previously it was common for backends to return dynamically generated javascript and to use the DOM as a frontend data storage layer. These w…
I've rarely heard this as a selling point, and it doesn't seem like a very good one to me.
Even when frontend code is clearly isolated from the backend code, it's quite easy to create a mess of it all.
Except now you're also dealing with 1) multiple separate tech stacks, 2) synchronizing state in at least two places, 3) duplication of code (validation being a common one), 4) payload size and possibly lazy-loading the front-end of your codebase, 5) and so on.
There might be /something/ to this selling point in a sufficiently large project or one where multiple client apps interact with a single backend, of course, but in and of itself I don't see the benefit of such 'forced' separation of concerns.
Earlier quoted context omitted.
> Rewrites are typically prohibitively expensive, Big bang rewrites are (and, moreover, tend to lose correctness from the source), Ship of Theseus ones are not and do not have that tendency. If you can do component-wise replacement, then fast-to-develop and correct but suboptimal performance is a better deal than anything which trades off either of the others for performance.
It's feasible, but it's still very costly. And again, there's no reason to pick a language that is going to force you to do a rewrite (incremental or not) when there are languages that offer good performance and good iteration velocity.
When one can choose between multiple equally-mastered stacks, then choosing the most appropriate/performant one is perhaps a good choice. But even then there are other things to consider.
For example, I worked for a startup where my ideal choice would've been a performant stack that I'm pretty good with (Elixir/Phoenix), but we ended up going for Python/Django because the founders felt that 1) it would be easier to find more programmers locally, and 2) apparently some investors do care about this. Both seemed like valid reasons to me.
Earlier quoted context omitted.
They probably use MySQL for Basecamp and it's worked for them so they're also using it for Hey (same team developing both). As for Vitess it makes sense since it's made to work nice with Kubernetes (which they are using). I don't know of a Postgres equivalent.
Is there a Vitess for Postgres?
Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…
What I find amusing is that all of today's SPA frameworks/views are kind of descended from Angular, which Google built internally after learning the lessons of how to build such a thing while putting the Gmail front-end together. We 15 years of SPA usage in email applications demonstrating their superiority. We have things like Facebook, the one true SPA which rules them all. And yet. Turbolinks. (And I say that as a…
Earlier quoted context omitted.
My post was not about what is probable but what is possible. Hey is an app, not a website, that has been built by an entire team of developers over 2+ years, with multiple millions of dollars, not a gatsby app on Netlify made in 30 minutes. They could have made this work fully offline in React in this time, if they wanted to.
Off-line support is trivial. https://twitter.com/javan/status/1274168003773566977
Earlier quoted context omitted.
> Rewrites are typically prohibitively expensive, Big bang rewrites are (and, moreover, tend to lose correctness from the source), Ship of Theseus ones are not and do not have that tendency. If you can do component-wise replacement, then fast-to-develop and correct but suboptimal performance is a better deal than anything which trades off either of the others for performance.
It's feasible, but it's still very costly. And again, there's no reason to pick a language that is going to force you to do a rewrite (incremental or not) when there are languages that offer good performance and good iteration velocity.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Vanilla_software "when not customized from their original form, meaning that they are used without any customizations or updates applied to them"
I was actually being serious. I've never seen anyone refer to a customized RoR, have you?