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

JSON Feed

jsonfeed.org

Post reply on HN
Print view View original

41–50 of 225 posts

Re: JSON Feed

#41

Post by anshou- »

mstade wrote: post #26

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please do…

It's worth pointing out that any valid JSON value is a valid JSON document. There is no requirement or guarantee that an array or an object are the top-level value in a JSON document.

"I am a valid JSON document. So is the Number below, and in fact every line below this line."

4

null

Re: JSON Feed

#42

Post by dangerlibrary »

moduspol wrote: post #36
mstade wrote: post #28

Earlier quoted context omitted.

If there was an `XML.parse` just like there's `JSON.parse`, I doubt you'd say the same. As it stands, the added complexity in JS-land is to import a library that provides this functionality for you. Fortunately there are many, but I agree a built-in would be nice. It's a bit of a shame that E4X never landed in JS.

It's more than JUST library support. It's also that JSON deserializes into common native data types naturally (dictionary, list, string, number, null). You can deserialize XML into the same data types, but it's not anywhere near as clean because of how extensible XML is. That's a big part of what's made JSON successful.

This is really only true in dynamically typed languages. From personal experience: parsing json in Java or Go without just treating everything as a bag of Object or an interface{} requires a ton of menial boilerplate work.

Super nice in python/ruby/javascript, though.

Re: JSON Feed

#43

Post by jonknee »

halloij wrote: post #17
jonknee wrote: post #8

Earlier quoted context omitted.

Probably this part: > simpler to read and write

If you're writing these things by hand, you're probably doing something wrong...

JSON is also easier for computers to read and write...

Re: JSON Feed

#44

Post by voidfiles »

CharlesW wrote: post #22
voidfiles wrote: post #6

This seems like a great idea. If it can help even one developer it's worth it.

How would it help even one developer? Or asked another way, what problem does this solve for you?

So, my personal blog doesn't get a ton of traffic, but the one article that gets the most traffic is an article about how to monkeypatch feedparser to not strip about embedded videos.

While not hard evidence, I think it's indicative of the kind of experience a developer has when they choose to engage with syndication.

Re: JSON Feed

#46

Post by halloij »

jonknee wrote: post #43
halloij wrote: post #17

Earlier quoted context omitted.

If you're writing these things by hand, you're probably doing something wrong...

JSON is also easier for computers to read and write...

XML generators and parsers have been in use for a decade+. Pretty sure most of the bugs have been found and fixed by now.

It's just reinventing the wheel because the new generation don't want to use the same tools the previous generation did. The time and effort spent doing this is quite ridiculous.

(FWIW, I hate XML, JSON is far better. But there's more important things to work on).

Re: JSON Feed

#47

Post by pfranz »

mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

Part of me is with you. But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON.

I think with something like feeds there's the possible benefit of becoming a 'hello world' for frameworks. Many frameworks have you write a simple blogging engine or twitter copycat. I don't think I've ever seen that for a feed reader/publisher. People have said that Twitter clients were an interesting playground for new UI concepts and paradigms because the basics were so simple (back when their API keys were less restrictive). Maybe this could be that?

Re: JSON Feed

#48

Post by ozten »

XML is aweful, but it does have CDATA, which lets you embed blog posts directly and it's easy to debug.

String encoded blog posts are going to be painful once people start using the `content_html` part of the spec.

Re: JSON Feed

#49

Post by gedrap »

But does it solve any actual problems other than 'XML is not cool', problems big enough to deserve a new format?

It's true that JSON is easier to deal with than XML. But that's relative, there are plenty of decent tools around RSS. From readers, to libraries in the most common programming languages, and extensions in the most common content management systems. JSON is slightly easier to read for human (although that's subjective), but then how often do you need to read the RSS feed manually, unless you are the one who is writing those libraries, etc. But that's a tiny share of all people using RSS.

>>> It reflects the lessons learned from our years of work reading and publishing feeds.

Sounds like the author(s) has extensive experience in this field and knows things better than some random person on the internet (me). But the homepage of the project doesn't convey those learned lessons.

Re: JSON Feed

#50

Post by aloisdg »

matthewaveryusa wrote: post #39
mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

Once you've peeked at the complexity of some of the xml parsers (like xerces, oh god xerces) undoubtedly you'll want to avoid it like the plague. xml can get crazy-bananas very quickly. I fundamentally don't understand xml (just like I don't understand asn1) for anything beyond historical purposes.

The Atom spec is really easy to grasp. Your platform may even include a way to deal with it ([.NET](https://msdn.microsoft.com/en-us/library/system.servicemodel... for example)
Post reply on HN