Let's first separate fundamentals from incidental complexity. You have to have:
A server that responds to HTTP requests and provides all data to the browser. Someone else might run the server in a way that you don't have to worry about it, but that's always been true of the web. Remember ~/public_html/?
At least a minimal HTML file to have a DOM to manipulate.
Adequate performance that someone will endure the page.
A workflow that doesn't waste your time in large amounts of drudgery or expose you to errors of carelessness.
Beyond that, it depends heavily on what you are trying to accomplish. There are a lot of projects where writing HTML and CSS by hand is the simplest, most effective path. There are projects where building a system like React to handle multiple teams all putting stuff into the page makes sense, which is why Facebook built it. Part of a the maturation of the platform is a diversification of what it is used for. In the early days of computers, they were for calculation of ballistics and other numerical problems. As the field matured that has blossomed into the range we have today, and the tools have blossomed with it. We don't turn to MATLAB/Simulink to build Myst. We don't turn to HyperCard to model combustion. We don't write first person shooters in Perl and we don't rename a bunch of files according to some pattern in C++.
A few particulars:
However, these [static site generator] abstractions pulls us farther from being able to just view source, which, as Kyle Simpson rightly put, could be a downfall to the web as it would make it harder for new developers to get in.
Not really. Static site generators produce HTML like anything else. We used various forms of them back in the 1990's. View source flourished. JavaScript is the real worry here.
Work with the data in the server at runtime, but... bad performance (and high costs / maintenance)
Generate the website on build time, but... abstractions (and lock-in, might not be very future proof, etc.)
I think you may be overstating both of these. Any website that persists state changes to the server has to generate a view of the data in the server at runtime. You can generate it as a JSON blob and send it to the browser or as HTML directly and send it to the browser. You're still going to generate some text and send it. Bad performance here is a red herring. Yes, you can write an HTTP endpoint that takes tens of seconds to respond. You can also write one that will respond in a time negligible compared to the network latency. Likewise, abstractions? Future-proof? Lock-in? Look at all the JavaScript stuff you're talking about in your list.
And, honestly, the idea of just building .html, .css and (very few) .js files doesn't feel like a productive workflow.
I can say from experience that for many projects it is a very productive workflow, especially with web components to replace server side includes or other simple templating system. If your project's purpose it convey information, not to let someone edit state on remote machines, this is a great workflow for a dozen or fewer pages.
The conversation you want to have really needs to begin with what you are working on.
And perhaps the heavy JavaScript path isn't even the right direction. Go look at Seaside for a completely different, very productive approach to web development.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Let's first separate fundamentals from incidental complexity. You have to have:
~/public_html/?Beyond that, it depends heavily on what you are trying to accomplish. There are a lot of projects where writing HTML and CSS by hand is the simplest, most effective path. There are projects where building a system like React to handle multiple teams all putting stuff into the page makes sense, which is why Facebook built it. Part of a the maturation of the platform is a diversification of what it is used for. In the early days of computers, they were for calculation of ballistics and other numerical problems. As the field matured that has blossomed into the range we have today, and the tools have blossomed with it. We don't turn to MATLAB/Simulink to build Myst. We don't turn to HyperCard to model combustion. We don't write first person shooters in Perl and we don't rename a bunch of files according to some pattern in C++.
A few particulars:
Not really. Static site generators produce HTML like anything else. We used various forms of them back in the 1990's. View source flourished. JavaScript is the real worry here.
I think you may be overstating both of these. Any website that persists state changes to the server has to generate a view of the data in the server at runtime. You can generate it as a JSON blob and send it to the browser or as HTML directly and send it to the browser. You're still going to generate some text and send it. Bad performance here is a red herring. Yes, you can write an HTTP endpoint that takes tens of seconds to respond. You can also write one that will respond in a time negligible compared to the network latency. Likewise, abstractions? Future-proof? Lock-in? Look at all the JavaScript stuff you're talking about in your list.
I can say from experience that for many projects it is a very productive workflow, especially with web components to replace server side includes or other simple templating system. If your project's purpose it convey information, not to let someone edit state on remote machines, this is a great workflow for a dozen or fewer pages.
The conversation you want to have really needs to begin with what you are working on.
And perhaps the heavy JavaScript path isn't even the right direction. Go look at Seaside for a completely different, very productive approach to web development.