We are having an IE8 nightmare with RPC services returning list with (more or less) 60 objects with 5 properties each. Though modern browsers do the job, IE8 just isn’t responsive enough.
There is even an open issue about this.
We are planning to change RPC for services that need to send large lists of objects, but we want to change the minimum amount of code possible on both server and client.
First Question: Will JSON deserialization run faster on IE8 for this scenario?
We love the easy RPC service stuff. We have our CustomRemoteService implementation, our CustomAsyncCallback implementation, our CustomRPCException implementation and so on. RF is quite a big change for us.
Second Question: Would using an RPC service which return a single JSON string and then deserializing it client-side could do the job?
Or can you recommend another approach?
Thanks!
It should run faster, because IE8 supports native JSON parsing (and in IE6 and 7, you can use an
eval()which should still run faster than parsing the string by hand)But it highly depends what you do of the parsed objects: if you process it to reconstruct POJOs from it, you’ll probably lose all the JSON benefits; JS overlays on the other hand have zero overhead, but requires changing all your arrays or lists to
JsArrays for instance, and dates cannot be easily encoded in JSON, they need additional marshalling/unmarshalling.If your JSON processing is lighter-weight than RPC deserialization, then yes. Parsing the response on the client-side is a simple
eval()(yes, strangely it doesn’t use native JSON when available) and then lookups in the parsed object; what costs the most in RPC deserialization is to interpret the values to reconstruct objects; getting a string is just a lookup in an array, so it then depends what you do of that string later on.