Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please make your products work with URLs

anderspitman.net

Post reply on HN
Print view View original

311–320 of 353 posts

Re: Please make your products work with URLs

#311

Post by anderspitman »

danShumway wrote: post #270
anderspitman wrote: post #226

Earlier quoted context omitted.

> Even without adding a build step, would you be willing to add a tag to your index.html that just linked to the Github repo in general Absolutely! Should be working now (or as soon as CloudFlare cache is purged). Thanks for the snippet.

Thanks a ton! It's showing up perfectly on my end. As long as I know how to get to the text in some format, I'm usually fine with the rest, and markdown is a format that's very easy to read.

Even so, I'm going to put in some effort to make text-only a 1st-class citizen.

Re: Please make your products work with URLs

#313

Post by [deleted] »

egdod wrote: post #299
anderspitman wrote: post #246

Earlier quoted context omitted.

>> If you clone my blog[1] (with submodules) you should be able to host it exactly as-is from the repo. > Who would want to do that? Future me. Actually just today in order to publish this post I had to re-learn how I had set up my dependencies, so I switched it to submodules so it won't be a problem again. > However if you want to optimize for subsequent page loads I suggest you do so without compromising your initi…

Static HTML publishing is a solved problem. Don’t reinvent the wheel. Don’t make me run random JS to display plaintext. Don’t justify said random JS with silly whizbang features that no one actually wants.

[deleted]

Re: Please make your products work with URLs

#314

Post by crazygringo »

jschwartzi wrote: post #142
crazygringo wrote: post #100

I don't believe I've ever, once, in my entire history of browsing the internet, come across a direct hyperlink to a video file to play in the browser. Virtually universally, videos are embedded in webpages, and occasionally a link is provided that downloads rather than plays a video. So I think this is just a use-case issue: the average user is exceedingly unlikely to ever want to watch a raw video file specified by…

Before Youtube this was a thing, just as streaming radio was a thing before Pandora. You'd get a URL and the URL would stream radio or video instead of being a website. Obviously the protocol descriptor would be different from HTTP/HTTPS.

Oh sure, I remember RealPlayer used streams like rtsp:// and mms://. Man, takes me back.

But that all died out, it seems. So I get that history could have continued in that direction... but it didn't, I guess. It sure would have been interesting if it had, though.

Re: Please make your products work with URLs

#315

Post by zzo38computer »

egdod wrote: post #299
anderspitman wrote: post #246

Earlier quoted context omitted.

>> If you clone my blog[1] (with submodules) you should be able to host it exactly as-is from the repo. > Who would want to do that? Future me. Actually just today in order to publish this post I had to re-learn how I had set up my dependencies, so I switched it to submodules so it won't be a problem again. > However if you want to optimize for subsequent page loads I suggest you do so without compromising your initi…

Static HTML publishing is a solved problem. Don’t reinvent the wheel. Don’t make me run random JS to display plaintext. Don’t justify said random JS with silly whizbang features that no one actually wants.

It has been fixed so that there is a work around now. At first it was just blank, but now there is a work around. So, you can use that.

Re: Please make your products work with URLs

#316

Post by jefftk »

JohnFen wrote: post #262
jefftk wrote: post #157

Earlier quoted context omitted.

> I wonder if the authors of these badly engineered pages really know that they're excluding people People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. Being able to write a site in markdown with static hosting and have it instantly rendered in user's browsers is one of those things! If you choose to browse with IE6 and c…

> People who choose to turn off JS are excluding themselves. It goes both ways. Yes, turning off JS means that some sites will fail to work. As I said in my comment, I expect this. On the other hand, a well-designed site should fail gracefully, so that turning off JS won't make the site fail to work, but may make certain features unavailable. Sites that don't fail gracefully (with certain exceptions) are poorly engin…

> Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily.

Every time someone makes a site they're balancing a bunch of tradeoffs. For example, when I built https://trycontra.com I could have implemented the search server-side, with a query and response, but this would have involved writing active server side code. Instead I implemented the search entirely in client-side javascript. People are free to choose not to run the JS, but I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either.

> Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.

Downloading and executing binaries from random websites is far more risky than allowing JS. A binary runs as you can can trivially do anything you could do, from keylogging to subverting your browser. If you can do similar harmful things from JS, on the other hand, you're eligible for very large bounties from browser vendors. JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.

> That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.

HTML often fails gracefully, but not always. If someone writes a site that doesn't fail gracefully and so is completely unreadable in IE6, I don't think they've done anything wrong.

Re: Please make your products work with URLs

#317

Post by jefftk »

zeveb wrote: post #200
jefftk wrote: post #157

Earlier quoted context omitted.

> I wonder if the authors of these badly engineered pages really know that they're excluding people People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. Being able to write a site in markdown with static hosting and have it instantly rendered in user's browsers is one of those things! If you choose to browse with IE6 and c…

> People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy. JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requireme…

> JavaScript enables all sorts of attacks on one's security and privacy

Could you say more about this?

Re: Please make your products work with URLs

#318

Post by dredmorbius »

jefftk wrote: post #316
JohnFen wrote: post #262

Earlier quoted context omitted.

> People who choose to turn off JS are excluding themselves. It goes both ways. Yes, turning off JS means that some sites will fail to work. As I said in my comment, I expect this. On the other hand, a well-designed site should fail gracefully, so that turning off JS won't make the site fail to work, but may make certain features unavailable. Sites that don't fail gracefully (with certain exceptions) are poorly engin…

> Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily. Every time someone makes a site they're balancing a bunch of tradeoffs. For example, when I built https://trycontra.com I could have implemented the search server-side, with a query and response, but this would have involved writing active server side code. Instead I implemented the search…

JS search is not generally a critical site function.

Rendering the goddamned content is.

If you can't at a minimum give me a title, byline, dateline, main body text and/or some level of summary or description of non-textual content (as with graphics, audio, video, or interactive elements), then you're failing.

(SPAs or web applications should at least provide context for understanding what the application is/does. I'm not calling for all functionality to be rendered in HTML, but sufficient context to determine WTF the site is about.

Your "but I cannot implement search" is a strawman, and really doesn't address the core complaint.

As it stands, I'm looking at options for SSG-based blog posting, and at how it might be possible to support search. JS-based options, plus an extensive tagging / ontological classification, strike me as a reasonable compromise.

The fact that the Web is lacking a usable search-oriented standard which could bypass much of this problem, is one that's seldom noted. If sites could provide a permuted index in accessible format, and a standard mechanism for accessing it via a browser site-search function (or independent third-party search tools) ... well, the present online landscape would look remarkably different.

Sadly, we're not there, and the orientation of the leading browser developer is quite likely not going to support such development.

Re: Please make your products work with URLs

#319

Post by dredmorbius »

jefftk wrote: post #317
zeveb wrote: post #200

Earlier quoted context omitted.

> People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy. JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requireme…

> JavaScript enables all sorts of attacks on one's security and privacy Could you say more about this?

https://duckduckgo.com/?q=javascript+security+privacy+risks&...

Re: Please make your products work with URLs

#320

Post by causality0 »

satysin wrote: post #201
causality0 wrote: post #172

Earlier quoted context omitted.

I fear that soon we're going to need an open-source alternative to Plex. Increasingly aggressive monetization seems to be creeping into the Plex experience. I keep finding things I don't own and don't want showing up on my home screen. "Suggested movies" and "Suggested podcasts" and the like. You can prune them back but a few months later you find some other garbage you don't want.

This is a very valid complaint however I understand their need to monetise and at least you can remove that items. At least so far. I am always open to alternatives however with everything I have tried over the years nothing has come close to how well Plex works. From the flexibility of running the server to the superb automatic content identification to the frame perfect delivery to my TV it has been flawless for me…

Eh, it's gotten noticeably worse of late, almost as if their resources are going somewhere other than UX. The client as picked up a habit of hard-crashing on certain files when "Automatic" transcoding or "original" is selected instead of manually choosing a certain bitrate.
Post reply on HN