Live data from Hacker News

Show HN: This website is valid JSON

webdatarender.com

201–210 of 240 posts

Re: Show HN: This website is valid JSON

#201

Earlier quoted context omitted.

It's kind of the author's problem and not ours. If they want to figure out how to make a quirks-mode page work correctly, be my guest. It will just be unnecessarily painful.

Quirks mode is not the only problem of this approach. It may not significantly affect users of modern browsers in their default configuration with good internet connections, but it does affect plenty of other things. You want to parse things in the document? Now you need a whole different suite of tools from the usual tools you use. Your library that parses all the meta tags, identifies the content, &c. is now useles…

> You want to parse things in the document? Now you need a whole different suite of tools from the usual tools you use. Your library that parses all the meta tags, identifies the content, &c. is now useless.

They're no less useless than for SPA's that render their content in JS. That's all this site is. If your web scraping suite can't handle content loaded from JS then you're already locked out of most of the web.

Same if you disable JS. Most of the web will be broken for you and it takes an annoying amount of effort enable the minimum necessary scripts.

Re: Show HN: This website is valid JSON

#204
post #25

You know, I once had a resume powered by JSON. It was rendered to a PDF (and HTML) but the syntax was backed by JSON. This was years back and I shudder to even recall the idea. I didn't create the project mind you, it was some NPM package back when I was a fresh 'un who didn't have thoughts on using a billion subdependencies Anyway, I was nearly broke and when I went to apply for the benefit, I was asked for my resum…

My resume is an XML document and a stylesheet I feed to Prince (https://www.princexml.com/), which is an amazing piece of software. I also used it once to generate a book I had printed by some on-demand printing company. I got great output out of it.

Re: Show HN: This website is valid JSON

#205
post #76
post #24

Earlier quoted context omitted.

This makes a lot of sense and I agree with this need! I want to throw in a healthy dose of skepticism about whether your solution can address that need -- only because I hope that hearing it early can increase your chances of success! I think a hard problem ahead would be how to convince other people to also adopt this framework, and how to make sure that people are using the same JSON keys to mean the same thing. I'…

>I think a hard problem ahead would be how to convince other people to also adopt this framework, and how to make sure that people are using the same JSON keys to mean the same thing. At first, I was thinking to use some kind of general schema, but those things never work. So I decided something much simpler: the render determines the schema. This is an important aspect that I am working on. If you choose some specif…

Honestly, I think letting people include their own code is good, people will always want to do things that you couldn't have imagined yet, and for their own good reasons.

However, you need to make sure the platform can eventually catch up with the de-facto standards people are coming up with, so that people don't keep having to keep on re-inventing these wheels. As a comparison, see how JavaScript features evolved from jQuery and Underscore features.

> But I think the mindset is to stop thinking the website for just the browser.

I agree. I'd suggest that you think through how you can convince people to stop thinking about the website as just for the browser.

In the last decade, many people might have thought that the rise of the mobile web would made web developers separate presentation from content. But instead of using the same HTML with different stylesheets, what actually happened is every major website started maintaining two completely separate websites, one for web and one for mobile! I'd recommend thinking about why this happened, to make sure your framework doesn't nudge people down the same route.

Again, wishing you success!

Re: Show HN: This website is valid JSON

#206

Earlier quoted context omitted.

If only XML wasn't so damn complicated , it might have had a chance. People love to point at close tags, but there's a long list of more serious problems. External entities, namespaces within namespaces, CDATA, namespaces that confusingly look exactly like URLs, but aren't, parser vulnerabilities.

The way XML does namespaces is one of the best things about it - you can host any XML dialect within another, with no name clashes, and without losing the schema identity of embedded parts. Infinite data composability, subject only to the constraints placed by schema authors. And namespaces are URIs, so they can be URLs. The bad smell was mostly coming from all the things inherited from SGML - CDATA, entities etc. Al…

I don't see why you even need the concept of namespaces to do that.

In my schema, I have a element, whose contents is defined to be a foreign document.

Re: Show HN: This website is valid JSON

#207
IE11 doesn't render anything. Console errors:

HTML1527: DOCTYPE expected. Consider adding a valid HTML5 doctype: "". webdatarender.com (2,0)

HTML1513: Extra "" tag found. Only one "" tag should exist per document. webdatarender.com (86,15)

SCRIPT1002: Syntax error render-basic-1.0.3.js (1,4)

HTML1506: Unexpected token. webdatarender.com (86,104)

Re: Show HN: This website is valid JSON

#208

Earlier quoted context omitted.

The page says: > I'm creating a blog platform using this concept. Yeah, please don’t; this is an abomination that’s fun for demonstrating and teaching how these things work, but should absolutely never be used in reality. You could use this as your data model foundation upon which to build a generator , but you should never under any circumstances actually serve this stuff.

This is such a depressing comment. It's the opposite of the hacker spirit. The web has made it easier than ever to discourage people from trying anything new. New ideas seem like bad ideas, because otherwise people would be doing them. One could imagine your objection applying to React: "What a horrible idea. It's a nice hack, but under no circumstances should you actually build webpages like this. Webpages are built…

You're both right. Suggesting other people try your blog built on this platform is giving people bad advice, and the comment you're replying to is overly negative.

I think the thing that's annoying is trying to sell other people on using such a tool. Anyone crazy enough to try it should jump right in, but don't try to talk people into it as an actual good blog option.

I call this sort of project "linux on a wristwatch." It's totally cool and a fun hack, but there's no real utility to it beyond an art piece.

Re: Show HN: This website is valid JSON

#209

Earlier quoted context omitted.

I’m going to double down here. React and its ilk were designed for use in apps , where there are meaningful advantages in powering things entirely with client-side scripting rather than generating server-side HTML and possibly enhancing it on the client side with scripting. They were then abused by increasingly many people for rendering static content, things like blogs. These people were using the wrong tool for the…

Look. We're on a Show HN. You call his work a monstrosity with no benefits for the user. You call it an abomination. When you've used up all your insults, what's left? What are you going to call something deserving of hate? It's so petty and bitter, and you need to go have fun with something. Go play! As for your React commentary, it's 4:42am my friend, and I was just sad to see someone take such a hot steamy dump on…

I’m specifically objecting because of the text “I'm creating a blog platform using this concept” and what else the author is saying here. As a technical demonstration, it’s fine—various people don’t realise you can do things like this, and I’m all in favour of showing people these sorts of things, as it does get people thinking in interesting ways. But the author seems to think that this is a good idea, which I’m afraid it’s just not, so I can’t mince words—though perhaps I have expressed myself a bit more strongly than is seemly (thank you for pulling me up on that).

Of React (and its ilk: React was by no means the first project along these lines; as an example, I can think of having hit a couple of full JS-required Knockout sites well before React was a thing, where they would have been better as prerendered HTML), I’m not saying that history was rewritten to say it had a place from the beginning, but rather that there was a place for it from the beginning: that there is a certain type of app where there are very substantial benefits for the user in doing at least some parts on the client side (that was where the jQuery style of progressive enhancement started, and then things like Backbone steadily expanded it), and then that architecturally there are substantial benefits to going all in on client-side rendering if you need this sort of enhancement (this was what Knockout tended towards, and what ExtJS and React more fully realised)—but that this had costs, too, in that it broke the traditional model, making life harder for all kinds of tooling and making pages heavier, so that it shouldn’t be used everywhere.

React was not initially intended as a way to write web sites, but rather web apps. It’s an important distinction. For apps like Facebook and Twitter, the advantages of server-side rendering were not so applicable, and the benefits of full client-side rendering more marked. Unfortunately, the SPA craze grew further, and people liked using one tool everywhere, and so it became more and more common to use React in places where it was inappropriate at the time; until finally tooling like search engines caved on the whole JavaScript thing.

I still don’t like how often I find normal websites depending on JavaScript for fundamental rendering (it may not surprise you to discover that I browse with JavaScript disabled by default—mostly for performance and minimisation of annoyances), but at least React has purpose and some advantages, and has done from the start.

Meanwhile, this thing here doesn’t get you any of the benefits of client-side rendering (things like lighter and faster subsequent page loads and transitions, by using AJAX and semantic knowledge), but does carry all of the costs of client-side rendering: poorer performance, and making life harder for tooling of all kinds.

Re: Show HN: This website is valid JSON

#210
post #189

Earlier quoted context omitted.

This is such a depressing comment. It's the opposite of the hacker spirit. The web has made it easier than ever to discourage people from trying anything new. New ideas seem like bad ideas, because otherwise people would be doing them. One could imagine your objection applying to React: "What a horrible idea. It's a nice hack, but under no circumstances should you actually build webpages like this. Webpages are built…

This is just a bad idea. Apart from abusing browser rendering quirks (which is unfortunately a sad tradition of the web, something that has claimed the life of entire technology stacks like xml/xhtml), it removes any hope of producing webpages accessible from screen readers and similar. In comparison, JS-only pages look like model citizens. This is the equivalent of abusing IE hot-comments and other CSS-parsing bugs…

Heh, now I have to defend this thing!

So long as the JavaScript executes, this doesn’t actually harm accessibility: as it loads, it slurps the JSON, and turns it into a perfectly normal web page; rather like XSLT, as others have pointed out. And quirks mode isn’t that serious a problem. It’s a mild nuisance at most, really.

But I do agree with your last sentence.

Post reply on HN