There are a lot of differences. A Wordpress sites html is generally rendered serverside, by php code with access to plugins and a database. Wordpress can do things like post forms, run surveys, you can pretty much implement any web app you care to with Wordpress and plugins. It's a very mature platform.
Neocities sites are static HTML, meaning once your files are uploaded,they don't change. Neocities doesn't do POST, there is no database backend or code running on the server.
Now in 2017, CORS allows client side apps to do just about anything traditional web apps have done, without page tranistions, given an appropriate backend. The difference is that html rendered by javascript on the client typically isn't indexed by search engines, while html served from a domain are. That's one significant difference, there are others.
Thanks. that helps a lot, though I don't quite get "CORS allows client side apps to do just about anything traditional web apps have done, without page tranistions, given an appropriate backend", thought CORS is just a secure measure.
Browsers implement what they call the "same-origin policy" as a cross-site scripting prevention measure. This prevents you from using XMLHttpRequest calls on other hostnames/ports, which effectively means if you're making a static website on a host with no API endpoints, your website can't interact with any backend services. As a result, you can't save or load data from a server-side database or do a lot of other operations that traditional web applications can do.
There's pre-CORS workarounds. You could build an HTML multipart/form-data POST form inside an iframe and submit it with JavaScript for example. And if the server API supports JSONP, you can inject a script tag into your page that loads the target content as a script which then executes the data in a callback to read it back into the client page.
If you don't care about REST, and you only need to do GET/POST requests with a limited set of mime types, you could make a client-side application that gets around the same-origin policy without using CORS. But it's ugly.
With CORS though, you can potentially make any type of request across origins, because the CORS preflight OPTION requests allow a server to specify what request methods and what headers a client from a certain origin can access at a given URI. And these days, you can find CORS-enabled third-party REST APIs that you can use with things like client-side OAuth to provide all the same functionality that you would have in a traditional web applications.
I've been thinking about using a completely split API/client-side app architecture in my own projects lately, because scaling a bare API is much easier and cheaper than scaling a web application.
So yes, CORS is just a security measure, but it gives you more functionality in a client-side application by allowing you to bypass an older security measure, the same-origin policy, in a very clean and explicit way.
It is a security measure. Suppose you have a marketing site for a client. You'd like users to be able to fill out and submit a contact form. A host like neocities can display the html with the form to users, but neocites won't let you POST the form and do anything with the data. So, CORS allows your page on neocities to POST data to another domain (ie www.othersite.com). The javascript on the page would do something "event.prefentDefault()" to keep the user on the page, doing the form submission via ajax. Then the server at www.othersite.com can do stuff with the data.
There are third party services that provide form processing of this nature, and even complete database backends and user management APIs (I built one).
Neocities sites are static HTML, meaning once your files are uploaded,they don't change. Neocities doesn't do POST, there is no database backend or code running on the server.
Now in 2017, CORS allows client side apps to do just about anything traditional web apps have done, without page tranistions, given an appropriate backend. The difference is that html rendered by javascript on the client typically isn't indexed by search engines, while html served from a domain are. That's one significant difference, there are others.