3) Run $docker container (ghost, wordpress...). I typically use one docker-compose file for each domain. "expose" is not necessary because the requests are proxied by traefik.
Here's a docker-compose sample for a website available under my-website.com:
Completely agree with the ease of this setup as it's been my goto for roughly a year.
Put Docker on your VM / instance, make a project with a docker-compose that just ties one or many services together with traefik as the reverse proxy (I use CNAMEs or subdomain routing - path routing & stripping adds complexity and breaks many apps).
For the actual site you can choose any stack you desire. I'd recommend node / express over wordpress for a simple site, but you can rock a flavor of the month, or whatever your experience allows you to be productive in - Swift Vapor, go, php, .NET... then dockerize your site.
Deploys and execution should be identical locally and remotely. If you get popular, you are in a great place to scale out compared to many traditional stacks. If you want to try out another service, tool, database, whatever; just add it to the docker-compose, run docker-compose down/up, and there she is.
There is a sharp initial learning curve with Docker - images, containers and their layers, volumes, networks and ports, and how all that interacts with the host machine. Containerization is arguable something you won't be able to ignore forever. The advantages are just too numerous and appealing, especially for the hero solo developer!
WOW. You have no idea how much it makes he happy and encouraged to see that NFS is still making it. They were my first webhost, for price alone, and then overtime became my default because of the support.
Eventually moved on when my needs evolved and sort of...forgot about them until this comment.
I've been with them for about 10 years now. They've increased pricing and decreased support at the same time. They have introduced (probably 8 years ago) a static site option which is considerably cheaper.
But moving my static sites to S3 would be considerably cheaper.
Unfortunately, they discontinued the static site option 2(?) years ago. Now all sites are dynamic, but my static site costs have barely gone up, so its all good.
I too have mostly moved on, but I still have a couple clients that use them and I maintain an adjunct account and register my domains through them.
They provide an excellent service, especially for someone like the person asking this question.
I love NFSN. To me, it feels like a step up from conventional shared hosting, while not going as far as to be a VPS. Despite the price increase, I'm still a happy, longtime customer.
Without knowing your OS: a text editor of some sort and an FTP/SFTP client.
Then just get shared web hosting account - there are lots to chose from and they are super cheap these days. You can go a long way with that without having to mess around with maintaining your own server (unless you want to - I do :)
> a text editor of some sort and an FTP/SFTP client.
I very much agree in the sense of start simple, and grow. My progression was plain html, html plus php for header and footer, text file based CMS, finally a db-backed CMS that does everything I want how I want it. But that was also starting with knowing next to nothing, and to do it differently (more "efficiently") from the get go, I would have needed to just accept advice to use X, without really understanding what it does for me. I was a bit stubborn and not just suffering from NIH syndrome, I was in the cult of NIH. But I learned, it was fun, and I am glad how it worked out.
One person with a simple text editor isn’t going to be nearly as productive as someone who chooses a modern stack with better tools.
I left open my prior tools, etc so as not to bias the answers. I’ve done lots of Java, Python, Swift, some Go, etc but I’m willing to learn anything, so forget that you know that.
No, it really is that simple, if you are taking about a “website”, not a “web application” or some sort of “platform”. Learn to do it by hand or you will forever be dependent on tools. VSCode or Atom is what everyone seems to be using but the more you are able to treat it as a text editor the better you will be.
But since you say you are comfortable with programming, then a static site generator might be interesting for you. Pick one in whatever language you prefer. Be prepared to spend a lot of time before you are as productive as writing it by hand.
I have Atom, VSCode, Sublime, JetBrains, ... I know vi and Emacs. I’ve programmed websites in Perl, Python, Java, Go, ... I didn’t realize we differentiate between applications and sites these days.
In 2019, I’m one person who is willing to start with a clean slate. What current tools should I choose so, as one person, I’m most productive 6 months from now, once I’ve mastered the new tools.
It's not really a sensible question IMO. It's like what's the best car - I say 1980s Countach ... then you say, but I can't fit my luggage in, so I say a Landrover Disco', and you say it doesn't fit in my garage, so I say a Porsche Cayenne and you say it's too expensive, ...
The best stack depends entirely on what you want to do with it, and yes web apps and web sites need different things (I'd say the former are computational, the latter are presentational).
Background: I've been doing solo web dev (but never full-time professionally and mostly casually) since last millennium.
The platform is HTML and CSS. If you want to be above average, use the most modern HTML5 semantic tags. Use grid and flexbox in CSS. Use media queries for responsive design.
The language and the compiler is in the browser. The source code is HTML/CSS. Use VSCode, Atom, Sublime or even Dreamweaver to write that code.
> I didn’t realize we differentiate between applications and sites these days.
I differentiate far more than that. Just as you wouldn't make the same tool choices for a throwaway, ten line script, a command line tool with five subcommands, and a full word processor, you can't expect to do the same for a website.
If what you need to do is put fixed web pages online, then a text editor and an SFTP client is exactly it. Write your HTML and CSS by hand and get on with life. It still works beautifully.
Just past that point is the uncomfortable place where you want to do some templating. And this is where it seems so simple just to hack together a quick script to do what you want that there are a million static site generators, and it's questionable if it's easier to write your own or learn how someone else has organized one. This is a place where no one has gotten it obviously right yet. I still use Hakyll because I got it working a while back and haven't been motivated to change. I've looked at Hugo and Jekyll. I've experimented a bit with writing my own. It's just not worth the effort.
At this point in time, the two things I think would be worth investigating in this space would be either precompiling web components to static HTML so you can use an existing standard that scales to web apps or going into something like Smalltalk and defining objects with content and metadata as objects in a live system then having the code generate output directly.
You're looking for buzzwords when the parent is trying to give you a stack that has worked worked for decades. You bringing up the "Beating the Averages" post isn't relevant.
“Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you're starting a startup, you feel this very keenly.”
I’m not exactly sure why what I’m asking is not clear.
One person with great tools can accomplish a lot more than a small team with average tools. Wasn’t that the reason Ruby was a much better choice than Java/JSP a decade ago? I was never allowed to chose Ruby, for example, because my company required Java.
Today, there are even more options and it’s not clear where to begin the evaluation.
You seem to be asking for a single clear answer. Okay, here's one: node.js. Learn it. Live it. Love it. Use VS Code. Learn it. Live it. Love it. Is this the best combination? Many seem to use it (it's the current hotness that all the hipsters are using) so it must be good. If that's not a satisfactory answer, ask yourself why it isn't. As for the "software written faster and better will ... put its competitors out of business" quote, take a look at Microsoft. They were never the first to market, and often times, it took them three or more attempts to get something correct. Yet they're still a juggernaut of a company. Being first doesn't mean you'll win---just as often you'll end up with arrows in your back.
It really depends upon what you want to do. My own website [1] is written in XML and I use XSLT to convert it to HTML [2]. My blog [3] uses a mixture of C and Lua [4] because that's what works for me. A great craftsman can make wonderful items with average tools that an average craftsman with great tools cannot. It's not just the tools, but how well you understand them and what their limitations are [5]. Also, the industry changes. Hell, javascript didn't even exist when I started making websites. Nor did Java. I got taught CS 101 in Fortran of all languages. The only constant is change, so stop asking what's best, and just start working. You'll find out what works for you and what doesn't.
[2] I wanted an easier way to maintain the links among all the pages (next section, previous section, next page, previous page, etc.) instead of modifying static files. XSLT was the new hotness at the time. I won't say it was a mistake, but I haven't bothered changing the underlying technology since.
[5] I know of a bridge player (a card game) who took the time to learn x86 assembly language to write his own bridge playing software, and from my understanding, at the time it was a "best of breed" type program. Could he have been more productive in another language? Perhaps. Perhaps not.
WordPress. It’s profoundly unsexy. It’s also solid.
Do you want to fuck around with building another CMS that nobody but you will use, and which you will probably only use for about three posts before throwing it out and making another CMS built on today’s hot tools? Or do you want a website that you can get to be reasonably pretty without much work, and which you can update from multiple devices?
Seriously I spent a while setting up WP a decade ago and it’s been where I post everything I make. I don’t have to futz with it unless I want to make a cool new theme for a new comics project, it just sits there updating itself for me and waiting for me to feel like writing a new post or whatever.
(Okay I do need to spend some time futzing with it soon, the latest WP update won’t run on the decade-old version of PHP I set it up with, and something in it breaks when I try to switch which version my shared host is using. That’s once in like a decade.)
I'm building a simple blog/project site just using Hugo. It's quite easy to get started, and is a single binary you can use to test and deploy the site with no dependencies.
I like that I'm able to design everything from the ground-up the way I want it. Also a decent selection of themes if you wanted to focus on content.
The question is, what do you know now? If you're starting from scratch, you should learn HTML and CSS. As for tools, again it depends on what you already know. If you know a given programming language, you can usually find a static site generator that you can build from.
There are lots of templates free, or for purchase you can use, cut up and deploy. It really all depends.
Many just dip into wordpress, which for good or bad is pretty much the king of CMS. Others Drupal or similar.
You can use tools like Hugo to generate static sites. Basically such tools gives you power to avoid duplication of reusable components on the page, as well as to generate static lists automatically like related pages/recommendations. See this discussion on such tools: https://news.ycombinator.com/item?id=16472395
Not static, but easy to backup (plain text instead of database), many plugins, article versioning, easy editing (even on the mobile phone), a servicable, if unexciting, design that's mobile friendly.
If you want to be productive, and "productive" does not mean building web software (which is fine!), worry less about the software and write more.
Netlify and a static site generator of your choice, preferably one that uses a language you’re already familiar with. I use Middleman for example, but there‘s also the much more popular Jekyll in Ruby-land.
It’s nice but only supports static content, so personally I would not count that as “running my own website”. Web hosting even container based VPS is super cheap - I would just go for that and have the extra freedom to do interesting things.
Simply because it is very limiting. Running your own site, even on cheap shared hosting, opens up lots of exciting possibilities. With a bit of PHP and SQLite you can build lots of cool stuff (just like before WordPress came and made everything boring).
For simple sites, static is great, but if it becomes more complex (even just lots of pages sort of complex) then some sort of templating, even just through basic PHP includes, becomes very helpful to keep it maintainable. Example: I help look after a site with 3K static HTML pages and it is impossible to make any global changes without literally months of manual work. :(
For my own site I use a static site generator, which is another great option, but that comes with a much steeper learning curve unfortunately.
Seems like a limited/narrow definition of maintaining a website, just because there are different options of platforms and tools used to put content in the user's browser. Ultimately, for the browser, the result is the same, no?
Edit:
Following your edit, I can see an argument being made that maintaining static sites coming with a different workflow than maintaining a CMS and why some may not prefer it --personally, the mutability of the workflow for many of these stacks is the appeal of SSGs for me (especially, more recently 11ty[1] which I'm thinking of porting my personal site to).
My advice is based on my own experience, so obviously I think it is true.
It is my job to know a LOT about putting content in users browsers (from TCP protocol level up to the HTML) but I still think that GitHub pages is too limited for anything but very simple site.
It’s cool to have a static site - it’s not cool to be forced to only have a static site.
I still think that GitHub pages is too limited for anything but very simple site
Oh we wont disagree there, it absolutely has its limitations.
You had originally stated you don't consider these types of stacks to be "running my own site" and I was just wondering what the distinction was, not to necessarily call into question or invalidate your own experiences-if I gave that impression, it's on me to communicate myself a bit better next time.
I'm enjoying Netlify as a intermediate step: mostly static site, plus their Forms and Functions to add small interactive parts. I'm not sure it's easier for a beginner, though.
I’d be willing to learn something new if I knew in 2 years, I’d be extremely productive.