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…
I'm a fucking webmaster (2016)
221–229 of 229 posts
Re: I'm a fucking webmaster (2016)
#222Earlier 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...
Re: I'm a fucking webmaster (2016)
#223Earlier 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.
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)
#224Back 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…
Re: I'm a fucking webmaster (2016)
#225Earlier 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…
Re: I'm a fucking webmaster (2016)
#226Back 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…
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)
#227Re: I'm a fucking webmaster (2016)
#228Re: I'm a fucking webmaster (2016)
#229Earlier 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.
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.