211–220 of 333 posts
Everything is deployed via Netlify (well except the DB) and I use their functions to emulate a traditional backend.
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
How do you protect yourself against incomplete writes? What about when there's a critical update that you don't want lost?
I've done similar stuff in the past, but I handled things slightly differently. For tiny data structures I just spat out a short XML file. For larger data structures I synchronized all changes with a SQLite database.
https://github.com/GWBasic/pogon.html
About a year ago I decided to learn Node.js by writing a personal blog engine. I wanted a rich, template-based server-side rendering engine that would share things like headers and footers among different pages.
Mustache and Handlebars (templating systems for Javascript) are awesome, but they don't have the rich kind of HTML-aware templating that I was looking for.
And because one of the goals of Objective-S is to blur the hard lines between Unix-style command-line programming, Smalltalk-like integrated development and macOS-like apps, I also wanted to to create something to blend these elements.
The site is served by an Objective-S program that hooks an Objective-C wrapper for libµhttpd up to a bunch of storage-combinators that define the web-site.
The Objective-S program is created in an interactive app called SiteBuilder, which includes Smalltalk-style browsers for the classes the define the program + the resources (some markdown + images). The app has an integrated live-preview that reloads interactively, as-you-type. That preview is served via a special URL handler that keeps everything within the app (no http). In addition it also serves the site on an HTTP port.
The code + resources for the site are stored together in a macOS bundle, so a directory wrapper with the files inside. In fact, this data format is a version of a generic "Smalltalk bundle" that is used by a bunch of different live-editing applications.
To deploy, the wrapper is rsync'ed over to a DO droplet (smallest instance they have) running Linux + GNUstep. This setup has held up to a HN hug-of-death without breaking a sweat, so it's reasonably light-weight and robust.
Other sites are maintained using the same SiteBuilder program, but first exported to a static site.
Wix and Squarespace with Shopify for ecommerce. Every time I get asked for yet another marketing site at work I make people prove these would not work for them first. 10 bucks a month
Earlier quoted context omitted.
Sorry, I'm not sure I understand your question? Basically, I use diffing because it's simple. I don't want to mess around with manually updating whatever content I want to update, and I don't want to be forced to generate a specially crafted piece of HTML so that it's updatable. This way I only have to have only one function that updates the current page in-place by diffing, and I can use it everywhere I need to.
I meant that the old tree and the new tree both originate from the same source (i.e., your code), and if both were annotated with some kind of hashes of their contents, you wouldn't need any diffing to find the changes. You could simply compare the annotations on corresponding pairs of nodes and if they're the same, you don't need to descend any further and compare their contents - you already know than anything belo…
That's exactly what I don't want to do, since it's extra complexity and extra work on my part. (:
> Also, have you compared the performance of whatever you're doing with a simple PJAX-like approach? Considering that browsers are very good at parsing HTML, I wonder how fast that would be compared to doing quite a lot of DOM calls, which you seem to be doing (?).
Nope, sorry, I haven't done any benchmarks. From what I've tested the performance is great. If the pages where I use it were heavier then maybe I'd have performance problems, but so far I don't.
For my personal projects I find particularly satisfying using my own stack: - https://h3rald.com/litestore if I need a RESTful searchable data store and some relatively simple middleware logic. - https://h3.js.org if I need to write a single-page application and I just want to get things done fast. - https://hastysite.h3rald.com if I need a static site generator. - https://min-lang.org for more complex things. It too…
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
No SQL database is the one thing I disagree with. What if you want to write a SQL query/report? Do you have transactions? As the app gets bigger you might want that.
You have now recreated Drupal.
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
> flush to disk periodically How do you protect yourself against incomplete writes? What about when there's a critical update that you don't want lost? I've done similar stuff in the past, but I handled things slightly differently. For tiny data structures I just spat out a short XML file. For larger data structures I synchronized all changes with a SQLite database.
I don't update files on disk in-place. I write to a new file, and once it's done I do an atomic move and replace the old file with the new one.
> What about when there's a critical update that you don't want lost?
I immediately write it to the disk? (:
I don't think it's possible to completely avoid this problem. In a traditional database if you suddenly lose power you'll also lose that critical update, if it hasn't been yet committed to the disk.
I switched to Elixir/Phoenix + LiveView for my stack. - Content all markdown - Tailwindcss for styling - Phoenix provides a extremely fast framework - No database at the moment - CI/CD with github actions - Automated deployments with Gigalixir I switched to gatsby and I notice that I was spending more time fighting the system than writing. You can check it out here: https://allanmacgregor.com/posts and the code is av…
Considering using tailwind too. Only thing is, it doesn't work so well for the generated markdown html output you don't control, esp. when using many plugins to markdown parser (Mermaid, PlantUML, etc.).