prob never
Hmm I'm trying to suggest ideas
Why not use GitHub - Stuk/jszip: Create, read and edit .zip files with Javascript
JSZip is not that hard is it?
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
hmmmm
you don't know that.
i dont
That why I said
Jeez, you guys, I am so tempted to establish a rule that every day I wake up to a flag war we turn the whole forum off for a day.
Luckily for you, collective punishment is officially (UN) a Crime Against Humanity.
@programmer_user, @helicoptur: coder2195snap has the habit of overstating his case, like a lot of y'all (so tempting to name names here (I don't mean either of you two)) but he's trying to be helpful. Compressing projects on the cloud is a good idea, although I have the vague impression that virtual computers (such as the Snap! cloud) are already stored compressed. But we are talking about moving to storing media separate from project code, so that we don't need a zillion copies of alonzo.png on the server. That would eliminate the need to include code and media in one zip archive.
@coder2195snap: Jens has repeatedly explained that the reason for using Morphic, our own widget manager, is that it supports lively code (the ability to modify a script while it's running and see the result immediately) much better than DOM elements would. I think it would be an interesting research project to find out how much our users actually do that. We know that there's a big cost to that choice; we have had to reinvent things like text entry and (not done yet) support for screenreaders. But we're unlikely to change that, which would mean a(nother) complete rewrite of Snap!.
As it is, Jens did do a major rewrite recently to use a separate canvas for each widget rather than just one big canvas for the whole window. That led to a significant speedup.
wdym by that
And how about use JSON instead of XML
Well I'm not overstating I'm suggesting
Plus I think JSON+ZIP is a better way of compressing than XML
JSON doesn't help with compression.
SOME STUFF ABOUT JSON VS XML
FIRST THING:
JSON is faster because it is designed specifically for data interchange. JSON encoding is terse, which requires less bytes for transit. JSON parsers are less complex, which requires less processing time and memory overhead. XML is slower, because it is designed for a lot more than just data interchange.
Don't cha think if would be better if XML projects moved over to JSON?
(Emphasis added)
Really it's only the JSZip one that's offensive.
That's an apples and oranges comparison. Zip is about compression; JSON is about preserving structure when serializing. You'd have to compare JSON with XML, or JSON+Zip with XML+Zip.
And we do a lot more than data interchange. Deserialization is like writing a compiler for a special-purpose language. Most of those articles Google found for you are thinking about a simple database with fixed-format records, so size is the only real criterion.
Of course JSON would be smaller, only by virtue of using brackets instead of end tags: [TAG: foo bar bletch] instead of <TAG>foo bar bletch</TAG>. One possible virtue of the XML approach is that it makes it easier to fix file corruption because of the redundancy; a missing end tag will cause a mismatch when the next end tag is seen, whereas a missing ] could be anywhere.
Having said all that, we've gone back and forth on how to do serialization over the years. I think I'm remembering correctly that in the BYOB days we rewrote the serializer and deserializer at least once to switch formats. So your suggestion isn't stupid; there would indeed be some real advantages to JSON. But there are also real advantages to XML, so it's not an obvious choice.
But why are assets included in xml
Why can’t they be a separate file in a zip?
Yes, absolutely. If you look back at my post in a different thread about which you said "prob never," you'll see that it's about separating media from code so that we only need one copy of each costume or sound on the server.
I think y'all don't get that we're all frantically busy putting out fires. Right now, as discussed in another thread, the biggest fire we're working on is that school districts won't let teachers use Snap! unless we sign contracts making a bunch of promises about student privacy and about data security. So, yeah, saving some server space, while also important, is on the back burner.
Ooof 
Hmmm but what is so unprivate about puts assets on an seperate area inside zip file
What? No. I'm not trying to make a connection between privacy and your suggestion, except the connection that we can't do everything at once.
Could you explain what you mean
Did you mean that you have too many contracts to sign so you cant change snap zip xml thingy??