Many sites could be built on the stack espoused by Alex Petros, "The Hundred-Year Web Service", <https://www.youtube.com/watch?v=lASLZ9TgXyc>: SQLite, Express.js, Nunjucks, and HTMX.
But if your app needs islands of interactivity, my library does it in a way that I haven't seen elsewhere.
This is clever advice, to first find out what estimate is tolerable to management and then adapt your design to fit. It's sort of like what the makers of Basecamp, in their book Getting Real, say in chapter 7, "Fix Time and Budget, Flex Scope"<https://basecamp.com/gettingreal/02.4-fix-time-and-budget-fl...>.
I wonder if it was a mistake to ever call it "engineering", because that leads people to think that software engineering is akin to mechanical or civil engineering, where you hire one expensive architect to do the design, and then hand off the grunt work to lower-paid programmers to bang out the code in a repetitive and predictable timeline with no more hard thinking needed. I think that Jack Reeves was right when he said, in 1992, that every line of code is architecture. The grunt work of building it afterward is the job of the compiler and linker. Therefore every time you write code, you are still working on the blueprint. "What is Software Design?"<https://www.bleading-edge.com/Publications/C++Journal/Cpjour...>
Martin Fowler cites this in his 2005 essay about agile programming, "The New Methodology"<https://www.martinfowler.com/articles/newMethodology.html>. Jeff Atwood, also in 2005, explains why software is so different from engineering physical objects, because the laws of physics constrain houses and bridges and aircraft. "Bridges, Software Engineering, and God"<https://blog.codinghorror.com/bridges-software-engineering-a...>. All this explains not only why estimates are so hard but also why two programs can do the same thing but one is a thousand lines of code and one is a million.
I came into programming from a liberal arts background, specifically writing, not science or math. I see a lot of similarities between programming and writing. Both let you say the same thing an infinite number of ways. I think I benefitted more from Strunk and White's advice to "omit needless words" than I might have from a course in how to build city hall.
You should let your child have lots and lots of freedom to do whatever he wants, even if that is often watching television or whatever. Ideally you would have a lot of outdoor places for him to roam --- whether that be a large amount of land that you live on or just a green neighborhood.
This is based on my own experience, because I was allowed to manage my free time. When I got out of school, I had a chore or two, but the rest of the evening was mine to manage. (I was expected to do my homework at some point, though, and make decent grades. In fact I made A's and B's.) But the rest of the time I watched about 2-3 hours of TV, drew a lot, jumped on the trampoline, and in general ran around outside (We lived on five acres).
My parents never sent me to summer camp. The summer was mine. They never made me take piano lessons or join the boy scouts. Nothing.
I graduated magna cum laude, started my own business (which failed) then pivoted to a completely different field (web programming) and taught myself everything, through books, blogs, etc. That was 15 years ago and professionally speaking, I lead a very stable life.
When I hear about today's children being shuttled from school to one extracurricular activity or another, where they have very little unstructured time, I scream on the inside on their behalf. I've known a handful of adults who were homeschooled, and most of them have turned out very poorly. They basically are walking time bombs: quiet and obedient through childhood, then they get out of the house and explode.
As my mother wisely said, "Kids need to be kids." (We had a very strong religious teaching, however, in my household --- firm but not oppressive. I ascribe my own acceptance of that teaching as a key reason I did not just squander all that freedom on drugs, sex, and rock'n'roll. But most of all, I felt very, very loved and accepted as a person, even if I were to screw up royally.)
NoSQL is very much like the databases that were around in the 1960s ("navigational" databases, nested sets of key-value pairs). E. F. Codd proposed a database of tables (which he, a mathematician, called "relations") to solve a number of problems that these primitive databases were having, one of which was speed.
In a few tests I ran, I found rendering to be fast and lightweight. If you already have prepared the associative array of values, then the final stage of combining it with a template and producing HTML doesn't strain the server, and so it doesn't help your server much to move that part to the client.
The server's hardest work is usually in the database: scanning through thousands of rows to find the few that you need, joining them with rows from other tables, perhaps some calculations to aggregate some values (sum, average, count, etc.). The database is often the bottleneck. That isn't to say I advocate NoSQL or some exotic architecture. For many apps, the solution is spending more time on your database (indexes, trying different ways to join things, making sure you're filtering things thoroughly with where-clauses, mundane stuff like that). A lot of seasoned programmers are still noobs with SQL.
Anyway, if rendering is lightweight, then why does it bog down web browsers when you move it there? I don't think it does. If all you did was ship the JSON and render it with something like Handlebars, I think the browser would be fine, and it would be hard to tell the difference between it and server-side rendering.
I think what causes apps to get slow is when you not only render on the client but implement a single-page application. (It's possible to have client-side rendering in a multipage application, where each new page requires a server roundtrip. I just don't hear about it very much.) Even client-side routing need not bog down the browser. I've tested it with native JavaScript, using the History API, and it is still snappy.
I guess what it is, is that the developers keep wanting to bring in more bells and whistles (which is understandable) especially when they find some spiffy library that makes it easier (which is also understandable). But after you have included a few libraries, things start to get heavy. Things also start to interact in complex ways, causing flakiness. If done well, client-side code can be snappy. But a highly interactive application gets complicated quickly, faster than I think most programmers anticipate. Through careful thought and lots of revision, the chaos can be tamed. But often programmers don't spend the time needed, either because they find it tedious or because their bosses don't allot the time --- instead always prodding them on to the next feature.
How can you keep yourself accountable? What motivates me is to focus on the other, instead of on myself.
If you're doing the minimal amount of work, does that mean that the users are suffering? If you had put in more effort, would they be able to get more out of your software with less effort? The drive to make the best experience for my users motivates me to learn everything I can about design.
What about your fellow programmers? Does anyone else have to deal with the code you wrote? If so, is your code sloppier or harder to maintain than you could have made it, had you put in more than 10%? The drive to make code a joy to work on, for others and myself, motivates me to learn.
What about Google? Are they getting their money's worth out of you? This is a bit harder to sympathize with, being that now we're talking about a rich company instead of particular people. But think of it as a test of your honesty. Did you agree to work a certain number of hours but are really working a fraction thereof? Don't get me wrong, no one that I know can code for 40 hours a week, 50 weeks a year, without burning out. But I think your managers, if they understand programming, expect some reasonable fraction of your day to spent working hard, doing your best, etc.
Many sites could be built on the stack espoused by Alex Petros, "The Hundred-Year Web Service", <https://www.youtube.com/watch?v=lASLZ9TgXyc>: SQLite, Express.js, Nunjucks, and HTMX.
But if your app needs islands of interactivity, my library does it in a way that I haven't seen elsewhere.