Live data from Hacker News

I'm a fucking webmaster (2016)

justinjackson.ca

221–229 of 229 posts

Re: I'm a fucking webmaster (2016)

#221
post #121

Earlier quoted context omitted.

You can still just use HTML.

This does indeed work fine. The major problem is still finding somewhere to host it, and incurring the still non-trivial risks thereto, since among the many things students want to do with free web space, hosting warez and other things that will get you in trouble quickly is still pretty far up the list. Plus someone has to pay for a domain name or something. If you can get a modern text editor that can use SSH or so…

Netlify has drag and drop deploys now. Can't get simpler than dragging a folder onto a webpage

Re: I'm a fucking webmaster (2016)

#222

Earlier quoted context omitted.

You had to wait 30 minutes to wait for all those unicorn gifs to load, so I'd say it wasn't as fast as it could've been :D 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 charact…

This was my favorite ("I Kiss You"): https://methodshop.com/mahir-cagri-i-kiss-you-internet-celeb...

i remember sending out the "i kiss you" XOOM page to my entire AOL address book. that's how things went "viral" back then.

Re: I'm a fucking webmaster (2016)

#223

Earlier quoted context omitted.

It is a trade off. 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 re…

Anyone not committing the entire node_modules to their repo is in for a really bad time when npm goes down or gets compromised.

No, that's fixing the problem in the wrong way (by using your code version tool as an FTP more or less), complicating code reviews and unnecessarily growing your code repository.

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.

Re: I'm a fucking webmaster (2016)

#224

Back in the early 2000's, I taught "computers" to a bunch of kids in DC. I first started off with how a computer work; IO, CPU, storage and their eyes glazed over. 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 si…

My first experience of programming was walking up to an Apple II in grade school (this was in the 2000s, those were some old machines) and punching in code listing from a book. The machines didn't do anything when you powered them on, just waited for you to enter code or commands. It was so simple, and it just begged you to start writing programs. Now people talk about getting their kids started with programming, and…

Similar story but newer hardware. I was given a machine built with left over parts from the IT company my did did sales for. Booted right to the CLI. I was given a giant red hat manual and told to have fun. It was awesome.

Re: I'm a fucking webmaster (2016)

#225

Earlier quoted context omitted.

Anyone not committing the entire node_modules to their repo is in for a really bad time when npm goes down or gets compromised.

No, that's fixing the problem in the wrong way (by using your code version tool as an FTP more or less), complicating code reviews and unnecessarily growing your code repository. 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…

No one said committing to the code repo, deployment repos are a thing and if you're not revisioning your deployments then you are screwed anyway.

Re: I'm a fucking webmaster (2016)

#226

Back in the early 2000's, I taught "computers" to a bunch of kids in DC. I first started off with how a computer work; IO, CPU, storage and their eyes glazed over. 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 si…

Man, I loved the whole process of learning about IRQ's address spaces, I/O, North and South bridge, DMA...

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.

Re: I'm a fucking webmaster (2016)

#229

Earlier quoted context omitted.

No, that's fixing the problem in the wrong way (by using your code version tool as an FTP more or less), complicating code reviews and unnecessarily growing your code repository. 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…

No one said committing to the code repo, deployment repos are a thing and if you're not revisioning your deployments then you are screwed anyway.

> No one said committing to the code repo

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.

Post reply on HN