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

91–100 of 225 posts

Re: JSON Feed

#91

Post by cdelsolar »

tveita wrote: post #87
dangerlibrary wrote: post #42

Earlier quoted context omitted.

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.

> 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. From my experience in Java it is pretty simple using a library like Jackson. You define the types you expect to read, maybe add some annotations, and then it's one function call to deserialize. IIRC Go has something similar in its json library.

Yes, it's arguably nicer in Go, because you specify exactly what types and field names you expect, and then it's just a simple json.Unmarshal

Re: JSON Feed

#92

Post by foxhill »

zeveb wrote: post #76

If we're going to talk about replacing XML with better data formats, why not switch to S-expressions? (feed (version https://jsonfeed.org/version/1) (title "My Example Feed") (home-page-url https://example.org) (feed-url https://example.org/feed.json) (items (item (id 2) (content-text "This is a second item.") (url https://example.org/second-item)) (item (id 1) (content-html " Hello, world! ") (url https://example.or…

beauty is in the eye of the beholder - i personally prefer the JSON.

Re: JSON Feed

#94

Post by sillysaurus3 »

hayleox wrote: post #88
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.

To be honest, I'm really excited about the prospect of JSON based feeds. Right now, there's no easy way to work with Atom/RSS feeds on the command-line (that I know of anyway), which is something I often wish I could do. With a JSON feed, I can just throw the data at jq ( https://stedolan.github.io/jq/ ) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.

Surely there's an xml->json converter somewhere.

Re: JSON Feed

#95

Post by efsavage »

jawns wrote: post #51

> It's at version 1, which may be the only version ever needed. Wow. Now that's confidence. Have you ever read the first version of a spec and thought, "That's just perfect. Any additional changes would just be a disappointment compared with the original"?

Unsurprising as this is clearly an ego play, given that the first thing they want you to know is their names.

Re: JSON Feed

#96

Post by falcolas »

hayleox wrote: post #88
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.

To be honest, I'm really excited about the prospect of JSON based feeds. Right now, there's no easy way to work with Atom/RSS feeds on the command-line (that I know of anyway), which is something I often wish I could do. With a JSON feed, I can just throw the data at jq ( https://stedolan.github.io/jq/ ) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.

I give you libxml:

    xmllint --xpath '//element/@attribute'
There's a good chance it's already installed on your mac.

Re: JSON Feed

#97

Post by mstade »

tghw wrote: post #81
mstade wrote: post #70

Earlier quoted context omitted.

You're right, thanks for the correction! Also kind of reinforces my point I feel. That any JSON document is just that, a JSON document; it doesn't carry more semantics just because you say so. My JSON parser will still just see simple JSON values, no matter how much I tell it that a certain key should really be a URL, not just a string.

True, but that's also true of any XML, RSS, Atom, HTML, etc. Websites abuse HTML all the time, and there's nothing saying that just because something is transferred with application/atom+xml that it will be valid or follow the spec. It's more of a social agreement. If you get a JSON object from a place you expect a JSON Feed and it has a title and items, then it'll probably work, even if it omits other things.

So we can ditch media types altogether then? What's the point of having actual contracts if all we need is a hand shake and a wink? We're not talking about malformed data here, that's something different entirely and yes – it happens all the time. We're talking about calling a spade a spade.

If it's JSON your program expects then I should be able to throw any valid JSON at your program and it should work. Granted, it probably won't be a very interesting program precisely because JSON is just generic data without any meaningful semantics.

This spec is entirely about attaching semantics to JSON documents, but all that gets lost when you forget to let people know the document carries semantics and just call it generic JSON. Maybe that doesn't matter to a JSON-feed specific app that thinks any JSON is JSON-feed (an equally egregious error) but if there's an expectation that I should be able to point my catch-all program (i.e. web browser) at a URL and it should magically (more like heuristically I guess, potato/tomato) determine that the document retrieved isn't in fact just any JSON then things are about to get real muddy. Web browsers aren't particularly social, so I suspect a social agreement probably won't work that well.

Media types aren't just something that someone thought was a nifty idea back in the dizzy, they are pretty important to how the web functions.

Re: JSON Feed

#98

Post by russellbeattie »

For anyone who's tried to write a real-world RSS feed reader, this format does little to solve the big problems the newsfeeds have:

* Badly formed XML? Check. There might be badly formed JSON, but I tend to think it'll be a lot less likely.

* Need to continually poll servers for updates? Miss. Without additions to enable pubsub, or dynamic queries, clients are forced to use HTTP headers to check last updates, then do a delta on the entire feed if there is new or updated content. Also, if you missed 10 updates, and the feed only contains the last 5 items, then you lose information. This is the nature of a document-centric feed meant to be served as a static file. But it's 2017 now, and it's incredibly rare that a feed isn't created dynamically. A new feed spec should incorporate that reality.

* Complete understanding of modern content types besides blog posts? Miss. The last time I went through a huge list of feeds for testing, I found there were over 50 commonly used namespaces and over 300 unique fields used. RSS is used for everything from search results to Twitter posts to Podcasts... It's hard to describe all the different forms of data it can be contain. The reason for this is because the original RSS spec was so minimal (there's like 5 required fields) so everything else has just been bolted on. JSONFeed makes this same mistake.

* An understanding that separate but equal isn't equal. Miss. The thing that http://activitystrea.ms got right was the realization that copying content into a feed just ends up diluting the original content formatting, so instead it just contains metadata and points to the original source URL rather than trying to contain it. If JSONFeed wanted to really create a successor to RSS, it would spec out how to send along formatting information along with the data. It's not impossible - look at what Google did with AMP: They specified a subset of formatting options so that each article can still contain a unique design, but limited the options to increase efficiency and limit bugs/chaos.

This stuff is just off the top of my head. If you're going to make a new feed format in 2017, I'm sorry but copying what came before it and throwing it into JSON just isn't enough.

Re: JSON Feed

#99

Post by JoelSanchez »

zeveb wrote: post #76

If we're going to talk about replacing XML with better data formats, why not switch to S-expressions? (feed (version https://jsonfeed.org/version/1) (title "My Example Feed") (home-page-url https://example.org) (feed-url https://example.org/feed.json) (items (item (id 2) (content-text "This is a second item.") (url https://example.org/second-item)) (item (id 1) (content-html " Hello, world! ") (url https://example.or…

There's EDN, which is to Clojure what JSON is to JS: a format close to the language's way of representing data.

https://github.com/edn-format/edn

Example:

https://github.com/milikicn/activity-stream-example/blob/4db...

Not S-expression-based, though.

Re: JSON Feed

#100

Post by smilbandit »

frou_dh wrote: post #62
nilved wrote: post #14

Good lord, Web people, stop it. You are embarrassing yourselves. We already have standards and you need to stop recreating everything in JavaScript.

Brent Simmons is hardly some webdev kid barging it. He was the original developer of NetNewsWire, a very popular/influential feed reader application which is now 15(!) years old.

thanks, knew I recognized the name
Post reply on HN