You can host a website on a home system, if you like. There is a caveat, though. Some Internet Service Providers (ISPs) don't allow their customers to host their own servers, while others will allow you to do so. An ISP that doesn't allow home users to host their own servers may block traffic on the ports commonly used by servers. E.g., it can stop someone from running his own mail server by blocking connections from the Internet to port 25 on the IP addresses it assigns to home users. Likewise it could stop someone from hosting her own web server by blocking the default port used for HTTP, port 80, and the default port used for HTTPS, port 443. Someone might be able to circumvent such a block by running a web server on a nonstandard port. E.g., if the web server was configured to listen for HTTP connections on port 7080, if you could provide that port number to everyone who might visit your site, they could still get access to the server. E.g., instead of using http://www.example.com/sompage.html or http://10.0.0.5/somepage.html, visitors to the web site could use http://www.example.com:7080/somepage.html or http://10.0.0.5/sompage.html. Though even that traffic could be blocked by an ISP.
That solution might work, if you expect your website to be visited by just a few friends, but might be more problematical if you hope to have a worldwide Internet audience for your site, since most people are not accustomed to including a port number when visiting a site. Though, if you are linking to your site from other sites, as long as the port number is included the link would work.
But, supposing the ISP doesn't prevent you from hosting your own web server. You will need to configure your router to forward traffic destined for the default HTTP port, and possibly HTTPS, if you will be using that protocol as well, to the internal private IP address of the web server on your Local Area Network (LAN). This is necessary because most home users have a router performing Network Address Translation for communications between systems behind the router on the LAN side and systems on the "outside", Internet-facing side, of the router, i.e., the Wide Area Network (WAN). I.e., they have one external public IP address for the router, but there may be multiple private IP addresses for systems behind the router. E.g., you might have a laptop with an address of 192.168.0.4 and a desktop system with an IP address of 192.168.0.5 behind the router. Those private IP addresses are not routed over the Internet. A home router will typically perform NAT to allow external systems that see only the one public IP address to communicate with systems behind a router with private IP addresses.
Most home routers provide the capability to perform network address and port address translation and it is usually fairly easy to set up, you just need to know that you have to do that. Some routers may have a demilitarized zone (DMZ) setting that allows you to specify that any connections that originate from outside the router go to a particular system on the inside of the router. If you want your home server to be accessible via NAT/PAT, you will likely need to assign it a static IP address rather than one that may change because it is assigned via the Dynamic Host Configuration Protocol (DHCP), so the router can always route incoming connections to the right system.
In addition to the IP address of systems on the internal side of your router possibly changing, if you are using a home network connection, your ISP likely assigns the external IP address of the router via DHCP as well. Let's say it is xxx.xxx.10.250. Tomorrow it may be xxx.xxx.10.251. It depends upon the "lease time" the ISP uses for assigning IP addresses via DHCP to its customers. The lease time could be a few hours, a few days, a month, etc. So, if you tell people your web server is accessible at xxx.xxx.10.250, whenever it changes you will need to tell them the new address. Though, for some systems, even though your ISP may not provide you with a static IP address, but instead provide a dynamic one, it may stay the same as long as you don't replace the router. E.g., for my home Internet service, I don't have a static IP address, but the only time it has ever changed over the course of many years is when I replaced the router, so the ISP's equipment then saw a different Media Access Control address from a new router.
Even if your IP address changes frequently, you may be able to purchase a static IP address from the ISP. Some will sell a static IP address to home users for a monthly fee, while many will not.
But a solution I use when I need to be able to connect to a home user's system externally for troubleshooting or to set up a home-based server is to use Dynamic Domain Name System. That allows you to access a home-based server using a fully qualified domain name (FQDN), e.g. martijn.example.com, even if the external IP address of the router varies. I use No-IP.com, but there are other DDNS services, as well. The way DDNS works is that you install software on a system on the internal , LAN side, of the router that periodically communicates with a DDNS service-provider system, so that the DDNS provider knows the current external IP address from which the system is communicating. The DDNS provider then updates its Domain Name System (DNS) servers, which are the servers that translate FQDNs, such as martijn.example.com, to IP addresses, to reflect the current external IP address for your router. So anyone putting martijn.example.com in her browser will be directed to the correct IP address. Some routers have a configuration option that allows you to specify a DDNS service-provider, so you may not even need to install any software on a home system for it to work; you would just need to have an account with a DDNS provider.
DDNS providers will charge you a fee to use your own domain name, e.g. martijn.com, if you wished to purchase your own domain name. But you may even be able to use a DDNS service for free, e.g., No-IP provides a free service, if you are willing to use a domain name provided by the DDNS provider. E.g., if the provider owns example.com, you may be able to use martijn.example.com for free, though you would have to pay for martijn.com. I.e., you can specify a particular host name, e.g., martijn, to use with one of their domain names.
I've used such a configuration for a home-based website for many years. If you have a fairly reliable Internet connection and your ISP doesn't block access to home-based servers, it can actually work fairly well for low traffic sites. E.g., if you don't expect to have more than a few hundred visitors to your site every day and aren't already saturating your available bandwidth. But there are considerations you need to know about, i.e., the ones I mentioned above, when setting up a home-based server which may lead some to recommend using a hosting service.
Though such a configuration can even be used for a small or home-based business, I would not recommend it for a small or home-based business if access to your website is critical, if your external IP address can change frequently, since when someone visits your site their system will cache your IP address so that the next time they visit the site the system doesn't have to look up the IP address that goes with the name again. There is a time to live (TTL) value for such cached DNS entries, so they will expire and the system will look up the IP address again, but they may stay on a system for many minutes or even hours. And other DNS servers also cache entries, also. E.g., suppose Mary is a Comcast customer whose system connects to martijn.example.com. Her system may query the Comcast DNS servers to get the IP address for the website. So now the Comcast servers know the IP address that goes with the FQDN. Another Comcast customer, Bill, also wants to visit your site. He has never visited your site before, so his system hasn't cached the translation between martijn.example.com and its IP address, but when his system queries a Comcast DNS server, if that server already knows the address that is associated with the FQDN, it will provide the answer from its cache.
So, if your IP address changes, even though your server or your router may within a minute update the DDNS provider's DNS servers, others may still get the old IP address and so your website is inaccessible to them until their system or their ISP's DNS servers gets the new, current IP address. Due to caching and depending on the TTL setting, it is possible some systems might still try to connect to the old IP address many hours later or maybe even the next day. That may not be a serious problem if you just want to make your website accessible to family and friends, but if you are running a business, that is likely an unacceptable problem.
Update to address comment:
when you purchase a domain name from a domain name registrar, you often have the option to specify an IP address or addresses for systems that should be accessible via the domain name at those addresses or you can temporarily "park" the name, so it points to systems belonging to the registrar. When you are ready to specify your own IP address, registrars typically offer DNS services that allow you to modify the IP addresses associated with domain names whenever you like. Many also allow you, through their DNS service to adjust the TTL value, i.e., the amount of time that a system should cache the IP address that goes with a FQDN. So, if you thought you might need to change the IP address frequently, you would specify a shorter TTL. The registrar might have a minimum TTL you can specify, e.g., 5 minutes or 30 minutes. The value is usually specified in seconds, so a TTL of 5 minutes would appear as 300.
So, if you are using the registrar's DNS service, you will need to log into your account with the registrar and change the IP address or addresses associated with your domain name manually each time there is a a change. Or, alternatively, you could use a DDNS service provider so that the change in translation from FQDN to IP address happens automatically. You could either purchase the domain name through the DDNS service provider and so use their DNS servers by default or purchase the domain name from another registrar and specify the IP addresses for the DDNS provider's name servers through the configuration page for your website provided by the domain name registrar
Another option would be to run your own DNS server. When your purchase a domain name, you can specify the name servers that should be used with it, either the registrar's name servers or some other name servers. E.g., you could have the same system that is a web server be a DNS server. You would have to ensure that server would be accessible on port 53, which is the default port for DNS, for the UDP and TCP IP protocols. You could then create a script/program on your server that periodically checks to see what external IP address is assigned to your router and update the zone file for your domain name on your DNS server. Setting up a DNS server is a lot more complicated than relying on a DDNS provider, though. You can find tutorials for setting up a DNS server online, if you wished to pursue that more complicated route. BIND is commonly used for DNS service on Linux systems. Microsoft's server versions of Windows, e.g., Windows Server 2012 have a Microsoft-provided DNS service that can be used, as well. I'd suggest starting with a registrar's DNS service, which is typically free when you've purchased a domain name from the registrar, though, even if you thought you might want to embark on that more difficult path of running your own DNS server. Unless someone wants to learn how the underpinnings of the Internet, such as DNS servers work, sticking with a registrar or DDNS service provider's DNS servers is likely the best course for most people. You can also get DNS service through companies that specialize in DNS services, such as OpenDNS.
Keep in mind, though, that even if you specify a short TTL value and have automatic updates, there is a possibility for a greater delay than the TTL between the time you get a new IP address and the time all systems on the Internet stop using the old IP address and use the new one. E.g., see the GoDaddy article, What Factors Affect DNS Propagation Time? (GoDaddy is a domain name registrar), which explains why it could possibly take up to 48 hours before the new address is available to all systems on the Internet. E.g., the article states "Some ISPs ignore TTL settings and only update their cached records every two to three days."
