[jiggawatts]

Many other frameworks copied this approach from PHP.

For example, both ASP and ASP.NET can be developed using Notepad.exe directly on an IIS web server, and you can similarly test changes by simply refreshing your browser.

Personally I'm allergic to this style of development, the "banging on it with a rock until it starts moving" approach tends to result in poor outcomes over the long term.

I much prefer that a compiler go over the entire codebase and check everything when I hit the compile button.

Sadly, this bad habit from PHP still lingers in ASP.NET Core to this day, and causes me endless grief.

Just over the last couple of months, I have encountered the following:

- DEV, UAT, and PRD are out-of-sync with each other and the source code. When I asked the developers why that is, they said they make changes to individual files instead of "building the whole thing", because "that's faster". Okay, they saved the two minutes the pipeline takes to run, great. Now I have to spend a week disentangling the mess.

- I refactor something, hit build, it comes back with all green ticks, I deploy... and the site is broken with HTTP/500 a day later because these scripting-style frameworks don't build the page code until runtime.

- A security vulnerability code scanner was enabled, and it broke the build. Why? Because it actually builds the code, all of it! Except that these frameworks have two sets of page template files that contribute to the "final product": 1) the list of page templates registered with the build system or VS project file, and 2) the list of files physically in the Git repo. Some build steps consider only the former, the web server considers the latter. You can remove a page from a build system, and it'll remain working. It's like removing C code from Linux and still have it turn up in the kernel! That's nuts, and a security nightmare. Cough-xv-cough.

PS: It's possible for ASP.NET Core to be configured to both compile every page on publish and support hot-reload and automatically include every file in the build if it's physically in the folder structure. This really ought to be the default, but isn't... to pander to ex-PHP devs or something.

[mrtksn]

>I'm allergic to this style of development, the "banging on it with a rock until it starts moving" approach tends to result in poor outcomes over the long term.

I was sold on this too, that's why I left PHP for sexier stuff and never regained my productivity. As it turns out, most of the time I don't have a complete idea on what I'm doing but instead I have a direction and banging on it with a rock until it starts moving *in the right direction* is very productive because the design happens at the same time with the development.

My PHP code was complete "garbage" but it worked as expected and made me money and/or satisfaction of building things. Later I improved my coding skills and become much more aware of patterns and structures and found myself optimising the code instead of the product, destroying my productivity because as it turns out computers don't actually care or reward you for beautiful code. All that matter is, what that code is doing regarding the expectations of the humans who benefit from it.

[throwaway92748]

I worked with PHP XX years ago, and we didn't have that problem. I think that once you have access to a machine, it will always be possible to make direct changes. It's just that PHP made it easier, and in some cases it was also acceptable that the prod environment was temporarily broken until the developer undid their changes. You would just mess up a single page (or route).

Example 1:

I developed internal tools on a single server. The way I would do it was to have a personal folder on the server that I could use for development. Then I would commit the files to CVS which was the used for "deployment" to the main "production" folder. This worked well for me.

Example 2:

We also had a customer facing website where this practice was not allowed. We had proper build pipelines that created RPM packages which was installed by hand on the production machines.

My point is that there were many ways of avoiding editing the files directly in "production", even back when PHP ruled the world.

[jiggawatts]

“The problem didn’t happen to me” doesn’t mean the problem doesn’t occur. It’s like speeding.

PS: I saw a developer take out an 80K user enterprise because they tried to change the look and feel of a login page live on the prod server. They didn’t know any better because they were used to editing pages in live systems. That bad habit resulted in about a million dollars of lost work.

Oops.

[1oooqooq]

that shop could be using the latest academic language with full guarantee syntactic checks and perfect compiler and testing... you would still have the same problems.

[jiggawatts]

I've found that you can steer any group of people towards the pit of success instead of the pit of failure.