| Thats great and all, but a lot of those things had their problems and subsequent tools were created to fix them. - FTP - deploys where one or two files would silently “not deploy” and since there are no automated testing, or error logging, it would sit like that for days until someone finds the issue - Version control - its great when you’re a solo dev on a project, but once you have more people editting the same project, things begin to break very fast. And god help us if we’ve been editing the same file at the same time. - SQL - sql injections anyone? Back then the auto exploit tools might have been in their infancy, and you could get away with security vuls sitting in production for years, but not any longer. The script kiddies are real and would find that _one_ place were you forgot to escape the string - PHP - yeah 2018 php is actually awsome, but back then? If you had to do _anything_ different from just displaying a document site in english, you were in trouble, memory leaks, charecter encodings, image manipulation ... And someone else’s code was so hard to use that if it was not your main framework, or a single class function, it simply wasn’t worth the bother. And yes I do have projects that were developed back then with those technologies, and are used successfully to this day (deployed by burning on a CD, and travelling to the next town to install it on a solaris box no less :)) I wouldn’t call dev “easier”, it had different problems, which were mostly solved by new tech. If you tried to do it the old way, you’ll run into the same old issues, _on top of_ the new requirements that you’d be very hard pressed to fullfill. |