The Hacker News discussion around Hyperclay reveals several prominent themes, primarily revolving around web application development, persistence, and the vision for the future of the web.
The "Read-Write Web" and Personal Computing Paradigms
A significant portion of the conversation revisits the early vision of the web as a "read-write web," where users were not just consumers of information but also creators and editors. This theme is heavily influenced by the parallels drawn to projects like TiddlyWiki and early web browser concepts.
- Nostalgia for Early Web: Users express a longing for a more direct and malleable web experience, reminiscent of the early days. "This is coming close to WWW's original vision because the very first web browser was also an editor. Tim Berners-Lee's application on the NeXT was basically a wrapper for the operating system's built-in rich text editing class named TextView," notes pavlov.
- TiddlyWiki as an Inspiration: Multiple users highlight TiddlyWiki as a key precedent, praising its self-contained nature and ability to allow users to persist data within a single HTML file. "The author (me) was strongly inspired by TiddlyWiki -- I love that software and wish it was allowed to proliferate more," states panphora, the author of Hyperclay. jermolene, the creator of TiddlyWiki, even chimes in, saying, "Thank you for your kind words, much appreciated, speaking as the creator/maintainer of TiddlyWiki. I really like what you've done..." mettamage also notes, "The title reminds me of TiddlyWiki."
- Local-First and Self-Contained Applications: The idea of applications living within a single, portable HTML file is a recurring point of interest. "You can have a nice UNIX workstation on your desk at a university. This would resolve to machine.department.university.ac.uk rather than be hidden behind a router. If you wanted then you could run an x window on it or transfer files to and from it," recalls theodores, illustrating the concept of local accessibility. clemensnk also mentions his project "Webstrates," which explores similar ideas: "We've been using the DOM as persistence layer for building malleable collaborative software for smaller groups, whereas hyperclay focuses on using the same mechanisms for traditional webpages."
- Loss of Direct File Manipulation: Several comments lament the shift away from direct file manipulation and local persistence in modern web development. "If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!" exclaims panphora. codedokode echoes this sentiment, stating, "I do not want to use a web-server because it feels like overengineering and I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time."
The Role of Servers and Persistence Mechanisms
A significant portion of the debate centers on the necessity and implementation of backend servers for persistence, contrasting Hyperclay's approach with serverless or purely client-side solutions.
- Server vs. Serverless Debate: The core of this theme is whether a server is truly necessary for state persistence in single-HTML-file applications. "The author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right?" questions andai. This leads to a clarification from panphora: "The hosted version is for when you want to share your apps or let other people fork them online."
- Hyperclay's Backend Approach: Hyperclay's use of a "/save" endpoint to POST HTML changes to a backend server for persistence is both noted and questioned. "Wait, so instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit (e.g. a small profile description change)? What about if the webmaster then wants to change the HTML title of the profile description block? The user's version just diverged from the webmaster's ?" asks maelito. panphora defends this by explaining the trade-off: "Yes. In exchange, we get a portable, malleable, self-contained application. That's the tradeoff."
- Alternatives and Serverless Implementations: Users propose and discuss alternative methods for achieving persistence without a traditional server. meistertigran mentions htmlsync.io as a solution for localStorage synchronization. Sammi suggests using
isomorphic-gitto persist directly to a Git repo, while mcteamster shows an example of a self-contained game that downloads its updated HTML without a server. "No server required," states mcteamster. - Browser Limitations and APIs: The discussion touches upon browser limitations, particularly concerning direct filesystem access and APIs like
localStorageandIndexedDB, which are often cited as reasons for needing a backend. "I understand that local web APIs are ass and you very quickly run into the need for a server," admits andai. codedokode laments, "Sadly it doesn't work for JS modules, only for legacy JS scripts."
Identity and Authentication in Web Browsing
A tangential but significant theme revolves around the concept of user identity on the web.
- Need for Built-in Identity: swiftcoder expresses a desire for a more integrated identity system: "I've been thinking for a while that the web really suffers from not having a built-in concept of (ideally fairly anonymous) identity. I shouldn't need to maintain a whole authentication system and a database full of PII just to let you see the same data across your laptop and your phone..." They elaborate, "The browser should be able to vend me an (opaque, anonymous) token that identifies you as an individual. If your mobile and desktop browser vend the same token, then the website sees you as having the same identity on both platforms."
- Privacy Concerns: The privacy implications of such systems are raised as a major hurdle. chuckadams views it as "The privacy implications of this are a deep and toxic swamp into which every previous attempt has sunk."
User Experience, Communication, and Project Presentation
Commenters also discuss Hyperclay's presentation, its documentation, and the overall user experience of interacting with the project.
- Critiques of Presentation: Some users find the visual storytelling approach distracting or inefficient for understanding the core technology. "The experience I want is a short prose description up front, backstory that flows, and diagrams only where they actually illustrate a concept that needs it," suggests zahlman. bflesch also states, "I appreciate the storytelling and the nice graphics, but after reading 10 screen lengths of this story I still don't understand what technology they are using to achieve this."
- Clarity and Documentation: There's a call for clearer, more concise explanations of how Hyperclay works. maelito asks, "Do we need a story with illustration to understand how a new framework works? What's the plain markdown 2 to 3 paragraph that explains the concept?"
- Open Source and Licensing: Users inquire about the project's open-source status and licensing. "Are there any open source alternatives like this?" asks fowlie. panphora clarifies that a local, open-source version exists.
- Pricing and Business Model: Comments emerge regarding the pricing page (initially returning a 404) and the overall business model, with some questioning the market for a paid hosting service for what is perceived as an easy-to-host solution. "I'm wondering who it is that is ok paying for someone else to do the easiest part what they do for a living," wonders theelous3.
In summary, the discussion reveals a strong interest in revisiting the foundational principles of a malleable, user-editable web, with TiddlyWiki serving as a significant touchstone. The technical implementation of persistence, the trade-offs between server-based and serverless approaches, and the user experience of presenting complex ideas are central to the conversation.