Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What novel tools are you using to write web sites/apps?
344 points by yawn 9 days ago | hide | past | favorite | 321 comments
I'd like to hear about different approaches others are using to write web sites or apps today. What languages, frameworks, or libraries are you using? If so, why and what do you like about it?





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 refreshes normally)

- Running on a single, cheap VPS; no Docker, no Kubernetes, no serverless

- No SQL database; I just keep everything in memory in native data structures and flush to disk periodically; I have a big swap file set up so that I can keep a working set bigger than the RAM

- Written in Rust, so it's fast; I can support tens of thousands of connections per second and thousands concurrent users on my cheap VPS


> 100% server side rendered

> Progressively enhanced

> request full HTML through AJAX and diff it into the current page

These first three points are actually starting to be "in" again. They're called HTML-over-the-wire[1, 2]. And I am currently looking into implementing them for my site (which uses ASP.NET Core Blazor), because I think this approach is awesome.

[1] https://hotwire.dev/

[2] https://alistapart.com/article/the-future-of-web-software-is...


Have you seen HotChocolate's GraphQL (+Blazor +websockets)? https://www.youtube.com/watch?v=XLOZ3hhJKBE

I haven't, will look into it. Thanks!

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.

> No SQL database is the one thing I disagree with.

I'm not saying this approach is a good idea in every case. There are many situations where I would use a proper database. It really depends on what kind of app you're building, what kind of queries you want to run, how big is your dataset, your failover and availability requirements, your programming language, etc.

In my case it was a great decision. The code is simple, and the data is convenient to access since it is already packed in native data structures. And it's really, really fast since all of the "queries" are basically LLVM-optimized machine code.

> What if you want to write a SQL query/report?

I just write a few lines of normal Rust code to do that. Sure, it's not as convenient. But I don't need to do that as often, so I don't care.

> Do you have transactions?

The concept of 'transaction' doesn't really make sense in this approach, since I'm directly modifying the data in memory, every change I make is atomic and can't fail, and I flush the data to the disk atomically as well.


>The concept of 'transaction' doesn't really make sense in this approach, since I'm directly modifying the data in memory, every change I make is atomic and can't fail, and I flush the data to the disk atomically as well.

So you don't have mutable data shared between threads then?


> So you don't have mutable data shared between threads then?

I might have worded that one sentence a little better, sorry.

I do technically need to share data between threads, since my event loop runs on multiple threads, so if I want to mutably modify something I do need to wrap it either in a `Mutex` or an `RwLock` and lock it.

What I meant was that it is not the same as a "transaction" in the SQL sense. It can't fail, there is no rollback, I decide on my own what level of granularity I need, and I bake the necessary atomicity into the data structures itself. So there are no SQL-style transactions anywhere - I just use a lock where it's appropriate to directly modify the memory, just as you'd do in any other situation. (Either by wrapping the whole structure in a lock, or wrapping only a single field, or by simply making the field atomic by itself.)


So it's a simple mmap database like early versions of MongoDB? I like using atomic commands, but I imagine it would become tedious fast to do the extra work of doing the accounting of the transaction manually every time you want to do a non atomic transaction.

> So it's a simple mmap database like early versions of MongoDB?

Even simpler. I use mmap only for things that I build offline and that never change during the runtime. Everything else is just kept as your garden variety objects in memory.

(Well, although I guess you could say it is an mmap database, it's just that the mmaped file is the swap, and the OS manages it for me.)

> I like using atomic commands, but I imagine it would become tedious fast to do the extra work of doing the accounting of the transaction manually every time you want to do a non atomic transaction.

In my case it's not really tedious at all. Usually when I want to mutate something it looks something like this:

    let user_ref = state.require_login()?;
    let user = user_ref.write();
    user.set_field(value);
    drop(user);
Of course this depends on your requirements. If you'd have 20 different objects of 10 different types that you'd have to lock separately and you'd want to update all of them atomically it might become hairy (SQL would definitely be better in such a case), but I don't have such cases.

I do similar stuff to what you do, writing my backend code in Rust and not using a database but opting instead to keep things in memory and flushing to disk on my own. And running servers that I manage with SSH.

I would love to talk with you and exchange knowledge. Your HN profile has no publicly visible contact info though.

Do you have an email address I can reach you on? Can you put it in your HN profile description?


Sure. You can email me at j@exia.io.

(Just please note that if I apparently don't reply and if you're using gmail then my reply probably went to spam or gmail's /dev/null, so email me again; lately gmail doesn't like emails that I send and either puts them into spam or just sends them to /dev/null, even when I'm replying to someone that emailed me first! So much for Google having no monopoly, sigh...)


I run my own mail server so there’s also a chance that I end up in your spam folder instead when I send you a mail, if you do spam filtering :p

The basic stuff Rust will solve for you, but it is easy to forget logical dependencies and get an inconsistent state anyways... Just the ordinary close a session, send error message if not alive has bitten us in a 20 person project.

Yeah, this seems problematic. What if you hard power off your server, how do you know your data didn't get corrupted? As someone who has written databases, and knows how difficult this is to get right, it makes my skin crawl.

Backups and restore will also have to be DIY. Point in time restore probably won't be possible - and that's a life saver when you need it.


> What if you hard power off your server, how do you know your data didn't get corrupted?

Atomically replacing the whole file instead of updating the data in-place, and using a checksumming filesystem like ZFS should give you such guarantee, no?

> Backups and restore will also have to be DIY.

Well, yeah. A daily cron job that `scp`s the data to an offsite location. Personally I don't really see much problem with that? It's easy to backup, and easy to restore.


> Atomically replacing the whole file instead of updating the data in-place, and using a checksumming filesystem like ZFS should give you such guarantee, no?

No. You need to use fsync to ensure the file is flushed to disk. Also careful not to rename the file across mount points (/tmp is often a different mount and the most common location for people trying this.)

> Well, yeah. A daily cron job that `scp`s the data to an offsite location. Personally I don't really see much problem with that? It's easy to backup, and easy to restore.

That's fine, but your backup and restore granularity is daily. If you introduce a bug that writes the wrong / partial data, you can't recover anything that isn't in the previous day's backup.

With a typical database you have a transaction log and you could restore back to any point during the day.

This has been necessary about a dozen times during my career (once every two years or so on average.)


> No. You need to use fsync to ensure the file is flushed to disk.

Are you sure? At least in case of ZFS AFAIK the file wouldn't get corrupted, since it uses copy-on-write internally. Sure, you might get the old data back, but you wouldn't get corruption. And it automatically checksums your files anyway so it will detect any data that did get corrupted, and if you're using RAID-1 (as you should for any important data) it will automatically repair it.

> Also careful not to rename the file across mount points (/tmp is often a different mount and the most common location for people trying this.)

You can't rename across mount points. (Linux's `rename` syscall and the corresponding C API will return an EXDEV error if you try.)

> If you introduce a bug that writes the wrong / partial data, you can't recover anything that isn't in the previous day's backup.

Sure. If I was working in a bank not being able to do that would be totally unacceptable. But in my case that's the tradeoff I'm willing to live with.


Adding in a service like a SQL database because "you might want that" in the future is not a good idea. Apps should do what they need to do and no more. "Future proofing" is almost always a waste of time - even if you definitely want the feature in the future it's usually better to add it in when it's needed than adding it early and have to support something that adds no value yet.

As for reports and transactions specifically, noSQL databases support both.


OP isn't talking about noSQL databases, but no database at all (if I understand correctly - OP says '- No SQL database; I just keep everything in memory in native data structures'.

In this case, I don't think OP is even thinking about noSQL databases.


Correct. Sorry, I should have worded that better; unfortunately I cannot edit the post anymore.

Unless, of course, switching to SQL turns out to be a major headache because it requires major rewrites, organizational changes, etc.

> "Future proofing" is almost always a waste of time

Not really, unless you lack the experience to know what to future proof and what not to future proof.

I've saved days/weeks of development by future proofing certain things, I've also saved days/weeks of development by taking pragmatic YAGNI in the right places.

Obviously this will only surface on projects that last longer than a couple months ;)


Isn't this the problem? "What if I need to do something I don't need to do right now? I know I best add it in just incase!"

You have now recreated Drupal.


My "old is new" setup is similar in spirit but quite different in effect.

I use rails, postgres, and docker. The only weird thing in the stack is that I use a pretty big base image - the ubuntu base image.

Where I need SPA-like performance, I use react-rails to just do that little bit in React.

Rails has so many batteries included, I just can't imagine being as productive in anything less mature.


> I use a ~100 line long DOM diffing algorithm

Since this is not vDOM diffing (which most JS frameworks nowadays provide) can you help share the algorithm if its already out in the open / non-proprietary?


It's really nothing special. I wrote the whole thing in, like, a single afternoon. If you're interested, here it is:

https://pastebin.com/V7UiWj1e

It's not really a general purpose diffing algorithm. It probably doesn't handle every corner case as it only does what I need it to do in the few places I actually need it.


Would you even need diffing if, for example, the relevant nodes had an ID functionally derived from their contents?

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 below that node is going to be identical.

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 (?). I'd definitely be interested in that comparison.


> if both were annotated with some kind of hashes of their contents

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.


I'm really impressed at how many people have come back with critiques or suggestions about your architecture without actually even knowing what your app does!

So, what does it do?


Well, to me it's more of a "no one I know develops like this; tell me more" kind of a thing rather than a normal critique of my architecture. (:

I've posted this link in another comment already, but this is one of my projects where I'm using this approach: https://jpdb.io


Yes! I am a big fan of "keep data hot" approaches to things. I first came across this approach with the Prevayler library years ago and I love it.

People who haven't tried it will be excited to discover how much faster it is. The only trick is to store your data in a format where you can write the changes easily. E.g., logging changes and then playing back the log on startup.


I do the same thing with "no SQL db". The only thing I do differently is not make snapshot of the state but rather replay events to achieve the same state as before (or different t if we migrate to different logic). Also all the changes that are possible are typed events. It wont be a problem to save the state like you do but right now our application changes so often that we have to make sure we can replicate the state even if the logic changes.

Would love to talk to you about this.


I do this a lot these days with prototypes and poc’s but usually with Go since I’m more familiar with it. Sure it only works on one machine, but it’s usually so fast scaling means it was a success and now you have a war chest.

I’d add adding s3 to backup things though.


> 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.


> How do you protect yourself against incomplete writes?

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 like the approach of tailoring the app to the use case, so I'm not arguing you should do something differently.

The database has commit for exactly this reason. If you lose power, you will not acknowledge the commit to the client, so the client may retry. For example, the end user may get an error page. This is different from a case when the app would show modified values, but the next day, the modifications would be gone.

With the database, you still have the problem, that after a user sees an error, the transaction might have suceeded. Eg if connection drops at the moment when the DB receives the commit command.


How big are the files?

The old version of the application that was written before my version always wrote the entire file like you do. But when the file got very large it was too slow, which was why we used SQLite in newer versions.


> Progressively enhanced (fully works without JS, but having JS enabled makes it nicer)

This is something I've struggled to get developers to understand forever. It doesn't help that no browser really allows users to switch off js. The number of developers who think doing client-side validation on forms is enough is far too high!


Regardless of JS vs no JS, only validating forms on the client side is just an awful practice begging for trouble.

This speaks to my soul! How cheap of a VPS?

Currently 4.29 EUR/month VPS on Hetzner. (Although I have some fun features planned and might need some more processing power so I might upgrade in the future.)

They have great AMD-based VMs, 2x perf/$ over Intel. (I've benchmarked.)


How much traffic per month does it cover in this amount?

I want to launch some toy projects and confuses whether go for AWS or vps.


20 TB.

I would definitely recommend going with a VPS over AWS in your case, unless you want to play with AWS-specific tech to build up your resume.


are you also installing the DB within the VPS?

I would be needing a web app connecting with MySQL and a bunch of Crons.

Also, could I host multiple domains?


I don't use a DB. But sure, you could run both your app and the DB on a single VPS.

Yes, you can host multiple domains. You can either point multiple domains to a single IP of your VPS, and configure your web server to use name-based virtual hosting, or you could buy an extra floating IP, assign it to your VM, and use IP-based virtual hosting.


Is it done by hosting guys or I have to do on my own? Also what about backup? I am not quite good at devops/admin stuff hence asking

You have to do it yourself. But it's not that hard. The easiest way of hosting multiple sites is probably to just assign multiple IPs to a single VM and simply run multiple servers simultaneously, each listening only on a single IP.

As far as the backup is concerned, Hetzner has the option of handling it for you for 20% extra money.


In my opinion this question seems like a good reason to get your feet wet just a bit. Just gaining some understanding of how things work under the hood is worth it even if you end up never using it professionally.

The basics of operating a (virtual) server to run your apps on could be seen as similar to learning the basics of cooking food. You can eat fairly well for the rest of your life without knowing a thing about it but if you just spend a single hour every week preparing your own food, you will become more familiar with the food itself. You would larn what individual flavors you prefer and where they come from, and you'll even be able to survive on less money if you would need to, or even survive more easily in a potential crisis where home delivery isn't an option.

If you spend an hour every week to learn some system administration (what people call "ops" nowadays) you'll be able to realize when you're being overcharged for simple services, feel the power of building a larger part of your stack yourself, play with new things, etc. Running multiple apps on a single host with proper backups is a trivial problem, especially if you know how to code, and in my opinion these things shouldn't be "left to the devops team" or seen as "IT stuff".

Not that long ago most developers had to know what environment their software ran in as part of their job, and despite many attempts to move away from it, this is still mostly true even if we have switched from the Linux CLI to cloud dashboards, CI/CD pipelines and Terraform scripts...


I am currently using a bunch of AWS technologies, e.g. AWS EBS, RDS etc. I am also thinking to consolidate all projects to a single AWS LightSail, which offers pretty cheap instances, e.g. 512 Mb, 1vCPU, 20Gb SSD for 3.5$/month.

20 TB of outgoing traffic is included with a Hetzner Cloud VPS, any additional TB costs 1,19€. Incoming traffic is free.

what benchmarks do you use? I'm curious how my VPSes compare.

It was quite some time ago so I don't remember exactly, but I've basically used one of the usual benchmarks that everyone uses to measure the number of requests per second that a server can sustain.

(I've rented another VPS in the same data center and ran the benchmark from there.)


> I just keep everything in memory in native data structures and flush to disk periodically;

Can you expand on what you mean by this? I am interpreting that to mean that you are actually writing to a file and reading from a file rather than using SQL?


They're storing their data in native Rust objects and read or write them in server application RAM. In case data becomes larger than available RAM, they have set up a large swap, which is a file or a disk partition that the OS uses when no more real RAM is available, while acting like nothing is happening (and everything gets 1000x slower). They periodically serialize these in-memory objects to a file on disk, and presumably (they didn't specify, but I feel it's implied) they're reading this file and deserialize it during initialization/startup phase.

Correct. Although I don't read everything on startup. Some of the data (e.g. per user data) is only loaded once it's needed.

Also, the swap doesn't make everything slower as long as my active working set is smaller than the available RAM. That is, I have more data loaded into "memory" than I have RAM, but I'm not using all of it all the time, so things are still fast. It's basically an OS managed database. (If I were using a normal SQL database I'd get a similar behavior where actively used data would sit in RAM and less used data would be read from the disk.)


The obvious difference is that swap files are not as optimized for disk io. There is a serious performance issue if you ever have to hit disk often. It all depends on how you structure your in memory/on disk data. But it might never be an issue, have scaled to tenish million user in memory there is so much else that can go wrong first.

Why not use something like lmdb instead of writing raw files? It's a performant k/v store and memory mapped. It beats file access syscalls most of the time.

I'm well aware of lmdb and I did consider using it.

It is a reasonable option, yes. It's just mostly unnecessary in my particular case with my architecture, so I went for the simpler option.


What kinds of things have you made with your setup?

This is really neat. What's the site? I'd love to see it. And could you tell us more about the DOM diffing algorithm?

> What's the site? I'd love to see it.

One of my projects where I'm using this approach is this one: https://jpdb.io

> And could you tell us more about the DOM diffing algorithm?

I'll paste what I wrote in another reply to a post asking the same question:

It's really nothing special. I wrote the whole thing in, like, a single afternoon. If you're interested, here it is:

https://pastebin.com/V7UiWj1e

It's not really a general purpose diffing algorithm. It probably doesn't handle every corner case as it only does what I need it to do in the few places I actually need it.


To be expected from your previous comments, but your website is snappy. Navigating it feels great.

The search works great. Having furigana next to kanji is very useful. Fantastic work!

While playing around, I got the play button to work only once and then got this error:

  Uncaught TypeError: this.previousElementSibling.play is not a function
    onclick https://jpdb.io/search?q=ごめんあさい#a:1

That's interesting! It works for me, both on Firefox and Chromium.

May I ask what web browser and OS are you using?


Firefox 87.0 (64-bit) on Win10. It is reproducible. Disabling uBlock Origin didn't make a difference. Let me know if I can help debug!

Okay, so this is indeed very interesting. I just launched the same version of Firefox in a Win10 VM, and it works there too. So it might be one of your extensions, maybe? (I use uBlock Origin too, so that's not it.)

Could you try these things out please?

1. Try disabling all of your extensions and try again. (IIRC by default private mode disables all of the extensions, so that should be an easy way to do it.)

2. Can you open the dev console and try running something like this in it?

    document.querySelector("audio").play()
Based on your original error either the `previousElementSibling` is not an `<audio>` tag, or for some reason audio tags don't have a play method, so it'd be good to know which one it is.

Hello, just tried disabling extensions one by one and it seems that https://addons.mozilla.org/en-GB/firefox/addon/rikaichamp/ causes the problem. I can reliably enable/disable the extension to reproduce/fix the problem.

Which Rust templating tools are you using for server side HTML rendering?

I have my own crate for template rendering. I tried various existing ones but I ended up not liking any of them for one reason or another, so I've made my own.

Some of the features are:

* Fully static. It's compiled into Rust code instead of being dynamic. (I wanted to be able to use normal Rust code in my templates instead of a special template-only language, and I wanted the extra speed.)

* Built-in automatic HTML whitespace minification at compile time.

* Built-in XSS-safe string interpolation. You have to explicitly use the unsafe raw interpolation.

* It can interpolate any Rust value which implements the `Display` trait.

* Doesn't use Jinja's syntax.

* Doesn't have any extra unnecessary dependencies.

* Doesn't use inheritance for template composition, instead it uses simple textual inclusion plus late binding to achieve composition. Since it's hard to explain let me give a simple example. Let's assume I have a skeleton.html which looks like this:

    <html>
    <head>
        <title><~ @paste title ~></title>
    </head>
    <body>
        ~~ @paste body
    </body>
    </html>
And now I have index.html which is the actual template I render, and it looks like this:

    ~~ @include "skeleton.html"
    ~~ @snippet title
        Index
    ~~ @end
    ~~ @snippet body
        <h1>Hello world!</h1>
    ~~ @end
As you can see I first include the skeleton.html, and then I define the "title" and the "body" snippets after the skeleton has already pasted them. Normally this wouldn't work, but since the `@paste` directive is lazy it only gets resolved once the whole template is processed.

This makes it really simple to customize the templates, since you can just add `@paste`s wherever you'd like to have a customization point, and you don't have to think about doing things in the right order since the templating engine will take care of it for you.

(If you forget to define a snippet that was `@paste`d you'll get a compile time error; I also have other directives that allow you to set a default if there was no snippet defined.)


That looks a lot like ructe [0], a templating language that I really love. It compiles templates to functions that you can call from Rust using a build script. The functions parameters are accessible from your templates. You can even import and run arbitrary rust code from your app:

    @use any::rust::Type;
    @use super::statics::style_css;
    
    @(name: &str, items: &[Type])
    
    <html>
       <head>
         <title>@name</title>
         <link rel="stylesheet" href="/static/@style_css.name" type="text/css"/>
       </head>
       <body>
         <h1>@name</h1>
         <dl>
         @for item in items {
           <dt>@item.title()</dt>
           <dd>@item.description()</dd>
         }
         </dl>
       <body>
    </html>

[0]: https://github.com/kaj/ructe

I love the overall simplicity of your approach. Any chance of sharing your template rendering crate with us?

I've had a good time with Tera, but I haven't used it extensively.

What are the requirements that need it to have no database?

It's the other way around. I have no requirements that need it to have a normal database.

The biggest two advantages of not having a database are simplicity (I don't have to query the database to access the data, as it's already in memory) and speed (my average response times are well under 1ms, and that is with compressing every reply, having more data in memory than I have RAM, running on a cheap dual core VPS, and being flooded with requests from linking to my site on HN).


What Rust framework/crate are you using for webserver?

My own. (:

In general I was a little frustrated with the state of Rust's web server ecosystem since it has, what I personally call, the NPM syndrome. Pulling a single crate will often pull along with it hundreds of dependencies, and murder your compile times. I know that those dependencies are often necessary, but during development I do not need all of that.

So I made my own.

But of course it's generally a bad idea to run your own HTTP stack in production. So my framework works like this - it can be compiled either in development mode, or in production mode.

In development mode it uses my own crappy HTTP stack and my own crappy async executor and has *zero* dependencies, and compiles super fast. In production mode it uses `hyper` and `tokio`. In both cases the API is exactly the same. So I can have my cake and eat it too.


Any chance any of this can be made open source? Sounds like a killer feature

Possibly. I will make it open source eventually. It's just that's extra work that I don't really have much time for.

Fascinating. Would you like a full-time Rust job? :)

...are you offering one? (: If so I would definitely be interested.

We're also looking for Rust developers. E-Mail is in my profile. Happy to talk :)

email me, my email in my profile.

There is no email in your profile. You've probably added an email to your HN account, not to your profile.

To make it appear in your profile, add it to the "about:" section in your account settings (the page you go to when you click your own username)


How do you deploy changes? git hooks or something like ftp?

Basically it's more-or-less this:

1. Compile the binary.

2. SCP it to the server.

3. Restart the running process.


Brilliant, I feel that would simplify much of my life

What are “native data structures”?

Not OP, but we had a similar project long back. All data is in maps and structs. We didn't had free text search, all filters had a corresponding Map of key to []ids. A primary map from id to object. Needs lots of RAM, but that is the cheapest thing we can add

Normal structs, `Vec`s, `HashMap`s, `HashSet`s, etc. Basically whatever is natively available in Rust.

Whatever data types are available in the programming language of choice here; Rust.

How does progressively enhanced work without Javascript please?

how do you control for swapping to much?

I don't.

Linux's memory management subsystem is really good. It's almost magic. And modern SSDs are really fast. So whatever swapping is going on in the background I really don't feel it.

It's basically an OS managed database. Instead of the SQL server doing the swapping to-and-from the disk, Linux does it for me.


The post was about 'novel' tools. I really dont see what is novel about your approach

Let me quote the OP:

> I'd like to hear about different approaches others are using to write web sites or apps today. What languages, frameworks, or libraries are you using?

So the question as I understood it was not "what truly novel and unique approach you're using that no one else has before?" but more of a "what non-mainstream approach you're using?". And what I'm doing is definitely non-mainstream.


Actually, the title of the post specifically says "novel tools". That apparently didn't make it into the body of the post, but almost everyone is primed by the title to expect novel solutions in the answers.

That said, I don't think there's any harm in reminding people that there are plenty of non-novel solutions already that they might not have fully considered.


He is using a novel templating library, novel HTTP server, novel JS diffing algorithm ... and this approach has generated more questions than any other on this thread so clearly it is unfamiliar to much of the audience.

I am working on two alternative tools for building web apps:

https://htmx.org - uses HTML attributes and HTML-over-the-wire for AJAX/Web Socket/SSE interactions

https://hyperscript.org - an experimental front end programming language derived from HyperTalk that is event-oriented and that removes the distinction between synchronous and asynchronous code.

Both tools are HTML-oriented and are designed to be embedded directly in your HTML, rather than along side it. I am trying to popularize the term "Locality of Behaviour" for this idea:

https://htmx.org/essays/locality-of-behaviour/

There are a few tools that are moving people this direction these days, notably AlpineJS and Tailwinds.


I've played with HTMX (and previously intercooler.js). Just wanted to say - everything you touch is awesome. Thanks for your efforts.

I also like Alpine.js and Stimulus.js projects. They're trying to simplify the insanity of front-end development.

Go + HTMX is super powers. It peels away the piles and piles of framework layers and still gets you 90% there. For the 10%, just use React/Angular/Vue.


thank you very much, that's awesome to hear

"Locality of Behavior" is how everything started, when we used to embed PHP code into html. :)

yep

the idea wasn't wrong, but the level of expressivity wasn't there yet

trying to fix that


I'm not sure what came first, but it's unfortunate that hyperscript.org clashes with hyperscript, the pure JavaScript notation to describe HTML.

hyperscript (`h()`) had its first commit 9 years ago and the syntax is common in other rendering libraries (e.g. mithril, ivi).

_hyperscript (this one) seems to have released 0.0.1 only last year.

Definitely very confusing on the naming front. It is at least possible to disambiguate searches with the underscore.


I'm really looking forward to Hyperscript growing more capabilities. I love that it's very natural-language-oriented. I'm really interested in frameworks like this that could make HTML website creation more accessible for regular people. Watching a friend try to build a website with SquareSpace I was thinking... for the amount of effort she put into learning SS's tools and quirks, she could almost have just learned HTML.

yep, the tool chain startup costs in front end development are very high unfortunately

I honestly think for the sorts of websites you make in SquareSpace, they shouldn't be. There's no reason that to develop a static website (even with some dynamic elements like a shopping cart) that you should need e.g. a build process to target modern browsers (i.e. consumers in Western economies).

But this is probably me being idealistic. It's why I like things like hyperscript... it feels like we might be _just_ on the cusp of what I'm saying being true.


This is incredible. I’ve been looking for something like this for a long time. Love the site and documentation, please keep up the fantastic work. I am excited to play with this over the weekend and see what I can make!

htmx looks super intriguing.

Anyone have recommendations for server-side languages that make HTML templating fun? I’m leaning towards Elixir+Phoenix using sigils[1]

[1] https://hexdocs.pm/phoenix_html/Phoenix.HTML.html#sigil_E/2


HyperScript is so cool. I’m seriously going to look at this after I was stuck in a pit of addEventListeners yesterday.

:) it's pretty cool, but also pretty alpha

happy to help you get started if you want to jump on the discord


beautiful solutions, thank you for ur work

Is there similar solution for manipulating tables and json? I am not a front-end developer, so when i am preparing a poc, it always takes me so long to parse data in a table. Someone must have done the same thing as htmx for tables, or i hope ...


what kind of manipulations?

you can implement server side versions of most manipulations and then use htmx to trigger them and rerender the whole table, if that's acceptable from a UX standpoint

here is an example of active search that filters a table:

https://htmx.org/examples/active-search/


on the same note, I'm really enjoying basecamp/hey's hotwire stuff together with go templates.

will be checking out htmx as well, thank you for the links.


Just wanted to thank you for htmx!

I worked as a full-stack developer up until 7 years ago. Evaluating different options for my new website, I ended up just using what I'm familiar with: raw, vanilla PHP, HTML, CSS, and JS. Eliminates the need for any faff like server management on my part; PHP-enabled hosting is cheap and easy. No frameworks, just PHP. Not that novel, I know.

There's a stark difference in research and production in terms of output, for me. If I wanna get stuff done I have to think less in terms of the newest, coolest thing and just use the right tool for the job.

Edit: Wrote some details on the design and implementation [1]

[1] https://hypertele.fi/ec997be8c5933e87


We’ve got a similar setup. To add to what you said, PHP scales horizontally remarkably well because there’s naturally no cross-request state, so when you hit a certain point you can just throw another identical server into the mix.

We run autoscaled ec2 instances behind an AWS load balancer and Aurora but manage to keep a pretty simple PHP app serving millions of students a day.

For some of the more CPU intensive work we have a couple Go micro-services in the mix. Go is well worth anyone’s time to learn imho, it’s a very nice mix of powerful and easy to learn.

TypeScript in strict mode also keeps your JavaScript honest which I appreciate.


I'm not trying to impress anyone, I just want to solve business problems quickly, get paid, and go golf. I firmly believe that high productivity can be achieved by using boring technology. https://expatsoftware.com/articles/happiness-is-a-boring-sta...

Here is transcript of a talk about that same idea: http://boringtechnology.club/

Cheers. Found a recording of the talk: https://www.youtube.com/watch?v=wUmx-dlYS34

I only made small changes to my workflow over the last 10 years. My productivity is way above average.

Same preferences, I learn what is new (at least 2-3 year old) but stick to vanilla PHP, JS and HTML.

though I prefer learning a new programming language every year.


Then why post about it in a thread about novel tools? Great, your small blog doesn't need frameworks.

Chiming in here with my latest "weird but cheap" stack:

* Use a Trello board as a free CMS. * Write cloudflare worker code to read cards from the board via Trello APIs and render card content as plain old HTML.

I use labels as tags for the categories, and have specific formatting in the card descriptions. If an attachment is a YouTube URL, it renders the video as an embed, otherwise it uses image attachments as post images. Card covers render as the link thumbnails on the list pages.

Powers our family YouTube blog: https://thunderiron.family

(Check it out if you like fun and delicious Keto recipes)

An earlier version of this stack powers my personal dev blog, and the approach is written up here:

https://splatcollision.com/page/meta-post

What is particularly cool is that I can post things right from my phone using the Trello apps!


Nicely done! In pre-COVID-19 times, Atlassian used a similar hack for its catered lunch menus: a hand-updated Trello board stored the menu items, along with some data about which items are vegetarian, gluten free, etc (using labels?), and then that spat out a nicely formatted menu at a well known URL / on some TVs. Little bit of ingenuity goes a long way to avoid having to maintain yet another piece of software :)

Damn! That's certainly novel.

Nice work.


haha brilliant!

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 took a bit to get used to it, but I managed to get quite productive with it in the end.

I do occasionally try out more traditional things or the latest stuff but... using my own code feels a lot more gratifying. If I needed something different, I found myself building it from scratch exactly like I wanted it.


Now I really want to know which operating system you use.

Neat! I was playing around with min a while ago and it was fun.

I'm using a combination of Elixir, Hugo, a bit of Python and GitHub Pages for a personal site that hosts my poetry. I set up a simple hourly job in elixir to check Evernote for any new poems I've tagged with poetry:publish. If a new poem is detected, the elixir job downloads the text, runs it through a Python script to add it to the Hugo repo, regenerates the static html and pushes the updates to GitHub.

Overall I'm a huge fan of Elixir, it's incredibly reliable and easy to pick up for simple server tasks. Plus the scheduler is built into Beam, no need for any extra deps. My only complaint is needing to rely on extra python to convert the ENML to HTML, but that's a very niche library so not surprising that it doesn't exist in Elixir yet.


SvelteKit, Serverless, Backendless.com

SvelteKit[1] is a framework for SvelteJS (like Next.js is a framework for ReactJS). I've tried both Svelte and React. Svelte seems to be more elegant and lets me implement my ideas faster with less code. Svelte is very flexible; SvelteKit adds some opinions on how to do things like routing.

SvelteKit also embraces the serverless paradigm[2] (AKA JAMstack[3]). Although a node.js server is still an option, you can also have pages rendered in serverless functions or pre-rendered at build time. Even static pages can be "hydrated" on the client so they are not totally static. So this results in fine-grained SSR (server-side rendering) at the page level. The two main reasons for SSR are performance (especially on mobile devices) and SEO.

Backendless[4] is a VADP/MBaaS. This platform offers a lot of services, but the main one I'm looking at is authentication/identity. I was looking for an authentication service that supports anonymous guest login, social login, as well as traditional email/password login. The other contenders were Google Firebase (slow, and confusing sign in/sign up flow[5]) and AWS Cognito (too complicated/difficult to use). Auth0 was a contender, but they don't support guest logins.

[1]: https://kit.svelte.dev

[2]: https://www.serverless.com

[3]: https://jamstack.org

[4]: https://backendless.com

[5]: https://github.com/firebase/firebaseui-web/issues/665


This whole thing feels like layers upon layers of complexity. Not to mention, the brittle aspects of any javascript project - immature, lack of robustness and dependability. Your stuff is working on Node v12? Good luck with Node v14 - both LTS versions. It is a shitshow. Let's keep Javascript inside the browser IMO.

SveltKit is literally 2 months old.


"What novel tools are you using to write web sites/apps?" ??? is that not the prompt

SvelteKit as a project is literally 4 months old (since announced), but Sapper (the predecessor) have been around for longer, and SvelteKit has been used on NYT's county-level COVID tracker. There will be some teething problems but it's definitely not a totally greenfield project.

Well, Svelte itself is a bit older than that. And of all the modern Javascript frameworks, Svelte has been, for me, the most joyful to work with.

However, to your comment, I agree - there's unnecessary amount of complexity in the stack above. For me, it's usually Svelte in front, with any server side application.


- tailwindcss

I moved a React side-project from CRA to Next.js for server-side rendering benefits, but the latter doesn't support directly importing css styles in jsx to avoid problems with the global scope.

The two options offered were CSS modules and CSS-in-JS. I didn't like either approaches having hashes in the classname when opening the website in devtools, and both seemed too locked into React/JSX.

Tailwind 1. doesn't have component framework lock-in 2. doesn't make me think of css classnames 3. atomic classnames are readable in dev tools 4. provides default colors and box shadows, etc.

In addition, they're starting to make a render-less component library (https://headlessui.dev/): that means you can customize how components look without having to understand how its javascript internals work, which I'd find a huge plus compared to other libraries like ant design or material-ui.

- vite + react

More beginner friendly than webpack in starting a new project, and faster developer experience: page reloads almost instantly when you're modifying a component.


I really don't get the appeal of tailwindcss, and I feel like I must be missing some obvious benefit of using it vs something like bootstrap. But at first glance, it just looks like the framework recreates css rules with class names. What epiphany am I missing here?

> framework recreates css rules with class names

Pretty much, but that concept by itself is underrated. By having all of the CSS inline on your components, the developer doesn't have to click on a class name and find the css file associated with producing that class.

Tailwind is also a design system, so some non-obvious rules like box-shadows, colors, font-sizes are pre-picked. That means instead of remembering what font-size to use for a figure caption, "was it 0.85rem or 0.75rem", you can just use `text-xs`. Design constraint is good here because you get a consistent look throughout your app. It's kind of like having global css variables: by modifying your tailwind.config.js, you can change all `text-xs` to a different font-size now.

And then when you want to break out of that design system, "I need something smaller than a caption, say text-2xs", you can extend tailwind by defining your own atomic class names.

> benefit of using it vs something like bootstrap

Haven't used bootstrap since my first basic website years ago, but it seems like a vanilla js component + css library. Tailwind is primarily a css library, so you can use it with React and Vue as well. The way you install Tailwind is different too: Bootstrap you put into the head of your document and no build step is required; however, with a build step, you can remove unused css to get the minimal working spreadsheet.


it removes the separation between your structure and your styles so you can style as you go.

this sounds wrong because “separate responsibilities!” but in reality structure and style are so interconnected, for html and css, that you’re often changing one with respect to another so why not colocate the info.

also, managing a large css stylesheet is often terrible and it becomes write only as a result. it is easier to add new styles that override than attempt to find out which styles impact your target elements and change then. this is again due to the way that structure and style are intimately linked for html and css.

its better than writing raw styles on the html because that is rather obtuse, tailwind shortens many of the common style attribute names. e.g background-color: #efefef becomes bg-gray-50. this links into then named color palette that tailwind gives you.

also, *everything* is configurable.


There's a few major benefits with Utility CSS.

1. You don't have a dependency on raw CSS which is inherently nested and globally changeable. Instead you depend on tailwind.css and all your HTML describes the styling. This also means you can reliably copy chunks of HTML with tailwind classes.

2. Composition over inheritance. CSS is based around the idea of classes and selectors inheriting each other, which makes the style brittle and hard to follow and copy. Tailwind is composed of completely separate classes, which don't affect each other.

3. You actually learn CSS!! Other frameworks like bootstrap hide a lot of CSS features behind classes intended to simplify development. But this actually obscures what's going on with the CSS. Tailwind actually helps you understand how CSS works by having them easily accessible by utility classes.

    class="flex flex-col" 
   
Is the same as

    style="display: flex; flex-direction: column;" 
   
So you learn how to write better raw CSS too!

I seldom write CSS. I tried tailwindcss on one of my recent projects that required to closely follow a custom design (a portfolio for a graphic designer friend). I like it, with some caveats.

Main benefit for me is that I don't need to remember how to write css. 95% of what I need is a shortcut away from tailwind docs. The result is "prettier" than any other website-from-scratch I've done (that's purely on me, not much css practice). Now that I've memorised most common tailwind classes, I'm also moving faster than ever.

Main downside is that it's annoying having to modify tailwind's config file to add non-default variations (mostly different heights/widths than what it ships with).

Maybe something like Girouette[0] would be better.

[0] https://github.com/green-coder/girouette


> add non-default variations (mostly different heights/widths than what it ships with).

Check out https://github.com/tailwindlabs/tailwindcss-jit. It got released 3 weeks ago, and supports variable variables in width and height now.


Ah thanks! Will check out.

By the way, the project I linked is actually the same idea as tailwindcss-jit, but made from scratch, and in Clojure.

I'm not sure how easily I'll be able to use tailwindcss-jit since my projects are in clojure (it won't be able to automatically pick up the classes I use), but I might be able to feed them to it somehow.


Fav thread ever!

A good 5+ years ago I built HasGluten [1] with react backed by a google spreadsheet, hosted on github pages. Proven technology, it's still working.

More recently I hacked together MultiPreview [2] with react + API served by firebase functions. I'm also temp using firebase hosting as I have little traffic, but plan to replace it with edge computing / CDN caching.

MultiPreview is backed by Saasform [3]. This is more like a classic node/express (nestjs) application, but I really like how we're separating concerns: the SaaS = MultiPreview handles the biz logic / Saasform handles landing page + auth + payments.

While building the new landing page I played with and liked a lot Bulma [4], I used but didn't like AlpineJS [5] and I'm thinking to move to Hotwire [6].

My personal experience is that performance only matters when you're big enough, so in the near future I want to experiment more on usability / nocode side. And I'd love to see more open source alternatives to the big ones.

[1] https://hasgluten.com

[2] https://multipreview.com

[3] https://github.com/saasform/saasform

[4] https://bulma.io

[5] https://github.com/alpinejs/alpine

[6] https://hotwire.dev


You might want to check hasgluten.com's cert:

>> Firefox does not trust this site because it uses a certificate that is not valid for hasgluten.com. The certificate is only valid for the following names: www.github.com, .github.com, github.com, .github.io, github.io, *.githubusercontent.com, githubusercontent.com


Thanks - fixing.

Semantic HTML, CSS, Vanilla JS, and JAMStack.

Semantic: embed data directly in HTML. If I have a list of wines with categories, each wine's "class" attribute has a class for each category.

HTML: can be generated by anything and consumed by anyone. Great SEO.

CSS: These websites were all made with the same HTML, only CSS changing. http://www.csszengarden.com/

Let's imagine we have a checkbox, that when checked, should dim every wine that is not a white wine. Next to it is a div of wines, with the "container" class. The div contains wine elements.

3 lines of CSS:

    input[type="checkbox"].whiteWine:checked + .container > :not(.whiteWine) {
        opacity: 0.5;
    }
You can replace the checkbox's appearance with an image, a video, just about anything– it doesn't have to look like a checkbox.

This would take many lines of JavaScript in any other framework.

Instead of attempting to warp HTML into a UI library, this uses HTML as a data format, and CSS as a way to present that data.


IS CSS really this well featured and expressive these days? I havent tinkered with it in years.

:checked and :not() have been dependable for quite a few years now. Firefox has had ’em since at least version 1 (2004), Safari got ’em in 3.1 and 3.2 (2008), and Internet Explorer was the last player to the table in Internet Explorer 9 (March 2011). The rest of the selector features (tag, attribute, class, adjacent sibling, child) are older still (IE7 supported it all).

That's totally awesome. Everyone always just jumped to JavaScript for that kind of thing with jQuery.

Yep, thank god for flexbox and grid layouts.


Indeed, and that website only uses 2010 CSS features.

What happens when your wine types are dynamic? How do you typically bridge the gap?

What’s old is new again <3

Great example, btw!


This is the first thread in a long while that's given me a lot of FOMO anxiety. I've made a lot of one-off server-side rendered apps in Flask, and right now I'm doing some backend work ASP.NET Core for my job, but I have this overwhelming feeling there's so much I don't know and I'm not sure where to start. I only bring this up in case I'm not the only person sharing these feelings.

It's not a feeling, it's an observation. Technology is like a tree, branching infinitely in all directions.

When I was a baby web developer, just knowing CSS on top of HTML was considered advanced. (This was back when the bleeding edge was using tables for layouts.)

Today, I can't keep up with all the different ways there are to do something as simple as loading a web page.

This splintering is true in every area of tech.

At first it freaked me out, but I've accepted two things:

1) The only option is pick a path and specialize in it, knowing there will always be things I won't know. There's nothing wrong with learning new ways, of course. And often that's necessary. But I've given up on trying to master all of them.

2) Just because something is new and popular doesn't make it right. The proliferation of frameworks for otherwise simple things (like loading mostly static web pages) is one such example.


Honestly I don’t think you should worry about it. Once you know how to program, you know how to program - the fundamentals don’t change very quickly. Anything you don’t know now you can learn when you need it. The most important thing to retain is your love of learning and excitement about new technology, so that when the time comes for whatever is next you rise to the challenge with enthusiasm.

I feel this a lot too, but I find that I can quell the anxiety by looking at the huge list of $things_i_dont_know not as a chronicle of how far behind the curve I am, but instead as a buffet of new techniques/technologies that I can sample. Many will be irrelevant to the things I'm building, but some will likely help improve my productivity or ease my maintenance burden.

So I try to have a taste of one or two new things every so often; try them out on a couple of projects to see if they help me, or if they just confuse and overcomplicate. I'll never be able to try them all, but I feel like I slowly get a better understanding of many of the new items, and feel a bit better about ignoring things that I've already established aren't likely to help me to be more productive.


Try this for size: Are you feeling effective at what you currently do? Is there any tangible reason why that would change for the worse in the upcoming year?

If not, you are doing fine. There is absolutely nothing out there that obviously and significantly increases your output by dropping whatever tooling you are effective with already and switching as of this time. I have looked. It's sobering.


Im even lower-level in the stack, and some of the comments make me want to just learn php. I remember one comment where Joel Spolsky wrote on twitter where he wrote stack overflow in asp .net and scaled it running on one box. Its all about getting stuff done.

There is a 99% chance that you will not need whatever “tech” you are reading about. Keep up to date with what is out there but only deep dive if it might solve a real world customer problem you are actively having right now and the cost of the deep dive is less than the potential value gained.

Elm + elm-ui[1] (dont worry about CSS so much) + generated Elm client lib from GraphQL schema + Hasura (GraphQL over Postgres) + Postgres => strong type safety from db schema to frontend with SPA-first workflow; possibly add ReactAdmin[2] to the mix if that sort of thing is needed.

Rust + Actix + Yew (Rust browser framework compiling to WASM) => also verrrry nice vor SPA-first!

Slightly more traditional: Kotlin and jOOQ on the server side.

I also tend to let go of the HTML syntax lately, by using templating eDSLs such as in Elm, or in Rust's Maud[3], or in Kotlin's kotlinx.html or HtmlFlow.

[1]: https://www.youtube.com/watch?v=Ie-gqwSHQr0

[2]: https://github.com/hasura/ra-data-hasura

[3]: https://maud.lambda.xyz/

[4]: https://github.com/Kotlin/kotlinx.html

[5]: https://github.com/xmlet/HtmlFlow


As someone fairly new to elm:

How do you mix Elm with something like react-admin? Do you set up an elm SPA and embed the react part as a custom element? Or do you go the other way around, having the main App be JS controlled and only some components be an embedded elm App?


No mixing. react-admin serves as a quick standalone admin interface.

I see, thanks for the response.

Hasura + the React Admin plugin is a godsend, allowed me to focus on the SwiftUI app I was writing and barely have to think about the backend.

I have built an app template which uses Go html/template package to render html on the server. The app is enhanced using sprinkles of javascript(stimulusjs, svelte single file components) on the client, wherever needed.

1. template: https://github.com/adnaan/gomodest-template

2. template demo: https://gomodest-template.fly.dev/

3. SAAS starter kit using the template(wip): https://github.com/adnaan/gomodest-starter

4. SAAS starter demo: https://gomodest.xyz/

[edit: formatting]


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 available here: https://github.com/amacgregor/amgr_phx


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.).


Just finished working on the first iteration of a website for my mom. I didn’t want to deal with a full classical CMS and maintain Databases and such, especially as my experience with wordpress, PHP and typo3 has faded a little bit.

My mom’s website is basically a directory of old mansions in former eastern Prussia. Site is in German: https://gutshaeuser-ostpreussen.de

Anyhow Stack chosen:

Backend/CMS as a Service: https://prismic.io/ which is really great because it has an easy user interface that supports drafts, media, i18n (planning a polish version of the website) and defining custom types for pages which is great to force my mom to enter data consistently.

At first I used their SDK to simply query the data and rendered the Page while writing my own static site generator. Obviously very tedious. Since then I have moved away from that and landed on Nuxt which works well for me, because it allows me to iterate faster. Nuxt also supports rendering static pages https://nuxtjs.org/blog/going-full-static/. All of the JavaScript bits are basically progressive enhancements.

The page is then deployed via GitLab pages. Every time my mom changes a page, a webhook triggers a build of the Site.

What really eases my mind is the ability to simply backup all the data entered, as simple JSON files. So I don’t feel like there is any big vendor lock in with Prismic.


Regarding Prismic lockin: Have you checked whether the exported .zip contains the entire media library?

Regarding SEO: If you (i) host the Cormorant Garamond font locally and inline its CSS, and (ii) use srcset to serve a smaller hero picture on mobile, you will probably achieve a 100/100 score in lighthouse.


Didn’t think someone actually looks at the page. Thank you!

Currently I am just saving away the page contents as a JSON when rendering the page. My mom has all media locally. TBH, I considered just crawling all the pages and media via the API/SDK with a scheduled job in CI. Maybe saving them in a git repo to get history for free or just uploading a zip every week to backblaze.

Thanks for the SEO tips. Will definitely look into hosting smaller images and the font, also need to add meta tags for descriptions, maybe some JSON LD and other shenanigans for Facebook, Twitter, etc. Had to focus on the mom-visible stuff first ;)

Also wanted to look into analytics with something privacy friendly like https://umami.is/


I've been using my Datasette tool, originally intended for exploring databases, to build full-blown websites and it's working surprisingly well. It supports Jinja templates and runs on SQLite databases so it's actually a good fit for semi-static sites.

Here's what Datasette looks like by default:

- https://latest.datasette.io

And here are three websites that are actually just Datasette with some custom templates and plugins:

- https://datasette.io (data: https://datasette.io/content code: https://github.com/simonw/datasette.io )

- https://til.simonwillison.net (data: https://til.simonwillison.net/tils code: https://github.com/simonw/til )

- https://www.niche-museums.com (data: https://www.niche-museums.com/browse code: https://github.com/simonw/museums )

They're all hosted on either Vercel or Google Cloud Run at the cost of no more than a few dollars a month.


Just to add some off-the-beaten-path solutions I've come across recently:

https://github.com/Bogdanp/koyo - Koyo: a web app toolkit written in Racket

https://github.com/yawaramin/re-web - ReWeb: a ReasonML/OCaml web framework

https://cons.io - Gerbil Scheme has an embedded web server that supports writing handlers for


https://aantron.github.io/dream/ - Dream, also a web framework in OCaml/ReasonML

I've built a tiny pet project [0] that uses JSON Schemas [1] extensively.

Data is defined by the schema and it's used to build a static JSON API on GitHub Pages.

OpenAPI [2] definition for API reuses data schema and you can use OpenAPI Generator [3] to generate clients.

The site uses docsify [4] to display repo's README nicely.

[0] https://beatcracker.github.io/toptout/

[1] https://json-schema.org/

[2] https://swagger.io/specification/

[3] https://github.com/OpenAPITools/openapi-generator

[4] https://docsify.js.org/


Django, Hotwire/Turbo+Stimulus, Tailwind, Postgres. The codebase is small, easy to reason about, and maintainable, it's easy to build an accessible site on top of semantic HTML, and it's fast and responsive enough for my needs. It's nice to use JS for things it's best suited for rather than being responsible for running the whole application. Tailwind has its detractors but honestly I've found (as a decidedly non-frontend person) that it's very productive for building out a responsive design with good support for dark theming.

I’ve been playing around with code sharing options between web, mobile and desktop platforms.

The idea is that the app core is written once in Rust and bindings are automatically generated to all target platforms.

I have a project that starts with protobuf files and generates Rust for the shared core, and Dart (ffi) and JS (wasm) for the client stubs. The generated client interface is “platform-native-async” so Dart Futures or JS Promises. The bridge passes protobuf messages back and forth between both language contexts and takes care of the threading/async mapping.


If we do green field development, we often end up with a stack like this:

- Backend: Java + Spring Boot

We went there from node and we did try a lot of other backend stacks (Go, PHP, Clojure, Python, ...). Java has evolved quite nicely recently, APIs and libraries are rock-solid, well documented and battle tested. I plays very will with our DDD approach anyway. Many problems have already been solved for us here. Flyway for migrations, custom session handling mechanism. We do not use an ORM.

- Frontend SPA: Svelte

Again, we tried most of it, from vanilla JS, over Backbone+Marionette through React, Angular 1 - ?? and Vue. Svelte is a good compromise of an opinionated approach, high flexibility and ease of learning. It scales very well for big applications. Built with webpack.

- Frontend styling: Bootstrap

Yes, we developed with all of them again, even wrote our own. IBM Carbon is nice, but the svelte implementation has potential for improvements. People tell me everything looks like Bootstrap, but the point is: it's well tested, very well documented, extensible and accessible, has accessibility concerns baked in and can be themed easily. If done well, an app doesn't have to look like Bootstrap. We might pull in Tachyons for utilities if necessary.

- Data store: MySQL/MariaDB or Postgres plus Redis

You name it, we tried it. Postgres never let us down, we know it very well and its SQL support is a breeze. I personally like MySQL/MariaDB for some technical reasons. We had mixed experience with SQLite and bad experience with SQL Server. Oracle is pretty good, but the pricing is no in our favour. Everything related to caching and session handling goes into Redis. For search and analytics, we might pull in Elasticsearch or InfluxDB.

- Configuration

Config files or environment vars à la 12 factor app. We use Hashicorp Vault for bigger systems. We are dispassionate, though, what ever the client has decided to suffer through will be supported.

Complementary tools and technologies: Docker, docker-compose, Docker Swarm in prod, trying out Dokku at the moment, Keycloak for OAuth, Jenkins for CI/CD, people are trying to convince me to use Github Actions. Deployments are usually done on big machines on an IaaS offering (we run Azure and AWS as well as bare metal), no cluster systems, no micro services. We do not use Kubernetes.


I built Nodewood: https://nodewood.com

I really enjoy NodeJS/Vue for web apps, but I got sick of having to connect together all the packages from scratch each time, set up ESLint, testing, database connections, write the user auth/management, all that common stuff. So instead, I put together a boilerplate with all my common practices and basic app features. I figure, it ultimately saves me time on all future web apps, and if other people want to build a similar style of app, spending a few hundred on a decent boilerplate is cheaper than hiring a freelancer to do it for it, or even doing it yourself, if you value your time at anything higher than minimum wage.


My ex-company was an web agency, we were spinning out new projects every few weeks. I developped a "project generator" (more dynamic than a boilerplate) that would create a full project with Django-React-ReactNative-Postgres, with the Terraform configuration to deploy to AWS. Apparently it was huge for sales, and got projects starting on the right foot. You can probably make that into a full product!

I wouldn't call it "novel", but I've lately turned to designing APIs first using OpenAPI [0], and then using that specification to drive routing and validation using (shameless plug, but that's what I use) pyotr [1].

[0] https://swagger.io/specification/

[1] https://pyotr.readthedocs.io


Have you heard of tabulator? tabulator.info/ - I honestly don't know how my spreadsheet based project would have been possible without this amazing library (and Flask with Jinja)

On the personal side I always love using Processing (p5js.org) for interactive canvas visualisations. I recently found out that this can be used with react, so that's the basis for my next learning project.


If you're interested in hearing about what folks are using I have a podcast focused on this exact topic at: https://runninginproduction.com/podcast/

There's 75+ episodes with a new guest / app in each one. We talk about what tools folks use to build and deploy their apps, the why, best tips, etc..

At the moment there's 188 distinct tools (languages, web frameworks, various services, etc.).

Personally I'm a big fan of Flask and Rails with mostly server rendered templates. Lately I've been combo'ing that with TailwindCSS, Hotwire Turbo and StimulusJS for the front-end.


I have been enjoying building apps with https://hotwire.dev (server-side rendered with JS sprinkled on top) after using React/Vue heavily in the past.

I'm amazed at how simpler & productive it has become to build apps without getting lost in the whole JS tool ecosystem.


Django with raw SQL queries. HTML using templates, with CSS files for repeated styles (eg defaults for a given element type), and inline styles for one-offs. Modern javascript for targeted interactions like managing shopping carts through local storage, validating forms with visual feedback, and processing payments.

Typescript as-required; better language, but adds a build step.

Rust is promising for both front and back end, but backend frameworks are too sparse for websites, and frontend leads to large downloads for the client.


A while ago I created a simple website using an XML file as a storage technology and XSLT to render it to HTML. The data stored would be updated infrequently and suited a consistent format, making XML suitable for the job. Originally the site index file pointed to the XML file and the XSLT was rendered by the browser. This worked perfectly for a long time. Even though there was some technology to learn, it was a zero dependency, browser-native solution.

After a few years I decided to make everything completely static to facilitate some changes. It now uses lxml in a Python script to perform the XML transformation. This is run by a makefile and produces static HTML, which is then uploaded.

My blog (https://ajxs.me) is rendered using a static-site-generator I built myself in Python. Using Python template strings stored in HTML files to create a simple templating engine. The blog entries are written in HTML format and stored in an SQLite database loaded by the build script. The final output is entirely static HTML, not even any Javascript.

I'm experimenting with different formats for writing the entries themselves in, however I haven't found anything yet that gives me more simplicity and control than HTML. The LaTeX to HTML conversions I've tried were way too bloated and messy, and markdown doesn't seem to support the level of control I want. With HTML I have very granular control over the final output in the browser and can create whatever arbitrary content I need to.


Some recent projects:

- Frontend only, plain javascript, but a lot of it uses a project-specific custom scripting language. This is a game that consists almost entirely of procedurally generated written content, so I write a language that makes it easy to categorize procedural content bits and make sub-calls to new ones. I have a long way to go on language design still, but it's already better than a json blob.

- HTML frontend with some small plain javascript. Backend is node/express, but most of the heavy lifting is done by a shell call to Coil Snake[1], and which inserts a ton of code in ccscript and 65816 assembly. This is a randomizer for Earthbound (http://pkscramble.com/), so those are super specialized tools for that purpose. But I really like the Coil Snake ecosystem, and it's definitely going to influence my projects going forward (the decision to use a custom scripting language above was influenced by ccscript).

- Plain javascript frontend, vertx backend, postgres database. This is my goto for serious projects. It's fairly boring.

[1]https://github.com/pk-hack/CoilSnake


A shameless plug - but I'm attempting to build a kind of "deploy first and develop as you go" kind of system for this, inspired by the Smalltalk IDE and VM.

Link - https://github.com/imaginea/inai

Associated post - https://labs.imaginea.com/inai-rest-in-the-small/


I'm using SvelteJS[1] (specifically, Sapper[2]) on my product ListenAddict[3].

On other products I'm using SvelteKit[4], which is the spiritual successor to Sapper, but it's _very much_ in beta, and I wouldn't quite recommend it for production yet (even though it is being used in production for the NY Times).

I've found Svelte to be amazing to work in, especially compared to React/Vue/Angular. The compiler is great, and the final size in production is fantastic. It's also super easy to do things that I previously found annoying/hard/long-winded to do in React.

[1] https://svelte.dev/ [2] https://sapper.svelte.dev/ [3] https://www.listenaddict.com/ [4] https://kit.svelte.dev/


I made my own app. server with built in distributed JSON database that can hot-deploy directly from your PC to a cluster of servers async. = instantaneously.

This means I have 1 second turnaround from idea implemented to testable on a copy of live.

Other than that I am still on manual HTML, CSS and vanilla .js!

JavaSE for server and javascript for client.

HTTP Comet-stream over XHR/Fetch for real-time.

Single serving database salt SHA256 for security.


I'm using a tool I built myself for simple internal apps: https://github.com/yazz/visualjavascript

I use Cloudbackend [1] to create my projects serverless sql database and APIs with the API builder, it's generating the node.js code and publish it to aws lambda. For the frontend I use either Vanilla js (no framework) or Vue.js [1] https://cloudbackend.appdrag.com/

I built GoodPlates [1] using Netlify [2] for rendering the HTML, JS, CSS. Instead of using vanilla CSS, I used TailwindCSS [3]. My backend consists of API Gateway [4], Lambda [5], and DynamoDB [6]. I also use CircleCI [7] for deploying my API Gateway / Lambda changes.

[1] https://findgoodplates.com/

[2] https://netlify.com/

[3] https://tailwindcss.com/

[4] https://aws.amazon.com/api-gateway/

[5] https://aws.amazon.com/lambda/

[6] https://aws.amazon.com/dynamodb/

[7] https://circleci.com/


I use a pretty standard Rails stack, but just wanted to give a quick shoutout to Stimulus Reflex[1].

For the web app I'm working on, I wanted to add some real-time functionality (e.g. being able to broadcast updates to all the users on a given page in my application, and have them interact with each other) without having to write a full SPA. I ended up implementing that functionality using Stimulus Reflex and it's been great.

Stimulus Reflex uses: 1) Stimulus JS for frontend functionality 2) CableReady, a websocket library built on top of ActionCable 3) morphdom, a clientside DOM diffing library to update your UI

I'd recommend anyone who wants to incorporate some more advanced functionality into their Rails app to take a look. (I can't speak to how it stacks up against the new Hotwire/Turbo stack, as I haven't built anything with that.)

[1] https://docs.stimulusreflex.com/


I'm a college student trying to get into software development. I was recently hired to build a dashboard around some data stuck in an archaic platform.

I went with Phoenix and Elixir, and I really liked the combination of a focus on development enjoyment (inspired by Ruby on Rails) combined with an anti-magic attitude, so you can trace through what actually executes pretty easily. I haven't had much other experience though, so that that with a large grain of salt.

My client was very happy with the speed of development and quality of the final product, so I consider it a successful choice by the main metric that matters here.

Edit: The main pain point has been deployment. I spent an afternoon on some shell scripts that scp to a virtual server that mostly work fine, but I don't understand sysadmining very well and I I'm pretty sure they'll blow up on me at some point. It would be really nice if there was a tool that took care of the actual servers part for me.


My main issue with Elixir (and maybe this has changed in the last 3 years since I looked at it), is that there isn't a strong open source package libraries available like you see in Rails. People complained that you end up writing boiler plate code for things that in Node or Ruby would just be a package.

I've heard great things about the language and framework though.


I haven't run into many issues where I wished there was a package, but I haven't programmed a web app in a language that had a lot of packages available.

The main close call I had on this project was that there was only one package that supports generating excel spreadsheets, and it's a labor of love by one person. This wasn't a huge issue for me, I had a plan to write csv and then convert if it didn't work, as I didn't need formatting/fancy output. It turned out to work great, so that wasn't necessary.

There was an excellent transactional email library that hooked into the standard templating system, and a few so-so approaches to authentication. I ended up rolling my own on top of a decent crypto library.

For the non-web-speicfic bits I haven't found this to be an issue, Erlang has a whole kitchen sink with OTP (even if like a real kitchen sink it's a bit grungy if you look inside), and I've found plenty of algorithm/data structure-y packages.


For my personal website/blog, I use the beautifully simple static site generator makesite.py.[1] For the other sites I've made, I've used WordPress or plain old no fuss static html/js/css.

[1] https://github.com/sunainapai/makesite


I'm currently working with the AWS CDK and the more I used it, the more I have the feeling tools like that could be the next big thing.

It's melting the walls between cloud infrastructure and application code and the fact that it does IaC with the same language I use to program web apps (JS/TS) plays an important role here.

I think, it's not 100% there yet, but it's on a good way.


I spent a lot of time with CDK last year using Typescript. Very impressed with it and I have zero regrets after moving over our app's infrastructure to being deployed with it after 9 months in production.

I felt like being forced to use typed IaC helped me understand AWS API's and services themselves better.


While I'm not a big fan of some decisions the team made when building the CDK (the whole class/context stuff feels very un-javascript-y), it was the first project where I appreciated TypeScript over JavaScript.

Go + VueJS are serving me great. Deployed on AWS Lambda.

E.g. https://github.com/kaihendry/goserverless.sg


Novel... for Hacker News

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


I'm doing Fullstack with Angular + Spring Boot Kotlin.

I love writing the backend but the frontend part really seems overly complex.

In the end I'm just mirroring my data from the backend on the frontend, having to maintain two models, mapping the json to an object and then inputing that data into another component where it gets displayed. For example I tried to create a generic edit component but without reflexion it was a huge pain in the butt: https://github.com/tschuehly/DataRecovery/blob/f4003ddebbba7...

I would love to just have an html structure and then just having a template for a component filling it in the backend and sending it to the frontend.


hugo[1] for static websites, that need SEO

SVELTE[2], routify[3] and Orbit.js[4] for SPA Frontend with API requirements API Platform[5] or JsonApiDotNetCore[6] for Backend

SignalR[7] when realtime is required

[1] https://gohugo.io/

[2] https://svelte.dev/

[3] https://routify.dev/

[4] https://orbitjs.com/

[5] https://api-platform.com/

[6] https://www.jsonapi.net/

[7] https://dotnet.microsoft.com/apps/aspnet/signalr


I'm really enjoying working with MDX (JSX & markdown hybrid). https://mdxjs.com/

I was able to quickly put together a blog with some pretty nice features (e.g. margin notes): https://pratik.is/writing/essays/media-as-food

Writing content in markdown while adding interactivity with JSX is pretty nifty.

If you click "Raw" here you can see how the blog post is just markdown with some custom JSX elements littered in, e.g. <WrappedSidenote />: https://github.com/pringshia/pratik.is/blob/master/pages/wri...


I'm from the "new camp", my career started with a React JS gig and I've been in that space ever since. My typical stack is React frontend + Severless backend + FaunaDB if I need a DB.

Everything is deployed via Netlify (well except the DB) and I use their functions to emulate a traditional backend.


Cannot recommend gqless highly enough for making graphql actually fun to use and closer to something like meteor/firebase syntax[0].

And I’ll self-promote, I’ve been working on what I consider to be a “next generation” style system for React that solves my biggest issue with it currently: being able to performantly write styles in a nice syntax that optimize for both web and native. Called SnackUI, still in beta[1]. It has an optimizing compiler that really speeds up React apps a ton, but still lets them run fully on native, even with themes and responsive queries.

I’ve been hacking on a cool project for the last year using the two of them and really believe in them both.

[0] https://gqless.com

[1] https://github.com/snackui/snackui


I've been using the Vacancy Observer pattern to do data-fetching in my React app for a few years now.

https://gist.github.com/greim/3de3bcb71a672e11c75e371b7b81f4...


For all of my new side projects I am all in on Phoenix live view. I couldn’t be happier, you can write web apps quickly and it is super reliable. It’s probably not the best choice for every project, but for now it lets me do a lot as a solo dev who has maybe 30 minutes to an hour free a day to code side/personal projects.

My personal project that has the most use is https://readastorytome.com/. Almost all of the problems/bugs I have with it are to do with my implementation of webrtc and pdf.js. Liveview has been the source of very few problems.

And tinylivechat.com is a WIP that is also using Phoenix live view but I am debating killing it


Why are you debating killing it? Is it not making any money, or is it too much to maintain?

It’s not making any money or being used yet (wip) and I have not had much time to work on it recently.

It’s been a great project to work on though. I have had to think about how I to handle a lot of issues that come with web chat widgets, like how and when you alert your customer they have a new message or how to create an embeddable widget.

Another possibility is I will just make it open source.


It is somewhat whacky, but what I'm doing is:

I created a library to have distributed data types directly on the browser [1]. So there are no servers, data is sync'd directly between people's browsers.

Then I created a library to bind react components directly to my distributed data types [2]. So the app is just a static page, hosted anywhere, that works as an SPA.

[1] https://github.com/hyperhyperspace/hyperhyperspace-core

[2] https://github.com/hyperhyperspace/hyperhyperspace-react


This is very interesting. I've seen similar peer to peer work with the DAT browser but this looks like it works in existing browsers. I'll definitely be checking it out.

My blog/homepage is built using:

- Gatsby.js static site generator framework

- Posts written as md or mdx (markdown with jsx support)

- Github Actions to build the site

- Published to and served by Cloudflare workers

- Uses [sci](https://github.com/borkdude/sci) and ClojureScript to add a live Clojure REPL component that can be used in blog posts

- Tailwindcss is used for styling via emotion css-in-js and a tailwind plugin.

The setup mostly works ok, but as always with the JavaScript community the amount of breaking changes can be a bit taxing. Because Gatsby handles static site generation the blog works without JavaScript enabled for those that only want to access the static content.


For my projects I've built most of the infrastructure stack myself:

- https://github.com/queer/singyeong if I need message queuing / etc

- https://github.com/queer/crush if I need a basic JSON store or cache or ...

- https://github.com/queer/mahou is my WIP to replace container schedulers

It's a very satisfying experience to see my own tooling reach this level of maturity ^^


I have been exploring offline-first approaches to building web apps.

In a nutshell, the UI interacts with local state, and a background service syncs local state with server-side state and vice-versa. This theoretically allows the app to remain fully functional even when offline, while maintaining the benefits of your stuff being accessible from all your devices. There's also UX gains as well - your UI interactions don't need to be blocked by network calls.

In practice, that means using something like IndexedDb to manage client-side state, and modelling data as CRDTs or similar in order to have eventual consistency with the server.


Python + Fast API. It's the minimal web framework I always dreamed of.

Loving FastAPI + Postgres for the (small) amount of backend work I do at the moment.

you should take a look at sanic https://github.com/sanic-org/sanic It's very popular among people writing async web services in python. It's like 10% faster than fast api.

For the Objective-S site, http://objective.st, I obviously had to create something in Objective-S.

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.


I'm currently working on a PaaS product called fold.sh (very early days).

One thing I'm using that I've seen crop up on this thread is tailwindcss... I've not used it before but I'm really enjoying it so far. It's not a panacea by any means - it makes no attempt to help you organise your CSS or make it modular so you need to 'bring your own discipline'. For example, it's fairly easy to end up with inconsistent design because it makes it so easy to just add a few custom tweaks here and there. That same feature also makes it easy to duplicate information.

That said, for the first time I feel like I can actually iterate quickly on CSS and design in general. That probably says more about me than CSS but I'm having a blast. The fixed set of choices and short/consistent class names mean that I spend less time reading docs and more time iterating, which is great in my book.

Maybe it's an approach that doesn't scale well to teams? Maybe I'll regret it later? Can't comment on that yet but it has certainly given me a step change in CSS productivity.

The rest of the tech I'm using is all pretty dull, with one exception, which is that I'm using the platform to host itself (the backend at least).

Hopefully this doesn't count as too much of a shameless plug but it certainly fits the bill of a 'different approach' as I'm the only user right now!!

The (very basic) landing page is here:

https://fold.sh/


> That probably says more about me than CSS but I'm having a blast.

No, that probably is just how CSS is - a pile of decisions based on obsolete or incorrect assumptions that cannot be allowed to change due to backward compatibility.

To me Tailwind is just a wrapper that's more reasonable for modern webdesign. Just like TypeScript doesn't change how you're still running JS but it's more pleasant to work with.


Interesting analogy to TS (which I'm also a fan of). I hadn't really thought about it like that but I think there is truth to it.

As you say, the fact is that we've got all of these standards that can't be be changed without breaking the web. Those standards were also first created for a different time, so it's not surprising that some assumptions turned out to be poor.

As a result, we've ended up in a place where tools treat those standards as compilation targets. This isn't a bad thing per se but it does lead to a lot of complexity in the tool chain.

I think part of why I like tailwind is that it almost feels like I'm using plain old CSS. I get the same amount of flexibility (as much as I need anyway), but I don't feel like there is some great abstraction in between me and the styles I want the framework to produce. At the same time, it's quicker and easier to use.

Anyway, I'm aware it's a pretty divisive tool. I see a lot of strong opinions about it on HN!

EDIT: grammar


Not sure if this counts, but for simple stuff (both front and back-end!) I've been loving regular JS template strings for rendering HTML. Your render logic ends up looking very similar to React functional components, and you can get editor extensions that do syntax highlighting inside the string.

There are obvious downsides - on the back-end it's slower than a proper templating system, and on the front-end you're rebuilding the DOM tree from scratch each time, with all the limitations that includes (performance, animations get interrupted, HTML state gets lost, any event listeners have to be re-initialized). But for simple stuff, I cannot recommend it enough.

Here's a back-end example from my personal website: https://github.com/brundonsmith/website/blob/master/src/rend...

And here's a front-end example: https://github.com/brundonsmith/blogs/blob/master/docs/site....


You may be interested in doing js template strings with preact/react - no build tools required! Btw there's vscode support for this so you get syntax hilight too

https://github.com/developit/htm


Avoiding transpilation is nice, but so is avoiding a library altogether. I take this approach when I just want to get going with zero setup and zero overhead; if I'm going to the trouble to set up React then I'll want bundling, and at that point I'll probably just go ahead and configure JSX and TypeScript.

I use janet-lang

The stack lately has been

- osprey (sinatra like framework)

- tailwindcss

- sqlite

- alpine.js

- turbo (from hotwire)

Memory usage is really low, so I can have quite a few websites on a single VPS


For non-app websites, so in other words for "static websites", I have worked in the last 15 years with many technologies.

First j was in love with server side rendering. Mostly it was PHP in many flavors. For projects I had full control over I even built custo frameworks. Then I tried server side rendering in nodejs with frameworks such as react-server. I must say that the overheads were not worth in my experience.

I also tried client side rendering with js frameworks such as angular (v. >= 2) and react, but to be fully honest that was a not idea solution for "static websites".

Lately I've combined all these experiences and I've built my own static web site builder, YASSB (https://yassb-foss.github.io/). I've built it combining what felt tome like the best features of all the above. In short:

- websites are pre-rendered and served as static websites

- pages are composed with reusable components, these can be simple HTML components or can be rendered with js.


I don’t do much on the apps/websites side of things. I’m a platform and systems developer by experience/preference.

That said, I’ve long maintained a blog. I prefer to build my own tools. I wrote a highly opinionated static site generator in Go over the course of the few evenings during March.

I used to use Ghost to host the blog on DigitalOcean but got tired of chasing NPM updates. I got a small VPS instead, installed OpenBSD, and now the site runs off relayd+httpd. relayd handles setting caching headers. httpd handles serving of HTML.

It’s working really nicely. If I didn’t use IBM Plex Sans as a font, my site would easily join the lists like 10kb club. I do set the caching header for it though.

Other than that, I’ve got a couple of side projects I’ve been noodling on. Back end will probably be Go. Front end app will likely be PHP/Laravel. PHP 7+ has been really nice to work with and it runs well on OpenBSD. If it ever got popular enough, shifting to elastic deployments with Docker/LXC/Podman would be straightforward.


I use Foam (https://foambubble.github.io/foam/) for my second brain and have it integrated directly into my website: https://anthonymorris.dev/second-brain

https://shuffle.dev - drag drop and export as html. Nice for landing pages

- Next.js (react)

- Chakra-UI (for ui + ux)

- Hasura (graphql + postgresql)

- Express.js (for custom actions, event hooks etc)

- Kafka for message brokers

Previously, I was fullstack javascript developer using raw html with only express js and its renderer. Later I discovered ui and ux, react with dsl also graphql as data layer overwhelmed me. So I found simple stack for faster shipping. Learning curve is not that difficult I think.


Been using Next.js and Chakra. Big fan of Chakra, it's the best UI library I've used hands down.

Client side: React - Typescript Backend: Phoneix - Elixir

We're a live message tool and it is basically what Elixir is built for https://github.com/papercups-io/papercups.

The Elixir community has been great and incredibly friendly. I originally was worried about the size of the community but that hasn't been an issue the community has been super helpful. I also think the annual stackoverflow usage surveys are very misleading because most of the community's questions get asked in ElixirForum and not on Stackoverflow.

Phoneix is the web framework of Elixir which is very similar to Rails but minus a lot of the magic has been very helpful for our productivity as well.

If I had to built another service that is websocket heavy I would definitely use Elixir. Even if it was a standard crud app I would still most likely choose Elixir.


I'm migrating a side-project that was served by a Django-based server running on Heroku.

Here's the new version (WIP):

https://www.blockstudio3.net

It's written in Haxe (transpiled to js), runs on a single VPS with all of its data in SQLite, and is cached behind a CDN, making it pretty snappy.


For my app I use React Native with a webview, I can't imagine doing native now and having to release for every change.

https://expo.io does things in a similar vein.

Svelte and feathersjs.

Feathersjs seems to be just the right amount of magic: choose a backend store with a model, and it creates REST CRUD endpoints for you.

You can drop down to middleware or ideally use "hooks" that activate before (e.g. permissions) or after (post processing) each CRUD call. A new endpoint is a breeze to set up.


I am building a tool to construct internal apps quickly: https://www.jigdev.com

The idea is that developers who know business problems are usually bad at frontend. This is a tool to help them build web apps without much html knowledge.


[Warning: Not Safe For Prod]

Pug and Stylus for html / css preprocessors, especially if you're new to coding.

I used to teach a lot of web dev classes to non web devs (mainly designers looking to upskill). One of the worst parts of html/css (or code in general), particularly when you're experimenting, is the strictness. Pug and Stylus are great preprocessors for experimenting and rapid iteration, particularly because they don't care. Pug doesn't care if you change between its syntax and html. Stylus doesn't care if you missed a ;, or a : in your style declaration. They are forgiving languages, essentially the antithesis of something like Typescript.

Absolutely excellent when you're trying to wrap your brain around something. I highly recommend them.


Many things can be a text messaging service or an email digest if that helps you think outside of the box.

This is the next big thing. Companies like Attentive are way ahead of the game.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: