Show HN: This website is valid JSON • Hacker News Board

Re: Show HN: This website is valid JSON

#231

Post by spondyl » Wed, Dec 09, 2020, 8:11 PM UTC

vlovich123 wrote: post #28

spondyl wrote: 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…

I’ve generally saved my HTML resume to PDF without any major issues as a professional SWE for the past ~15 years or so, although I’ve been dealing primarily with SV tech companies and not government agencies in the UK. Microsoft Word is fine too but I would still use something like PDF for export and sharing (still not sure how Microsoft Word solves the usb problem for you). Generally though I like something text-lik…

Pandoc can even generate Word docs?! Well dang

Re: Show HN: This website is valid JSON

#232

Post by gpnt » Wed, Dec 09, 2020, 8:17 PM UTC

93po wrote: post #221

whoomp12342 wrote: post #198

Earlier quoted context omitted.

a huge advantage is that you could begin webdesign anew without all the baggage from old html standards

I would love an internet that provides content as JSON in a consistent format. No longer are we restricted to the often awful UI and UX choices and unnecessary stylistic overhauls that make everything more difficult to access. No more pop up banners. No scroll jacking. It sounds like bliss.

This is the exact motivation of the project. One of the next steps is to provide a global user preference to signal the render. One step at a time.

Re: Show HN: This website is valid JSON

#233

Post by gpnt » Wed, Dec 09, 2020, 8:56 PM UTC

rognjen wrote: post #148

Very interesting. My immediate thought for a use case is to debug APIs. Pass in a param that adds this to the response and get it in a more human readable form. Will test it out.

Embed the initiator that could be as complex as you like to make senses on-the-fly to the JSON. Very cool!

Re: Show HN: This website is valid JSON

#234

Post by gpnt » Wed, Dec 09, 2020, 9:02 PM UTC

nkjoep wrote: post #159

It doesn't work on my Chrome 87.0.4280.88 MacOS. It works on Safari though.

This is odd. This is my version and OS too. What error is showing to you?

Re: Show HN: This website is valid JSON

#235

Post by TheKarateKid » Wed, Dec 09, 2020, 11:46 PM UTC

chrismorgan wrote: post #226

TheKarateKid wrote: post #217

Earlier quoted context omitted.

> 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. Would you say the same about taking a browser -- which was designed to be a document viewer for researchers -- and turning it into an entire application execution platform like we have now? Point is: It's silly to say things like this, because this is how innova…

No, please read my other comments here—the point is that this thing doesn’t solve anything, but introduces various problems. The only tenuous claim it can have is that the document is JSON, so if you want to parse the data, maybe you’ll find it easier? But in practice this is not useful: you can already embed or link to a JSON representation in the HTML, and that JSON representation then won’t be constrained by havin…

It solves the problem of having to use multiple languages across front/back-end by using Javascript/JSON for everything. It may seem as ridiculous as using Javascript to write back-end server-side and desktop software, yet along came Node and industry hype and here we are today doing exactly that.

Re: Show HN: This website is valid JSON

#236

Post by TheKarateKid » Wed, Dec 09, 2020, 11:48 PM UTC

svachalek wrote: post #223

TheKarateKid wrote: post #217

Earlier quoted context omitted.

> 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. Would you say the same about taking a browser -- which was designed to be a document viewer for researchers -- and turning it into an entire application execution platform like we have now? Point is: It's silly to say things like this, because this is how innova…

You know, if we could just go back and make that un-happen, we probably would have built an actual internet application platform. That probably would have been a lot better than the layers of hackery that we deal with now, but ok, that's pure speculation.

Perhaps, but that doesn't mean it would be better.

Look at how many over-engineered platforms/frameworks Microsoft made, and it just ended up being over-complicated or reached a point where it was no longer worth continuing.

Re: Show HN: This website is valid JSON

#237

Post by Ayesh » Thu, Dec 10, 2020, 2:09 AM UTC

chrismorgan wrote: post #121

greggman3 wrote: post #63

Earlier quoted context omitted.

You are correct. It's a silly hack. Just because it happens to work doesn't make it a good idea. Turn off JavaScript and you just get JSON text.

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.

About the blog platform, I honestly thought the author was being sarcastic or joking when they out it there.

It is not even vid JSON response to begin with (it's served with text/html), and if the fetcher is configured to ignore that, you might as well configure the origin server to serve the JSON response based on the accept header.

Re: Show HN: This website is valid JSON

#238

Post by pjgalbraith » Thu, Dec 10, 2020, 2:16 AM UTC

mstade wrote: post #105

pjgalbraith wrote: post #50

Earlier quoted context omitted.

In regards to the character encoding issue, I wonder if they could just move the #render to the top of the object by inserting it as the first property.

I'm guessing there might be issues with the streaming nature of html parsers then. If you put it at the top and the JSON is of any non-trivial size you might end up with the script trying to read invalid JSON since it's not fully loaded yet.

They could just add the "defer" attribute on the script tag to prevent that.

Re: Show HN: This website is valid JSON

#239

Post by SrslyJosh » Thu, Dec 10, 2020, 3:11 AM UTC

Relying on the order of keys in an object seems like a bad idea.

Re: Show HN: This website is valid JSON

#240

Post by chrismorgan » Thu, Dec 10, 2020, 7:31 AM UTC

TheKarateKid wrote: post #235

chrismorgan wrote: post #226

Earlier quoted context omitted.

No, please read my other comments here—the point is that this thing doesn’t solve anything, but introduces various problems. The only tenuous claim it can have is that the document is JSON, so if you want to parse the data, maybe you’ll find it easier? But in practice this is not useful: you can already embed or link to a JSON representation in the HTML, and that JSON representation then won’t be constrained by havin…

It solves the problem of having to use multiple languages across front/back-end by using Javascript/JSON for everything. It may seem as ridiculous as using Javascript to write back-end server-side and desktop software, yet along came Node and industry hype and here we are today doing exactly that.

As I’ve said, I have no objection to using this sort of JSON as an input format, but I do object to deploying in this format.