I'm a fucking webmaster (2016)
justinjackson.ca
justinjackson.ca
I quickly ditched that topic and went right to building a web page. Taught them a few HTML tags and they instantly became "webmasters". They were so thrilled. They could create blinking text, could make all the fonts pink. All just by moving around some simple text in NotePad.
Most importantly, they were creating things that they thought were only able to be created by "scientists". I loved how it boosted their own self worth.
I've stopped teaching a long time ago. Not sure if there's still tools out there where a 13 year old kid with no technical experience can immediately get gratification with something so simple on a computer. Maybe it is a time gone by.
If you can get a modern text editor that can use SSH or something to mount a remote directory you can easily have an HTML party like it's 1999. That's easier than ever. But the surrounding issues are worse than they were in 1999, unfortunately.
The problem of warez is certainly no worse than it was 30 years ago, and there are much better tools to address it. A simple storage quota probably goes a long way.
It's simpler for us software engineers, less simple for the snot-nosed webmaster wannabes we were.
If all you want is to host static html, then any free hosting service will suffice. I.e. let them create a GitHub account and show them git add / git commit / git push and you're done.
It doesn't get much easier than signing up for e.g. Glitch.
Even the simple matter of port forwarding assumes you have access to the router you're using, and that's a major barrier for a lot of people.
I run the programming club at my high school (I'm a high schooler), and we use Github pages to host all of our stuff for this very reason.
I've used some old laptops to run servers within the network, but my school doesn't want us hosting anything public, and running everything through a free tunneling service like localtunnel is possible, but it scales so much better when students can just follow some friendly instructions to host a static site themselves.
It's not hard for the people with the privileges of (1) having a budget > $0 and (2) not having the adults tell you 'no' every time you want to try learn something.
Am I missing something? Even hosting static content on a server seems like a layer of complexity that is frequently unnecessary for basic use-cases.
You can do this in an hour with brand new coders. https://syllabus.codeyourfuture.io/fundamentals/week-1/sessi...
I think it was called Grid<something> or <Something>grid, I just had a look but couldn't find it
Think it was somehow linked to schools, this was in the UK around 2005
I can't answer that for a 13 year old, but I can for an 8 year old. Minecraft. The elaborate stuff my daughter built at that age is way more gratifying than anything I could have built as an 8 year old.
Lego MindStorms! There's a lab at my local university filled with Lego and basic robot sensors/actuators. Schools and other community clubs can book one-time or regular workshops.
What fascinates me the most is the adaptability to the students' abilities. Young students can do "block based programming", telling the robot what to do with very simple command blocks that connect to each other. With rising profession, advanced blocks can be made available that are more powerful, resembling software control structures. New sensors can be used and robots are built by the students themselves instead of prebuilt. At some point, you can ditch the graphical block based programming and show the generated Java code and introduce the students to basic software development.
Now people talk about getting their kids started with programming, and end up talking about raspberry pis and Linux distros and whatnot. Granted the tools now are so much more powerful, and a determined kid can write a best selling iPhone app, but there's something wonderful about a machine that shows up to you as a blank slate, awaiting instruction.
I am reminded of the old Kids React videos (which themselves are now nearly a decade old)... Kids React to Technology (an old Apple ][+) https://youtu.be/PF7EpEnglgk
When you boot up a MSX it was the same: a straight command line waiting for inputs, learning to command that was quite magical for 8 year-old me and my intro to programming in general.
Create an HTML file and open it up in the browser without a web server (though some advanced stuff will need a web server running). The developer tools built into the browser can be used to interact with the page and see how changing HTML, CSS, or JavaScript affects it.
Web console can be used to experiment with JavaScript, https://firefox-source-docs.mozilla.org/devtools-user/web_co...
I just wanted to make a website to start off with, just a bunch of linked pages. I already knew a tiny bit of HTML from college, but that was years ago and I wanted to know what had changed. So you can imagine my confusion watching that CS50 lecture as it was seemingly covering everything EXCEPT the stuff non-technical end users are familiar with: websites, apps and games.
Yes, yes, I now know that CS isn't about coding but about underlying fundamentals. But that doesn't change the reality that CS50 online has been viewed many, many more times than people who've sat in a CS class, and those people likely had similarly simple goals as I did.
Long story short however, I took a video course on webdev and learned far more in terms of immediately applicable skills. Again, I wasn't trying to get hired at FAANG. I just wanted to get to the level of 'webmaster', where I knew just enough to handle markup, hosting, SSL and CRUD functions. Learning by doing has been far more rewarding than following online courses.
That was not good advice. CS50 is an excellent, introductory, survey CS course but it's still a CS course.
You and I may know that the question is a bad one, but beginners don't know that. And when they ask, they aren't told to rephrase the question as "What would I like to build?" Someone will just say "well I know Javascript and...." and it goes from there.
I didn't know a lick of programming, but just knowing how to trace the 0's and 1's through the hardware greatly boosted my confidence in interacting with the computer.
No matter what program or language got put in front of me, I knew that something on a disk or in memory, or in some storage somewhere was telling the computer to do it.
Then I set out to understand the people who wrote those things and what they set out to do.
Then I realized I probably hated most of you. Because you went out of the way to make having my computer do what I wanted harder.
I'm somewhat reluctant to encourage youngsters down the path. I'm not sure it's the healthiest occupation.
I think a lot about the way the web was back in the mid 90s, compared to the bleeding-edge technologies of today, particularly blockchain and cryptocurrency.
And one major aspect I keep coming back to is that web technologies in the 90s, and even their descendent technologies now, are simple enough for most technology-literate people to understand, and that carried with it a lot of comfort and trust.
For anyone who had been using desktop computers and office software in the early 90s, which was basically everyone who was a student or an office worker, the web was just files on a computer, served over a network, which we already had plenty of experience using. And I think that's why my father, who was only a little older than I am now when I first showed him the web, grasped it straight away and was supportive of me building a website for his business.
These days I'm not spending much time writing HTML files in a text editor and uploading them via FTP; rather I'm writing programmatic code that talks to a database (A database! Just like MS Access or FileMaker Pro), does some processing, and displays the result on the screen with some elaborate JavaScript to make it look and function how I want (I’m happily a heavy user of React for building rich web apps), but it's still fundamentally the same concepts. Files on servers, accessed over a network and delivering useful information to my browser or app. The beautiful simplicity is still there, and it still doesn't feel like a big leap from the kind of computing we were doing 1993.
The world of blockchains and cryptocurrencies and "web3" feels vastly more opaque and esoteric by comparison and therefore untrustworthy to many of us, which I think is a significant answer to the question that was asked here in the past couple of days: "Why is Hacker News so anti-crypto?" [1].
I can't quite accept that it's just that I'm "old"; firstly because first heard about Bitcoin soon after it appeared and was excited by its potential, but also because I remember how people older than me reacted when the web arrived, and there was much more rapid acceptance and embrace than there I currently see for cryptocurrency, outside of those who are just chasing quick riches.
Give me some bitcoin and i would not know what to do with them except changing them back into money.
You can’t think of any situation where you would want to share access to and control of data with multiple untrusted third parties, where you would need to guarantee not only that data modifications are only executed in an authorized fashion, but also that no previous modifications have been reversed?
The list of use cases for that capability is not limited to “money laundering and tax evasion.”
Do you mean a cryptographic signature? Been doing those for decades back in email chains and newsgroups. Each message could contain the prior messages and their signatures. What’s new was assigning a currency to it.
But you can't rely on this approach to ensure that surreptitious deletion of old messages or threads is impossible. Not every old message in a newsgroup will be duplicated within new messages, and threads will typically not reference each other.
If an old message or a separate thread provides necessary context for interpreting a new message, the maintainer of the newsgroup or the email server has the ability to change the meaning of a conversation simply by deleting messages or threads. Or the owner of a relay server can block certain messages from propagating. You still have to trust these people.
Email is itself very decentralized, at least in concept, with every new email being copied into multiple accounts on multiple servers, so censorship like this is more difficult. But you can imagine how in a more centralized system (like Facebook or Twitter or HN itself) history can be rewritten by the entity hosting the conversation simply by their deleting messages. If all references to the unwanted messages are also removed, then for all intents and purposes, those messages would never have existed. Gmail is dominant enough that you can imagine Google being able to assert this power over much of the email traffic that currently exists.
A blockchain ensures that every modification to the shared state follows rules that all participants in the system agree upon. No modification to that global state can occur unless those rules are strictly followed, and because all participants receive all details of every state modification, the entire history of the global state can be replayed at any time by any participant such that surreptitious deletion is not possible. There is no other technology that I am aware of that is able to systematically prevent surreptitious deletions.
Cryptocurrencies are not the only thing that is new, and they are not even the most important feature of blockchains. Cryptocurrencies function as an incentive mechanism to ensure that there are a healthy number participants validating the state transitions. They can improve the reliability and security of a blockchain system, but there are blockchain systems that do not depend upon them.
Every single concrete example I can think of personally would work better with a normal database and some kind of Auth scheme which does not involve Blockchain, but maybe I'm just thinking of the wrong usecases?
Sounds like tax evasion/money laundering with extra steps to me.
You could call it justified tax evasion, maybe. If I'm being generous.
My assertion is quite different: that people familiar with basic computing technologies have a natural intuition for web technologies, which brings with it comfort and trust, whereas this is not true of blockchain and cryptocurrency.
As I said I was excited by the potential of blockchain and crypto, and would welcome it being widely adopted, but I suspect this factor is a major barrier. I’d welcome evidence to the contrary, not sneering.
How to I add some data to a blockchain? What is a blockchain?
I vividly remember that time in 1996 when I had to explain to my schoolmates what a _webpage_ was. (Whithout really having an internet access yet.)
What is opaque are all the various bizarre schemes to try to turn them into something useful and profitable, because they really aren't good for that much. (Non-zero. Definitely non-zero. But not really that much.) You either have to stretch them into a space they aren't really good for, or all but create a problem they can solve, but essentially doesn't otherwise exist as a problem. This is where a lot of the complication lies. NFTs, for instance. Drop-dead simple technologically, really. The confusing part has always been, why would anyone spend that much on a fairly crappy picture of a monkey? There's multiple layers of "wtf" to unpack in that question. But the technology itself permitting it isn't that complicated.
Ironic that payment via random drawings became a "reality" in this crazy world after all.
"Web3 is <anything at all>? Are we sure about this? Just because it was on someones blog?"
It's an empty marketing phrase that some people have latched onto.
Despite all the vague talk about freedom, really, web3 is all about cryptocurrencies. That is, web3 needs cryptocurrencies to work and it has no reason to exist without cryptocurrencies.
I was a 9 year old building websites in the 90s, and while I could write HTML and upload files via FTP, I had no clue about TCP/IP stack, socket implementation on the filesystem, how Windows 95 and Windows NT core worked, how my Pentium processor worked, and about a thousand other technologies that I used in the process. I relied on abstractions.
> The world of blockchains and cryptocurrencies and "web3" feels vastly more opaque and esoteric by comparison
Nobody's stopping you from just as blindly trusting underlying web3 abstractions as you did in the 90s with the web. But we're professionals who learned not to do that and have drastically different approach to technologies that we use. We're not 9 year old kids anymore. We had to learn these things after waking up to an outage, or after our site struggled with 10 requests per second (because we didn't know that database indexes existed), or after any other number of perfectly valid reasons. Now we don't trust tech, we read the whole documentation, and we want to dig in.
The world hasn't changed as much. It's us who's changed.
Except that most web3 technology is property-related. There is no easy undo and try again. And getting off the ground as a minor is probably extra hard with such things.
I have missed the discussion you have mentioned. But I remember 10 years ago HN was opposite to anti-crypto. And the anticryptoness of nowadays for me seems like stupid ppl who don't understand some basic principles and downvote me if attempting to criticize their misunderstanding.
Name-calling and assuming that everyone that "doesn't get it" is stupid is non-conducive to discussions. Worse, it makes your point much weaker because now there are only the "true believers that have seen the truth" and the "stupid sheeple" as opposite groups, which is a very stupid take in itself.
A huge problem here is that it's very fast moving.
Take the fast moving Web of the 90s and multiply it by how much more people use the Web today.
At Eth Amsterdam I talked to many engineers from that space and didn't get a satisfying answer to many questions devs usually ask about new tech.
"Where should you store your data?" - "It depends!"
Back in the days, and even today, in Web2, you would spin up a relational DB and it would be good enough for 99% of use cases.
I know, that changed with the rise of NoSQL, but in Web3 it's even harder.
I'm not even joking; everything they do with blockchain can be done cheaper, easier, and just as well without it. They do the minimum they need to to hype themselves up as being "Web3" and that's it.
For me it's more that we can already do everything web3 does without the blockchain sprinkled all over it
The only thing web3 adds to what we are already capable of is a participation fee, which sounds like someone was tasked to implement the worst possible version of the internet
When there was less distinction between programmers and just everyday people, convenience was a high priority in the authoring tools.
Web3 could be amazing. There's no reason it couldn't just be like BitTorrent, but for web pages, with even better performance on mobile.
JS frameworks are just files. Nothing really troublesome about that, besides the fact modern expectations demand a backend and CMS, unless you really want the full retro experience.
Even then, most of what backends do could be done by some hypothetical extension to WebDAV for search. Or just like, add a SQLite query verb to HTML with a standard permissions file or something. There are ways this could all be easy.
SSL is another problem. There used to be one protocol and one thing to set up. HTTP. Now you need certs, and it takes a bit more effort, and it's possible to mess up in a way that takes a half hour to fix. Not quite frictionless.
Facebook is free, but personal sites aren't.
Web3 could be exactly what saves us, giving us a standard platform to make sites for free, that does the security for us, doesn't need a domain name, and is generally really easy while still following modern standards.
We could literally have a browser with a "Make a site" button that works like a file manager, with a "Link to seedbox" button.
IPFS and the like are trying, but none quite reach BitTorrent's level of practicality, and they're all weighed down by cryptocurrency.
I think we really do need a Web4.
I remember seeing a team member migrating a project from grunt to webpack, the project was just a 404 page. "You need to compile your assets" they say, just a cat *.css > site.css would do it. Or even better, just do it inside the HTML and that is it.
People who need a JS library to check if a number is odd or even went way too far, I'm not exaggerating - https://www.npmjs.com/package/is-odd
[1]: https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even
It seems like a lot of people think they think how npm should work, while forgetting to see how npm actually works.
There's even an example of a well respected npm author that has repositories with just a few lines..
Y'all just love to hate on npm
If that were true, it would be useful for the author to actually explain that in his repo documentation. As it is, concluding that this is a joke is by far the most reasonable response.
Or you could check the lowest bit. Better to abstract away from that implementation decision. ;)
If someone wants a 1 line dependency, I say let them. I have zero issues with that.
Again, if you think something is not how it supposed to be, maybe YOUR view on what it supposed to do is whack instead?
n % 2
if you don't like the % you can also do it using a bitwise AND, this also handles negative numbers: n & 1
this is equal to 1 if the number is odd, 0 if it is even, and will be converted to true or false in a if statement. You don't need a library for this.And you should not need a library to handle string conversions, you should be aware of the types you manipulates. If you do need to handle strings, that's still easy:
Number(n) & 1
And Number(n) is a no op if n is already a number. But wait, no, actually, you don't even need this because % and & will auto cast the string to a number anyway. You can use parseInt(n) if there's a chance that your number is going to be non integer, but meh.So n & 1 will cover everything.
All this is readable and idiomatic, there's no need to write a function for that, let alone a full fledged library with unit tests, package.json and all this crap that bloats the node_module folders of everybody.
isOdd = require('isOdd') and your entry in the dependencies of your package.json is going to be more verbose than isOdd = n => n & 1. Even "isOdd(n)" is longer than "n & 1". Nothing beats the "& 1".
If people are going to write libraries for all kind of similarly small and trivial things, soon we will need more than the Earth to handle our code.
After reading your comment, I'm starting to think that isOdd is not only more readable but safer. I don't think I ever thought about n % 2 not handling negative numbers, and I'm not sure I would immediately recognize n & 1 as equivalent to isOdd. In languages without truthiness, n % 2 == 0 is longer than isOdd(n). Likewise, even with truthiness, n % 2 == 1 is longer than isEven(n).
I suspect that the real problem is the cost of adding dependencies, in terms of package size, performance, and security. All these problems could be solved using linking, inlining, and auditing.
That does not hold true for more complex stuff, but to test whether a number is odd, come on.
You'll test your code if it works anyway and if your odd test is wrong it will show.
But yes, you need to make sure on how '%' works in your programming language especially on negative numbers (and on non integers) because that can differ.
If you are testing whether a number is odd and that number can be negative, you'll probably think about it anyway.
That's a trap you should encounter once and then you are good.
The thing is, n % 2, i need to do mental gymnastics do comprehend whats going on. Even if your function is just one line, I rather read isOdd or isEven instead of n % 1 of n % 2, remembering when 1 or 2 stand for even or odd is something I could have trouble with.
n % 2 or n & 1 is something you likely get used to if you encounter it frequently enough, and at least something you should recognize after the first time you encounter it. And most people should have encountered it at least once because that's one of the things we learn to do when learning programming (but I guess Ten Thousand [1] can apply). If you don't encounter it enough to be used to it, then the rare gymnastic should not be a big issue neither. You need to be able to recognize it because it's in the wild.
If having an isOdd or isEven function around makes the code more readable for you anyway it's fine, especially if the function can be inlined, but pulling an external dependency for this is overkill.
That's a huge if!
So abstracting a one line in a function is actually good. Putting it up on npm is debatable.
Anyway, Javascript, like virtually every programming language, has "& 1".
Yes, the standard library is lacking and yes, that's a big issue, partly responsible for the huge mess that is NPM. No, it does not matter one bit here so this is off topic.
The sassc CLI app is pretty good for this. It's a single binary, has a watch mode, and just compiles SASS to CSS. Although for a 404 page that probably is unnecessary (unless it's pulling in shared styles from somewhere else of course).
That said, I've been in the Go ecosystem for a while and while the language itself is fine, it's the associated mindset and catchy oneliners that have been more valuable to me as a developer.
I finally understand how `node_modules/` directories grow to 100s of megabytes for the smallest apps
Turtles all the way down.
In most other ecosystems such as Java, Python, PHP, etc if you have a dependency A that depends on B 1.0, and a dependency C that depends on B 2.0, you cannot have both of them installed, so you either pick one or the other, or some intermediate version which works in all cases, but many times you end up not being to use one of them or, worse, not able to upgrade either A or C because you cannot resolve all the dependencies anymore due to constraints.
In node you can do this, you can use both A and C even if they use their own, incompatible B versions. If both A and C depend on the same (or compatible) B version, then you only have one as in the other ecosystems. And you can always enforce and override what final version you want if necessary.
This, plus usually the inclusion of documentation, type definitions, source and transpiled code is why node_modules is usually pretty big.
But you don't ship node_modules "as is" to the browser (200MB node module does not mean a 200MB bundle). And usually this is not a problem for any modern laptop or server.
Is this better? Is this worse? Can't say, it is just a different tool with a different trade off.
But just "node modules 10Gb is bad" to me only tells the bad side of it, and usually comes from a lack of understanding of how this works and how it compares to other systems.
If you want to be safe if NPM goes down, what you need is to keep an archive of built "binary" releases, either zip files, docker images, or whatever.
You can also have internal NPM proxies or caches too.
Committing external dependencies in the codebase is a terrible solution. And no, google doing it doesn't mean it is good for everyone else, probably more likely to be the opposite to what you need.
Yes, you did. Quoting: "...Anyone not committing the entire node_modules to their repo..."
> you're not revisioning your deployments
That's what I'm saying, quoting: "...If you want to be safe if NPM goes down, what you need is to keep an archive of built "binary" releases, either zip files, docker images, or whatever..."
Using Git/SVN/etc repository for this (which is what I kind of get from your responses) is just using the wrong tool.
That's pretty much most HN content about the web / front end development. I find HN al but useless for that topic now.
I've had this thought in the back of my head that a lot of content / comments are on HN are folks who do a little, not a lot, and are really annoyed that they have to do any front end development, so then we get rants about this and that... they're not fundamentally wrong, but as a web dev I find them a little skewed and completely useless / just negativity.
Like how many "I made this rando personal blog without a framework" and "there's too much javascript" (page includes lots of javascript) and etc that gets boiled down so far that it is pointless?
We're at the point a loading icon gets upvoted on HN to bitch about SPAs ... and I don't know about you but a hell of a lot of pages can sit at a loading icon that aren't SPAs. How disconnected is that?
Front end development discussion a land fertile for bike shedding and just about every topic can dip into it now, movies, music, all media really ... questions about who pays for the news, censorship, etc. Somehow it all gets pulled into the tech discussion as well.
Sometimes I just want to find a place to discuss it where we find neat things to do and less campaigning about every other topic.
I think if more people would at least try to build and maintain their own website, starting with the barest of basic HTML, we'd have less of this tech wistfulness around the old web. They'd do one or more of a few things:
1) Find a personal outlet in the hand-rolled site.
2) Find that outlet, but get tired of wading through angle brackets and set up/write a static site generator.
3) Find more they want the site to do and start coding.
4) Realize they've exhausted everything they want to say to the world and abandon it.
But what else would happen in any case would be a demystification of it. Old hands would lose their nostalgia goggles, and young folks would recognize how much of the irritations of social media derived from people's dissatisfaction with the time and effort it took to shout into the void on the old web.
And the fact that everything is SaaS now, well, that just gives me motivation to keep it that way.
Easy for me to say, of course, since I grew up back then and was fortunate to have the experience of the pre-modernization of the Internet. Good times.
Back then it was obvious to me that was the coolest thing you could possibly learn. Still to me it is outrageously cool that I can think something up and then in not that much time it can be a website.
So whats the new magic? To me it's the idea of being able to think something up and conjour it into the virtual world too.
Yours is the first perspective I’ve seen that actually made me curious.
This combination of presence and multiplayer create these crazy (to me) experiences where it's like you're stepping into the internet to meet people and explore it with them.
VRChat is one of the more popular examples, but most of it stuff still needs to be built in the first place.
* Once the resolution is a little better - virtual offices[3] and cinemas[4] allow for significantly more screen real estate than a traditional setup, requiring less space and capital investment.
* Live/pre-recorded virtual concerts and sports games[5] are already occurring (where you can invite friends to watch in real time). The current 'experiences' (wingsuit flying, virtual tourism, etc..) are far more immersive than watching the equivalent 360° Video
* VR fitness is a reasonable method of cardio, burning ~9 calories a minute. It can also augment other training methods, such as a stationary bike[6]
* Haptic suits[7], gloves and treadmills[8] - not really my thing, but allowing 360° running and feeling the interactions with your environment.
[1] https://www.youtube.com/watch?v=keufFXiO1_M&t=3m45s
[2] https://www.youtube.com/watch?v=_ZFiaILqQng
[3] https://www.youtube.com/watch?v=5_bVkbG1ZCo
[4] https://www.youtube.com/watch?v=Sh9n0bZcprk&t=1m7s
[5] https://www.youtube.com/shorts/duMowUK6tk4
[6] https://www.holodia.com/vr-fitness-blog/holofit-vr-works-wit...
Don't get me wrong I like old tech, but just for what it is. Text based, simple, fast etc...but I don't like wallowing in a warm, fuzzy feeling about how it was.
I mean I personally do recall 5.25" disks. I liked their look and feel as a kid. Fine. But making a big deal out of it feels retrograde...
I started as a web designer as images were being added to browsers and you could change the default grey background colour. Things are a bit different now...
It's not negative. It's an interesting sentiment, but one I think is based on a misperception or mischaracterisation, if you'll permit me;
Nostalgia is about experience and feelings. It often has idealising elements, attempting to restore something bound to a specific past time or culture that can never actually be revisited. Wallowing in a warm, fuzzy feeling" as you describe it, is depressive.
That's not what's going on in tech.
Tech people are experiencing disgust, frustration, anger, hopelessness and a whole range of sentiments hostile to current tech which is objectively broken in a number of ways. And justifiably so. We have wandered off the path, not just the path of "excitement and fun" but right off the path of utility into the long grass of bloated, brittle, precarious, unfathomable and unmaintainable complexity under the yoke of exploitation and false efficiency.
The desire to move "backwards" is a desire to fix things.
Many of the qualities of earlier tech can, and should be revisited.
We're in a cul-de-sac and unable to progress precisely because we label earlier technologies as "necessarily inferior". It is an arrogance and parochialism of false progress to do so. That mind-set always sees any sort of back-tracking as negative regression, or "anti-progressive". But sometimes the way forward is back. Remembering where you've been, is central to any successful algorithm that's navigating a maze (which is what technology is).
Projects like Gemini and distributed "New Web" based on overlay networks are not regressive. They are very contemporary attempts to distil the best elements of the 90s internet culture and re-orient development from there, but with the hindsight of knowing how not to do things.
> Don't get me wrong I like old tech, but just for what it is. Text based, simple, fast etc...
All of those qualities are also possible with new tech. And they make the new tech even better. And as energy and environment bite, we'll start to see them as positive qualities to move toward... in other words our definition (direction) of progress will evolve.
I distinctly remember I could never seem to manage to make a website fast. It was always quick (total load time <10s) but it was never fast (<3s). I spent so long learning underlying systems and various caching options.
20 years later I can throw together anycast DNS, geo-routing, web/SQL cluster, in/out MX services, memcached cluster, load balancer, whatever you need. No bother.
I'm glad that first site gave me so much grief!
- Peter Ferrie's homepage (http://pferrie.epizy.com/?i=1), old school: approx. 900ms
- Netflix landing page (https://www.netflix.com/de-en), modern: approx. 1.8s
Measured via Firefox "load time". Peter Ferrie is a famous security researcher.
The Netlix page is clearly 2x as slow, but the load time is far from proportional to the overall data transfer.
The HN front page, right now, takes approx. 1.7s. :)
I’d say, compare it to Reddit or Pinterest or something like that.
It feels like websites are a lot jankier today. The old web was slow, but it was predictable. Like I know a site where if you don't wait for it to finish to load (and it's javascript loading, so you get no browser indication that it's actually loading), then the all the links will be wrong. That is, you get the wrong content if you click a link. It's quietly kind of amazing how they've managed to break hyperlinks, given they're a part of HTML itself and work well out of the box.
Full screen bing.com-backgrounds weren't really a thing in web design, though. Except in porn, I guess.
But there's plenty of websites out there still - including HN - that do without all of those extras. And it's up to web developers of today to resist using the fanciest technologies to build websites.
At some point there was the concept of (iirc) progressive web apps, where the basis was all HTML - fully functional, you could turn off JS and CSS and it'd still work - and then use CSS and JS to add functionality on top, but that would be purely embellishment.
The amazing part was that everyone had a homepage at some point, where they put content online about topics that they thought was worth sharing.
Even girls in school had a website with sparkling rainbow gifs and a guestbook, and some pages about topics they liked... like smallville series character details, some cake recipes or games that they played. Oh boi have I read way too many things about dragons or vampires in historic literature.
Those websites were usually hosted at all those ad driven freehosters like geocities or funpic, so they sometimes injected their own ads to fund the hosting costs.
But honestly, I'd take the old version of the internet any time again over the dumpster fire that is social media propaganda and coordinated/incinerated defamatory shitstorms these days.
The internet was a welcoming place for everyone, where people shared what they loved with others. The internet was a nice place. And then, the facebook and the chans happened, and everything kinda went to shit.
I remember it took about 20-30 minutes to download an mp3 in the dialup days. Most websites were in the kilobytes because everyone was on dialup. Also keep in mind most screens would have been 640x480, so it's not like you were getting high res images.
Depends on the amount of gifs people were placing on their website :D We only had a 56k modem at the time. The Browser was provided by the ISP at first due to lack of dial-up software that supported the German ISPs, so it was loading all kinds of injected stuff from the ISP, too.
But yeah, I agree with the general sentiment that websites usually loaded way faster if you were using e.g. IE3 on purpose because it didn't load all the stylesheets and images.
Pages were anything but intuitive, there were no design standards. Most marketing pages looked like their art director imagined a futuristic movie prop.
There's still a ton of interesting pages out there, check out this collection: https://www.hoverstat.es/
I remember when some supergenius sent the first email as a word document with a 2 mb company logo embedded, and loading that took some 20 minutes - each minute being metered indivdually, only to then contain two lines of text that ought have been the mail body...
The internet was better back in the day - but it was not faster.
That's called progressive JPEG, and it's still around.
Now that I think back the computers "acted" really differently from what we use today.
Things felt much more "immediate" (as in the computer responded to you very quickly) but also much slower; imagine that your keystrokes occurred immediately but opening a window took 50ms.
If the CPU was being hit with any kind of load though, the input would buffer and your keystrokes would stop being presented until the GUI got some CPU time again and all your keystrokes just poured into the active window.
The web itself was a lot of slowly rendering webpages, the sites themselves would actually start loading much quicker than modern sites, and the content would progressively load over some amount of time, there was usually a progress bar at the bottom of the Web Browser.
I know I'm only a few years older than you, but I wonder if you remember all this.
From what I recall the most annoying thing was slowly rendering images.
Oh no; they weren't faster because computers and browsers weren't nearly as fast as they are today (iirc it was Chrome that emphasized performance, especially JS performance because it saw how much more that was going to be used (for ads lmao)), and not intuitive because there weren't as much guidelines or awareness of UX as there are today.
There should be plenty of websites from the 90's on archive.org
In the meantime computers and the internet became so fast that websites could be very fast by default, but the front-end tech stack and adtech still makes it slow most of the time.
It was an easier time back then.
We learnt HTML basics: displaying paragraphs, images, blinking/colored text, marquee, etc. It was definitely an eye-opening moment for me: computer was not a device only for playing games or typing documents, but something that could run what your instructions are.
Then during high school days, I learnt more serious programming languages: Basic, C, and Pascal.
These days, web frontend is definitely more complicated: HTML5, JS, CSS, etc. Nope, not interested to touch them anymore :)
>Our websites were pretty damned ugly. Instead of worrying about window dressing, we focused on words, hierarchy, and structure.
Naw, the sites were ugly because we were bad at window dressing and the tools were wonky ... and it was glorious that we were bad at it. I loved the ugly web. It reeked of "trying things".
For me personally, the appeal of the web back then was not that it was good, rather it was new.
Even today's web sucks without some heavy ad-blocking and script controls.
I do not think it is smart idea to make everything into web app. My daughter for example is Web Designer / Web Master and makes very healthy living designing and building front ends for various businesses. She does not see less need for her skillset over the years. Just the opposite.
atticshapes.com
I reviewed before adding comment, and I feel like changing info@ to webmaster@ now, in homage to the internet.
RFC 2142 [1] defines both those (among others), for different purposes. I tend to set all those for the used services (and one for XMPP, per XEP-0157 [2]) as aliases: usually it's not hard and costs nothing, but allows to adjust the aliases in the future (in case if somebody else will maintain some of the services), and provides standard ways for inquiries regarding those services.
Does anyone remember the early anime community of those days, by chance? It was such a vibrant community of builders and "webmasters".
Always amazes me how rose-tinted people who supposedly deal with cutting edge technology are.
I do feel like HN still gives off better vibes from the better days when the netizens had netiquette, when the information superhighway beckoned to the explorer, before the undying flame wars…
There was actually a competing protocol in those days: gopher. It still exists and has a small, near-fanatical community these days.