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

Better Than JSON?

wiki.alopex.li

Post reply on HN
Print view View original

141–150 of 153 posts

Re: Better Than JSON?

#141

Post by beardyw »

generalk wrote: post #28

On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not sure it’s something anyone > actually wants to use, it’s just going to be one more of > those mistakes of the past. Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes,…

I was asked by a company to sort out complaints which were coming from recipients of their XML. The big win was doing validation against the schema on the outgoing XML!

Re: Better Than JSON?

#142

Post by rurban »

I miss the security category.

All of the mentioned formats are now insecure by default, because they deserialize objects. (Just msgpack not, which has other problems). Even JSON, the most secure format originally became insecure in its 1st update. All the binary JSON variants, like BSON went bonkers.

Re: Better Than JSON?

#143

Post by petre »

bryanlarsen wrote: post #136
petre wrote: post #133

Earlier quoted context omitted.

You need to parse that. For graphs with thousands of data points just use Unix time plus a timezone or use the browser's timezone. ISO 8601 would leave your graphs churning for seconds.

If parse time is a significant concern, why are you using JSON?

Because we feed the data to Js. No need for additional overhead parsing string based timestamps. Unix epoch is just an int. We don't need pre 1970 timestamps.

Re: Better Than JSON?

#144

Post by RedShift1 »

petre wrote: post #143
bryanlarsen wrote: post #136

Earlier quoted context omitted.

If parse time is a significant concern, why are you using JSON?

Because we feed the data to Js. No need for additional overhead parsing string based timestamps. Unix epoch is just an int. We don't need pre 1970 timestamps.

Pre-1970 timestamps work too:

  Welcome to Node.js v12.18.4.
  Type ".help" for more information.
  > new Date(-10000)
  1969-12-31T23:59:50.000Z

Re: Better Than JSON?

#145

Post by nt2h9uh238h »

I also hate XML, but there's actually one very fair use, where I'm really struggling with all other formats: User Interface Descriptions. HTML, Apple iOS (XCode), Windows Phone (XAML), and even Android XML (virtually all android apps) copied it for that exact reason, even though they could have started from scratch.

Re: Better Than JSON?

#146

Post by eska »

vollmond wrote: post #25
dragontamer wrote: post #16

Earlier quoted context omitted.

The issue with XML is that it was mostly pushed upon developers without any deeper understanding. So there's a ton of utterly crap XML applications out there with no rhyme or reason, and these crap XML enterprise apps are most developer's understanding of "real world XML". Similar to how terrible C++ code being all over the place is making people hate C++ the language. ------- XML can be used very well however: its u…

Around 2009, I worked on an application whose web interface and API were the same url -- it was served as an XML data file, with an XSLT transform to make it pretty for the browser. It was so comfortable.

I really like the separation between the semantic content and the visualization there. HTML/JS/CSS throw everything together instead. But XSLT is nothing I want to have to work with..

Re: Better Than JSON?

#147

Post by Inufu »

petre wrote: post #143
bryanlarsen wrote: post #136

Earlier quoted context omitted.

If parse time is a significant concern, why are you using JSON?

Because we feed the data to Js. No need for additional overhead parsing string based timestamps. Unix epoch is just an int. We don't need pre 1970 timestamps.

JavaScript can parse binary serialised protobufs.

Re: Better Than JSON?

#148

Post by petre »

Inufu wrote: post #147
petre wrote: post #143

Earlier quoted context omitted.

Because we feed the data to Js. No need for additional overhead parsing string based timestamps. Unix epoch is just an int. We don't need pre 1970 timestamps.

JavaScript can parse binary serialised protobufs.

Yup with external libs. JSON.parse is builtin. We do the renderin in browser so why bother with protobuf.

Re: Better Than JSON?

#149

Post by jrochkind1 »

andreareina wrote: post #128
jrochkind1 wrote: post #40

There are a bunch more possible entries in the human-readable category, one of the more popular contenders is TOML. https://github.com/toml-lang/toml . There are more. I don't know if java dot-properties file is worth including.

The speaks to the context of serialization formats, which TOML isn't.

Hm. Would you call YAML a "serialization format" but not TOML? I'm not sure where to draw the lines of what is a "serialization format" (you can serialize to both yaml and toml, no?) but YAML and TOML feel to me like they are in the same space, human-readable representations of hash/array json-like data, ie serializations; not to you?

Re: Better Than JSON?

#150

Post by SAI_Peregrinus »

cbsmith wrote: post #121
fanf2 wrote: post #110

Earlier quoted context omitted.

I guess the ARM instruction you are thinking of is FJCVTZS, which implements the special ToInt32 operation required by JavaScript. https://stackoverflow.com/questions/50966676/why-do-arm-chip... It is nothing to do with JSON.

You think an instruction with Javascript in the name, that converts JavaScript floating-point to signed fixed-point, rounding towards zero, isn't used when parsing JSON?

It is, but oddly enough Javascript numbers and JSON numbers are different and mutually incompatible. JS allows ±INF and the NANs, since it uses IEEE754 double-precision floating point. JSON doesn't, and technically allows arbitrary precision floating point (though implementations are allowed to define truncation behavior to a format at least as large as an IEEE754 double).
Post reply on HN