rhelmer

Joined 16 years ago

Karma

658

Submissions

177

Member since

May 14

View on Hacker News

Recent submissions

Comment · 4 months ago

I suspect they are both more familiar with client-side rendering, and also thinking of things being able to share components, reuse existing libraries, and so on. So re-implementing everything with vanilla HTML and forms feels like reinventing the wheel to a team used to an SPA component library, it's not that it's intrinsically harder, it's that they don't have the existing building blocks they'd normally reach for.

Modern frameworks such as Astro allow for a similar development experience (and can optionally use JS, React and other client-side libraries) while still being able to generate a static site if desired.

I think server-side rendering and static site generation are less familiar to many web devs who came up in the React/Vue/Svelte era. The patterns and mental model are just different. In an ideal world we combine both: fast static HTML that works everywhere, with progressive enhancement for interactivity. Astro does this well; Next.js supports it too, though the SSR parts have a learning curve.

Comment · 3 years ago

Nice work! I've enjoyed playing this game in the past, and have been working on porting various apps to wasm lately. Coincidentally, this is one I was looking into porting when I found this post.

Comment · 4 years ago

Anyone used this and could compare/contrast with web-ext https://github.com/mozilla/web-ext ?

Comment · 8 years ago

I worked on the Firefox integration (per the article) if anyone has specific questions.

If you want more detail on Prio itself, I'd suggest http://blog.ezyang.com/2017/03/prio-private-robust-and-scala... as a more gentle introduction than the research paper.

Comment · 8 years ago

Part of the threat model is that individual orgs can be compelled in various ways to turn over individual user data, and having different orgs holding their own private keys helps to mitigate this.

Comment · 8 years ago

As bad (and deserved) as their reputation is for helping well-meaning users to create a big mess, spreadsheet software provides an incredibly intuitive UI to put in front of users that have the domain knowledge but not necessarily direct software engineering knowledge.

I've been thinking about this for years, ever since I first read "A Small Matter of Programming" by Bonnie Nardi: https://mitpress.mit.edu/books/small-matter-programming where she explored the history of end-user programming systems, and concludes that spreadsheet and CAD software are the only examples that have had widespread and undeniable success.

ASMOP was published in 1993 and I think it is still just as relevant today.

Just as it's possible to write a terribly-architected and designed program in any language, I suspect that with the right engineering effort and insight, modern software engineering practices could bring the complexity under control.

We shouldn't expect to just take spreadsheets and stick them into production, just as you wouldn't take a hastily-written prototype written in any programming language and do the same.