My hosting company just gave me notice they are shutting down their US servers. Is there any information about Handmade.network, who hosts it, the tech stack for the web page, and all that stuff?

Im not authoritative, but i'd like to know if I was correct... based on whois and headers, it looks like its nginx server, digital ocean hosting, and using cloudflare for reverse proxy/CDN and DNS as well.


I recommend using AWS or Digital ocean, depending on your needs

Sweet. You sure can tell the difference between a C guy and a Web guy.

I am also curious if you're right...

Hi Timothy,

That is correct. The site's running on nginx, hosted at DigitalOcean, behind CloudFlare. Given that I'm the one who set this up, I know this to be the correct answer. ;-)

I hope that helps.

Out of pure interest, which language did you write the site in?

I was wondering that too. I've been fighting with our internal website all week, trying to figure out the best way to do the client side Javascript with the least amount of libraries. So far I've got:

React for the UI,
Bootstrap for the CSS,
Backbone for REST and routing,
and a few other helper libraries I don't remember.

The server is Jetty with Jersey, using Akka for communication with a HSQLDB for data.

Yuck!

On the server side of things:

ChronalDragon

We built this site on the Python-based Django server

Looks like client side, there really isn't a lot going on, just a little bit of JS for the editor and some misc things, looks handmade to me :)

I like Django myself, their ORM makes it really easy to push new DB schema into production. As far as client side libraries, there really doesn't seem like any clearly winning solution...

As a side note, one fun thing I was thinking about doing was just using webGL, that way you can easily translate desktop ui to browser, and have it guaranteed to layout identically... and then you can transfer all your UI controlling logic via emscripten, but I haven't gotten a chance to mess with that yet...

timothy.wright
I was wondering that too. I've been fighting with our internal website all week, trying to figure out the best way to do the client side Javascript with the least amount of libraries. So far I've got:

React for the UI,
Bootstrap for the CSS,
Backbone for REST and routing,
and a few other helper libraries I don't remember.

The server is Jetty with Jersey, using Akka for communication with a HSQLDB for data.

Yuck!

I've been trying to figure out the best way to do client side JavaScript with the least number of libraries for a long time.

Back when IE 6 was still around I just used jQuery for everything, then we moved onto more full-blown frameworks like Ember, KnockoutJS, Backbone etc. Today at my work place we are using React which is working out ok, but I still maintain that after 10 years straight of fighting with JS, CSS and HTML, the best way is to just write it all from scratch yourself.

I could include thousands of lines in CSS and JS on my pages by using frameworks and libraries like React and Bootstrap, or I could write exactly what I need with 200 lines of CSS and a few dozen lines of JS.

Browsers are much more consistent with each other now, so gone are the days when things like jQuery were needed to iron out browser differences; the differences still exist of course, but it rarely causes a problem now.

The new fetch API for JS takes care of all my REST API requests using promises, and I write the REST API itself with Node, although I'm looking at changing over to Go.

Croepha
On the server side of things:

ChronalDragon

We built this site on the Python-based Django server

Looks like client side, there really isn't a lot going on, just a little bit of JS for the editor and some misc things, looks handmade to me :)

I like Django myself, their ORM makes it really easy to push new DB schema into production. As far as client side libraries, there really doesn't seem like any clearly winning solution...

As a side note, one fun thing I was thinking about doing was just using webGL, that way you can easily translate desktop ui to browser, and have it guaranteed to layout identically... and then you can transfer all your UI controlling logic via emscripten, but I haven't gotten a chance to mess with that yet...

Thanks for pasting in the quote from ChronalDragon. Python is a nice language to write in; I hate the virtual environments though...
Also, your WebGL idea sounds like it would be nice.

As you have probably seen more and more desktop software is being written in things like Electron, meaning we are porting web stuff to the desktop and ending up with things like the Atom editor or VSCode which are both soooooo slow due to running in Chrome with JavaScript.

Would be nice to see more ports from Desktop to Web.

While porting desktop to web sounds nice at first glance, keep in mind that:

1. Not all browsers/platforms run javascript quickly (i.e. know how to JIT asm.js style code, and are able to run it quickly enough to approximate native speed)
2. Not all browsers/platforms support webGL
3. Emscripten-compiled code tends to be *big*, orders of magnitude larger than the equivalent non-emscripten idiomatically-translated JS.

Unfortunate as it is, the "native language" of the web is still <div>s with plain text and javascript. I don't know if there's an easy (<10+ years) way around that without inventing a new platform and getting everyone to transition over (which would also take 10 years or more).