4 ms·
On reflection, the thing I miss about web dev in the '90s is the low user expectations. Because I was going to say I missed the simplicity of it all -- your fr
by mkozlows 7y ago
On reflection, the thing I miss about web dev in the '90s is the low user expectations.
Because I was going to say I missed the simplicity of it all -- your front end was just HTML, no CSS (which didn't exist yet) and only sometimes a smidgen of Javascript for like light form validation; your back end was just a Perl script with CGI.pm running behind Apache that rendered that HTML.
No React, no flexbox, no REST API, no microservices, no Docker, no Kubernetes... but the reason it didn't need any of those things is because it had a terrible UI, didn't do all that much, and only needed to support trivial numbers of users whose modems were probably the main bottleneck anyway.
Trying to make modern users happy with '90s era tech would be impossible and deeply painful.
But it was nice, just for a while, to have a world where people were thrilled that even a super-basic web application was a thing that existed.
- LeoPanthera 7y agoI still make websites this way because no-one told me to stop. They can be made responsive to things like smartphone browsers which incredibly minimal changes. No complaints so far.
- King-Aaron 7y agoPlease stop :P
- kvirani 7y agoLink or not real.
- didericis 7y agoWhat kind of sites do you make? I’d imagine that avoiding things like react is fine for a lot of sites that just need a bit of form input here and there and some nice styling, but that anything relatively big with interactive pieces would fairly quickly devolve into a difficult to maintain mess without components. I’ve sort of been trained to think that, though, as I was just starting development right before libraries like React started to get big. I remember reading cs books and learning about how important encapsulation and modularity was and then feeling like I wasn’t really able to apply those concepts adequately in my really early web projects. React came along and seemed like the best answer. Do you do something different to organize code related to more complex frontend user interaction than forms/animations, or do you find that you just don’t really need complex frontend user interaction for the websites you make?
- LeoPanthera 7y agoMost of the things I've made are not public-facing. I just try to keep things simple. My sites generally require page loads more than the average single page application, but they have the advantage of loading faster and working in nearly any browser, even super old ones.
- dpau 7y agoYes, it was a simpler time :) There was a job position known as "webmaster" who was basically a god. User expectations were low because users didn't know what to expect. Everything was so new. Putting formerly locked-away resources like job databases and digital libraries online blew people's minds. And we imagined that we were building a utopia where everyone could publish, and information was free..
- projectileboy 7y agoWith respect, I strongly disagree with your assertion that it’s the users demanding anything. Users are rarely asking for our bloated single-page apps; we just foist them on the public because we think JavaScript development is fun and cool. That’s not how we rationalize it to ourselves, of course, but it’s the truth. The majority of web sites (all newspapers, all magazines, many less trafficked social media sites, I could go on) would be served just fine with HTML, CSS, and minimal to no JavaScript.
- somatic 7y agoIf there were no JS, how would anyone make billions of dollars of ad revenue?
- tjr 7y agohttp://philip.greenspun.com/panda/user-tracking http://philip.greenspun.com/panda/user-tracking
- fbi-director 7y agoThat was... really interesting to read with a early 2000's mindset (seeing the date of the article)
- AlchemistCamp 7y agoPinboard is also a good example of this.
- tarsinge 7y ago> Trying to make modern users happy with '90s era tech would be impossible and deeply painful. Given my experience users can be delighted in 2019 by well-designed and lightweight UI built with just CSS and vanilla JS, instead of an overweight buggy SPA (usually built by engineers more interested by the code itself than solving the business problem in the leanest way). Source: I made that my business and I couldn’t be happier.
- zelon88 7y agoYou're correct, but so is OP. You're exceeding their expectations by providing less than they expected. That's easy to do when the user expects to be accosted by a slow loading page that comes onto his screen janky because of deferred stylesheets and 4 different Google fonts and 1.6mb worth of ads.
- crgwbr 7y agoSPAs are often buggy, but you can’t honestly blame React/Angular for that. I’ve built and actively maintain a number of SPAs in React. With some care JS size and speed is very manageable even in mobile devices. The thing that consistently kills site performance is ads and trackers. Of the sites I work on, GTM, Optimizely, FullStory, and other similar crap routinely are responsible for >75% of the JS weight and >90% of the HTTP requests. It doesn’t matter how much I prune our npm dependencies and tweak React to make sure it’s rendering fast—marketing is going to make the page suck and I can’t do anything about it besides generate page speed reports that the client will ignore.
- AlchemistCamp 7y agoInteresting. There were two primary triggers for me creating https://alchemist.camp https://alchemist.camp. One was that the Elixir screencasting I'd used site had very out-dated tutorials that often didn't compile or run on the post 1.0 versions of the language. The second was that I loathed the huge card-based design and the SPA the author moved to. I just wanted information density and scannability, not hamburger buttons and pages and pages of responsive cards. Similarly, I'm no fan of Reddit's redesign or the huge lag when loading IH and yet more and more content sites are going the same direction.
- BerislavLopac 7y ago> the simplicity of it all > No React True, but when I remember how we used 1x1px Java applet to allow reloading data without refreshing the page I would not call that simpler... And don't even get me started on Flash. > no REST API True, but when I remember fumbling about with SOAP I would hardly call that simpler... > no microservices True, but what we had instead -- monolithic PHP "applications" with insane hacks to integrate with other monolithic services, Microsoft' and Adobe's attempts to abstract the backend/frontend separation away and so on -- I would not call that simpler... > no Docker, no Kubernetes True, but when I remember the deployment mechanisms (upload via FTP), problems with scaling once our server became not enough (usual approach: set-up everything on a separate machine and then have a downtime until it was back up) and so on, I would certainly not call that simpler... There are always trade-offs, and you continuously have to learn new technologies and unlearn others...