Most people's expectations of what a "basic website" should do have gone way up over time.
Even as a programmer, I've fallen into the static site generator trap a few times.
It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.
Nowadays, if I want a static site I just start with a folder of html files.
It's way less complicated and quicker to go from idea -> execution without bike-shedding or procrastination on tools.
I'm pretty happy writing html and css manually though—I don't recommend it for everyone.
The other cool thing is if I then decide to "abort" to rails.. I can copy the folder of html files into the rails public/ folder.. pretty easy upgrade path.
Maybe you just haven't found the right static site generator for your needs?
Jekyll is the most well known in Ruby space, but it's tailored to a specific niche - authoring a blog with Markdown or another lightweight markup language. You can certainly massage it into doing other things, but it's not that ergonomic as a general purpose static site generator.
If you want something that's easy to copy/paste into rails, a rack based static site generator like middleman is great because you can start writing with erb/haml and ActiveSupport from the very beginning.
If you're looking for the simplicity of handwriting HTML and CSS but you want some niceties like includes, partial templates, link helpers, nanoc is a good static site generator that's progressive. Start with plain HTML/CSS, only add additional features as you need them.
> Even as a programmer, I've fallen into the static site generator trap a few times.
> It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.
Hard to discuss without examples. I started using Pelican over a decade ago, and am still happy with it. Every once in a while I write code to customize the behavior, but it's once every few years. It's simple and just works.
There are things I miss from dynamic sites, but I don't see how a simple folder of HTML files is in any way superior to Pelican...
I've been posting to my personal website for 20+ years and it's been something like: basic HTML -> Drupal (whew) -> Wordpress -> basic HTML (via Jekyll).
The fundamental rule I've set myself against feature-bloating in my website is defining what I want it to be: an archive of things I've done. As an archive, I want it to be very durable in time. Thus, static file that are dead-easy to copy around, mirror and make it work in any hosting platform.
It did take me a while to nail having a bilingual site, though :) but at least it's a price I paid once.
For blogging I use Hugo because it is just easier to focus on content, not on style. That is why I don't like writing pure html files. Changing style can also be a problem, if something is hardcoded into html file.
For more advanced tasks I write in django, because it so easy for me to add features.
> Nowadays, if I want a static site I just start with a folder of html files.
Same here. I've considered adding a .md —> .html step for content, but just haven't found it necessary — yet.
> The other cool thing...
I like being able to—easily—view my site via a local sever. The best case would be one that I can view via file:// too, but I couldn't quite crack the organisation and ended up with a 'make local' step that generates a separate copy for file-based viewing.
I run a blog for an organization. We do one post per business day on average, with typically around 3 posters. I set it up years ago with Django/Wagtail/Puput and it has happily chugged along ever since. I can’t imagine how annoying it would be to manage if people were creating their own new files for every post and writing their own HTML…
But you've had to maintain that Python/Django stack, as well as a server.. Right?! I've done hundreds of Django release upgrades. They're not automatic or time-free.
Most SSGs, especially those geared to blogging accept nicer markup systems like Markdown. Keeping track of things, even in a multi-user system isn't hard.
Getting non-technical people used to a git workflow is the hardest part.
Yes, it depends on the target audience. For a personal website which the article was about, it would probably be fine for most hacker news users. If someone can’t manage to send me a mail, they probably wouldn’t see my website anyways. If you do your grandparents personal website, a proper form with a backend is better though.
How are you handling commonality between pages with plain html pages? As long as you don’t use iframes, you have to manually sync everything that’s shared or almost the same on alle pages (header, footer, navigation). That’s pretty annoying.
> Nowadays, if I want a static site I just start with a folder of html files.
? With that argument, we can also calculate 10 million digits of pi in HTMl by renaming our C files to .html. If someone tells me they’re using a collection of html files, I’m assuming they mean static html pages without server side scripting.
Yeah nah, for me it's exactly that: plain html/js/css files. For simple things, I copy/paste.. not a big deal.
If it's getting more complicated, I'll abort and upgrade to rails to use layouts etc.
The middle ground of static site generators are a trap in my personal opinion.
If I need to add a feature, I've found it's easier for me to implement it directly rather than try mess around configuring a static site generator with plugins etc.
Amusing how underneath this comment, there are several comments saying "ah, you just haven't found the right SSG, this one is good". Well-intentioned, but completely missing the point.
I'm not sure if it's helpful, but if you want some perspective from someone that's interviewed a few hundred software engineering candidates..
I ask this question to every candidate I interview. My expectations for this question are very low.
I find it's a very effective screener for low effort applications. A lot of candidates I interview haven't even looked at our company website.
If you're the kind of person that's doing zero preparation for a job interview, I've already learned something about you.
Many people I interview just answer the question very directly:
- "I got laid off"
- "My current company is returning to office and I want to work from home".
- "I've been working at X for 5 years now and I'm bored"
- "I want to make more money"
- "I want to work with an international team"
.. honestly, that's all totally fine.
I agree that there's no need to pretend about your motivations—I'm not expecting a lot of enthusiasm about writing boring business software at my company.
On the other hand, if you've done some basic research about the company or the role and can ask some good questions—I'm learning something about your intelligence, conscientiousness and self-awareness, which are actually the things I'm testing for.
Job interviews are full of latent variables like this. As an interviewer I want to find out if you're good at X, but I can't just ask "are you good at X?". I need to test you out by asking other questions that demonstrate X.
It sounds like you want the candidates to answer a different question than the one you asked. You want them to demonstrate knowledge of the company, but instead you ask them to muster up something enthusiastic to say about working for a company which they can only have superficial knowledge of - not having ever worked there before.
- Working from home for long stretches.. feels more like "living at work" for me. Hybrid is good. Some boundaries in my life are healthy.
- Most people hate their commute. I ride my bike to work and it's the best bit of my day.
- I'm in a three person startup.. a ton of the software engineering and business problems I work on get hashed out talking over lunch and coffee—or in 2 minute hallway chats.
Influx provides customer support teams that can flex and scale monthly. Influx enables companies to deliver consistent and high quality service 24/7.
We're looking for an experienced engineering leader to build out a new team. Our stack uses Ruby on Rails and Postgres with infrastructure hosted on Heroku and AWS.
The Influx engineering team is small but growing. There will be enormous opportunities for learning, personal growth and taking on more responsibility as the team continues to expand.
What we’re looking for:
- Someone that is curious, collaborative and ready to take ownership and responsibility.
- Comfortable being part of a small, autonomous and distributed team.
- Top-notch communication skills are essential.
- Eager to learn and grow.
Email me at dennis@influx.com to apply or ask questions. Thanks! :)
Influx provides full-service customer support teams that can flex and scale monthly. Influx enables companies of all sizes to deliver consistent and high quality service 24/7.
We're looking for an experienced Ruby engineer. Our stack uses Ruby on Rails and Postgres with infrastructure hosted on Heroku and AWS.
The Influx engineering team is small but growing. There will be enormous opportunities for learning, personal growth and taking on more responsibility as the team continues to expand.
What we’re looking for:
- Someone that is curious, collaborative and ready to take ownership and responsibility.
- Comfortable being part of a small, autonomous and distributed team.
- Top-notch communication skills are essential.
- Eager to learn and grow.
Email me at dennis@influx.com to apply or ask questions. Thanks! :)
Influx provides full-service customer support teams that can flex and scale monthly. Influx enables companies of all sizes to deliver consistent and high quality service 24/7.
We're looking for an experienced Ruby engineer. This is primarily a back-end role using Ruby on Rails and Postgres with infrastructure hosted on Heroku and AWS.
The Influx engineering team is small but growing. There will be enormous opportunities for learning, personal growth and taking on more responsibility as the team continues to expand.
What we’re looking for:
- Someone that is curious, collaborative and ready to take ownership and responsibility.
- Comfortable being part of a small, autonomous and distributed team.
- Top-notch communication skills are essential.
- Eager to learn and grow.
Email me at dennis@influx.com to apply or ask questions. Thanks! :)
Hi Dennis, while I was on the Influx careers page, I noticed that you have certain Kenyan-based openings. Are you currently considered a Ruby Engineer not in Malaysia/Melbourne.
Influx provides full-service customer support teams that can flex and scale monthly. Influx enables companies of all sizes to deliver consistent and high quality service 24/7.
We're looking for an experienced Ruby engineer. This is primarily a back-end role using Ruby on Rails and Postgres with infrastructure hosted on Heroku and AWS.
The Influx engineering team is small but growing. There will be enormous opportunities for learning, personal growth and taking on more responsibility as the team continues to expand.
What we’re looking for:
- Someone that is curious, collaborative and ready to take ownership and responsibility.
- Comfortable being part of a small, autonomous and distributed team.
- Top-notch communication skills are essential.
- Eager to learn and grow.
Email me at dennis@influx.com to apply or ask questions. Thanks! :)
Even as a programmer, I've fallen into the static site generator trap a few times.
It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.
Nowadays, if I want a static site I just start with a folder of html files. It's way less complicated and quicker to go from idea -> execution without bike-shedding or procrastination on tools.
I'm pretty happy writing html and css manually though—I don't recommend it for everyone.
The other cool thing is if I then decide to "abort" to rails.. I can copy the folder of html files into the rails public/ folder.. pretty easy upgrade path.