Live data from Hacker News

30 years of tags

artmann.co

21–30 of 103 posts

Re: 30 years of <br> tags

#21

> Every page on your site needed the same header, the same navigation, the same footer. But there was no way to share these elements. No includes, no components. That's not completely true. Webservers have Server Side Includes (SSI) [0]. Also if you don't want to rely on that, 'cat header body > file' isn't really that hard. [0] https://web.archive.org/web/19970303194503/http://hoohoo.ncs...

I think they meant that from a vanilla HTML standpoint

HTML frames let you do this way back in the day

Re: 30 years of <br> tags

#22

Earlier quoted context omitted.

I think they meant that from a vanilla HTML standpoint

HTML frames let you do this way back in the day

The article mentions that in the very next sentence

> You either copied and pasted your header into every single HTML file (and god help you if you needed to change it), or you used to embed shared elements. Neither option was great.

Re: 30 years of <br> tags

#23

> Every page on your site needed the same header, the same navigation, the same footer. But there was no way to share these elements. No includes, no components. That's not completely true. Webservers have Server Side Includes (SSI) [0]. Also if you don't want to rely on that, 'cat header body > file' isn't really that hard. [0] https://web.archive.org/web/19970303194503/http://hoohoo.ncs...

I think they meant that from a vanilla HTML standpoint

Sure, but later in the article it says that when PHP came out it solved the problem of not being able to do includes. Which again... server-side includes predate PHP. I think that this is just an error in the article any way you slice it. I assume it was just an oversight, as the author has been around long enough that he almost certainly knows about SSI.

Re: 30 years of <br> tags

#24
"Virtual private servers changed this. You could spin up a server in minutes, resize it on demand, and throw it away when you were done. DigitalOcean launched in 2011 ..."

The first VPS provider, circa fall of 2001, was "JohnCompanies" handing out FreeBSD jails advertised on metafilter (and later, kuro5hin).

These VPS customers needed backup. They wanted the backup to be in a different location. They preferred to use rsync.

Four years later I registered the domain "rsync.net"[1].

[1] I asked permission of rsync/samba authors.

Re: 30 years of <br> tags

#25
post #9

Earlier quoted context omitted.

Good showcase. Your code will match the first parameter that has as a suffix, no necessarily exactly (username=blag&name=blub will return blag). It also doesn't handle any percent encoding.

> Your code will match the first parameter that has as a suffix, no necessarily exactly Depending on your requirements, that might be a feature. > It also doesn't handle any percent encoding. This does literal matches, so yes you would need to pass the param already percent encoded. This is a trade off I did, not for that case, but for similar issues. I don't like non-ASCII in my source code, so I would want to encod…

Ampersands are ASCII, but also need to be encoded to be in a parameter value.

Re: 30 years of <br> tags

#27

Earlier quoted context omitted.

HTML frames let you do this way back in the day

The article mentions that in the very next sentence > You either copied and pasted your header into every single HTML file (and god help you if you needed to change it), or you used to embed shared elements. Neither option was great.

I’m talking about the frameset and frame tags, not iframes.

Re: 30 years of <br> tags

#28

> For that, you needed CGI scripts, which meant learning Perl or C. I tried learning C to write CGI scripts. It was too hard. Hundreds of lines just to grab a query parameter from a URL. The barrier to dynamic content was brutal. That's folk wisdom, but is it actually true? "Hundreds of lines just to grab a query parameter from a URL." /*@null@*/ /*@only@*/ char * get_param (const char * param) { const char * query =…

> HTML represents a tree and string interpolation is the wrong tool to generate a tree description. Yet 30 years later it feels like string interpolation is the most common tool. It probably isn't, but still surprisingly common.

Which is really sad. This is the actual reason why I preferred C over Python[*] for that project, so I could use my own library for HTML generation, which does exactly that. It also ameliorates the `goto cleanup;` thing, since now you can just tell the library to throw subtrees away. And the best thing is, that you can MOVE, and COPY them, which means you can generate code once and then fill it with the data and still later modify it. This means you can also refer to earlier generated values to generate something else, without needing to store everything twice or reparse your own output.

[*] I mean yeah, I could have written a wrapper, but that would have taken far more time.

Re: 30 years of <br> tags

#29

Earlier quoted context omitted.

> Your code will match the first parameter that has as a suffix, no necessarily exactly Depending on your requirements, that might be a feature. > It also doesn't handle any percent encoding. This does literal matches, so yes you would need to pass the param already percent encoded. This is a trade off I did, not for that case, but for similar issues. I don't like non-ASCII in my source code, so I would want to encod…

Ampersands are ASCII, but also need to be encoded to be in a parameter value.

Yeah, but you can totally choose to not allow that in your software.

Re: 30 years of <br> tags

#30
post #17
post #9

Earlier quoted context omitted.

Good showcase. Your code will match the first parameter that has as a suffix, no necessarily exactly (username=blag&name=blub will return blag). It also doesn't handle any percent encoding.

Further, when retrieving multiple parameters, you have a Shlemiel-the-painter algorithm. https://www.joelonsoftware.com/2001/12/11/back-to-basics/

Thanks, good author. I also like to read him. Honestly not parsing the whole query string at once feels kind of dumb. To quote myself:

> In practice you would probably parse all parameters at once and maybe use a library.

Post reply on HN