Hacker News new | past | comments | ask | show | jobs | submit login

The complexity of modern sites is insane. It's also insane to relay on other peoples services ('cloud' and 'server-less') for simple websites, like publishing articles or blog-posts. Those services could be gone tomorrow!

A lot of users may also chose to disable JavaScript in the future, as more and more malicious actors use JavaScript to exploit people (the latest trend is to hack sites and js- libraries to make other people mine crypto-currency).

I believe the answer to many of todays challenges is to move on to static sites, and to make most sites work without JavaScript. You only need JavaScript if you make a site that is basically an application. A blog or a newspaper is not an application.

For a blogger, another feature with static sites is that they don't require a specific back-end (like wordpres or drupal). As a static site, their thoughts and ideas can live on for millenniums, long after the last wordpress or drupal instances has shut down.

Disclosure: I'm not un-biased here. I'm actually so biased that I wrote my own static site generator last year to make it simple to publish blogs that works great on both mobile devices and PC's.




>You only need JavaScript if you make a site that is basically an application.

You may not even need that. As part of the process of learning Nim, I've been making a package repository that's designed to accept artifacts from a CI system, store them, and allow searching by a variety of different package metadata, including a web interface to manage all your artifacts. Not a complex webapp, but also not a trivial one.

Anywho, I decided to set myself the challenge of using no javascript anywhere on the site. It's really not been much of a problem. The UX is different, which means the application UX design is different. But it isn't worse.

The only thing I've run into and been unable to solve without javascript is that when you use the file picker to manually select a file on your computer for upload (rather than using the API), I can't update the page to show you which file you picked.

Based on my experience, javascript is like a fine spice. A little bit of it added to your page in just the right amount can make an average web experience fantastic. Taking the cap off the JS shaker and just pouring it in is almost certainly going to make the experience far worse.


Those services could be gone tomorrow!

This is true of any hosting service. Unless it's your machine in your rack in your building attached to your pipe, there's a company that could suddenly shut down tomorrow and leave you in the lurch.

I believe the answer to many of todays challenges is to move on to static sites, and to make most sites work without JavaScript

The second part I agree with. The first part... meh. I've built a lot of database-backed websites, and have been doing so since the days when people used the term "DHTML" to refer to using JavaScript in a web page. The patterns for doing it are well-understood, the tools for doing it are solid, and for anything bigger than a brochureware site I'll basically always turn to a database (and even for the brochureware, I'll usually do it, since I don't want to train non-technical people on how to edit files and run a static generator).


>> Those services could be gone tomorrow!

> This is true of any hosting service.

It's a lot easier to just 'scp ~/blog/. new-server:/var/www' than to set up a database server, go trough configuration and hardening of apache and php (or whatever) and make everything play together, again. Some of my sites have been down for 6 months now, because I never found the time to do that.

> since I don't want to train non-technical people on how to edit files and run a static generator

Some friends of mine and I are planning a hosted service for this, where users can push sites trough git, scp, ftp or interactively maintain the site trough a panel (using JavaScript) - and download the entire site at any time as a zipfile (or git clone). The sites will be static, but there will be (optional) comments, using a 3rd party service.


It's a lot easier to just 'scp ~/blog/. new-server:/var/www' than to set up a database server, go trough configuration and hardening of apache and php (or whatever) and make everything play together, again.

Well, you need to do some configuration and hardening no matter what. And while I don't use PHP anymore, I've found that for what I do the deployment story these days is easy enough.

Some friends of mine and I are planning a hosted service for this, where users can push sites trough git, scp, ftp or interactively maintain the site trough a panel (using JavaScript) - and download the entire site at any time as a zipfile (or git clone). The sites will be static, but there will be (optional) comments, using a 3rd party service.

So after suggesting people don't trust third-party services, you're going to start and advertise your own, and integrate someone else's service into it? :)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: