datalist

Originally, mostly for ideological reasons and because people simply followed the anti-Microsoft trend. Technologically, IE was not a bad browser when it was released and had quite a few advantages over Navigator/Communicator.

Of course, when Microsoft decided to abandon the whole thing and the competition (i.e. Mozilla) continued working on it, IE slowly lost these advantages.

So, down the line there were certainly also technological reasons why people were not too fond of it, but most of the dislike originated from said anti-Microsoft ideology. Of course, we are speaking here about 20ish years ago.

Coincidences or not, why should it suggest a simulation? That seems somewhat unrelated.

PHP does come with an incredible amount of functionality out of the box. Though that does not mean one may never have to intgrate a library.

That being said, the dependency insanity which became commonplace with JavaScript becoming more accepted as backend language is a different story of course.

Was it left-pad? :)

editplus.com

What about standard permissions? The user is never prompted for them.

Thanks for the response, appreciated. I am afraid I can hardly post it again for obvious reasons :)

However there is a screenshot - https://ibb.co/K7JDsZ4

True.

> But the US has said it will not pressure Ukraine to negotiate and has even discouraged it from negotiating. State Department spokesperson Ned Price seemed to suggest that Ukraine continue to fight and Ukrainians continue to die rather than ending the war by negotiating

Available at

* https://odysee.com/@RT:fd

* https://rumble.com/c/RTNews

Maps and Earth were not in-house built but purchased.

That posting is proof of the old saying

Don't do drugs, kids

That's not the point though.

The question really only is whether the allegations have mentioned merit or not. If the situation was reversed it would be the same of course.

Difficult to tell if sarcasm or not ;)

This domain appears to have used these two bizprime servers for almost two years, however they only return a generic IP address which most likely serves that "for sale" page.

Currently, however, the domain does not point to these nameservers but to ns3.aqadvisor.com and ns4.aqadvisor.com instead. DNS glue appears to be present for these two servers, however they themselves do not consider themselves authoritative for the domain (and don't return their own names) but only refer to bizprime again.

The whole DNS setup is somewhat broken and needs fixing by the site owner.

Well, jQuery has the hashes on-site.

To be honest, I am not sure what should be wrong with adding code by hand.

Libraries were added manually by legions of developers long before one thought he'd need to create a downloadable left-pad "package".

The whole package management issue is overrated.

That not, hence "not exactly" but SRI still is nice add-on.

Though after that point even your own code cannot use that permission anymore.

While not exactly what you are asking, SRI does address that issue to a certain extent

https://medium.com/binary-passion/gentlemen-please-fasten-yo...

I recently migrated a personal project to a newer version of a library it is using and that version dropped its jQuery requirement. In that process I also rewrote my own code using jQuery and moved to vanilla JavaScript.

A lot, that required or semi-required jQuery before can now be done with vanilla JavaScript, however jQuery is still going strong with invoking code on sets of elements as well as cascading calls.

jQuery has been a fantastic library and deserves all the praise, however a lot of its functionality has made it by now into the language itself.

To answer your direct questions, I couldnt think of any "issues", at worst you download an additional 30 kilobytes (gzipped) but with today's mentality of megabytes and megabytes for websites, that really shouldnt matter much. As for advantages, as mentioned, JavaScript did take over a lot of functionality, but as direct advantages I'd consider aforementioned features. Additionally, there certainly is also still a lot of libraries/plugins which depend on jQuery.

It is not even a CNAME. It is a JavaScript redirect based on the the response of an HTTP request to Wikipedia.

I am afraid, as jackcviers3 already said, you are missing the point.

The goal of making applications is to have a piece of software at the end. That piece of software is the solution to the problem you have.

Actually, in that very sentence of yours you explicitly repeated what I already wrote

You could argue that, but that would apply to painters, chefs, mechanics, hair dressers, everyone.

"You're not cooking meals, you're solving problems"

I believe calling out something for what it is, is just fair.

Just like calling out Milli Vanilli was in order.

Ehm, I did not ask? I very much did so

> However you havent really addressed your use case anyhow but you just threw keywords around - gigabyte, IO, compressed, etc. You might want to elaborate on where you have to use XML files of the size of 50 gigabytes.

I even asked if you could provide that one 5 megabyte file. I take your response as you cant.

I really have the feeling we are going in circles here and you seem to want to resort to ridicule at this point, which will make the discussion pointless.

I believe I have made my point very clear from the start, elaborated more than once what my stance on this subject is, and even dug out some benchmarks. If none of that pleases you or makes you understand what I was actually trying to say, then I am terribly sorry but it is pointless.

And I'd appreciate if you could point out where I was "condescending", as I would object to that, except for the "lack of experience" and I still stand by that given the information you have revealed so far.

To also address this part which I seem to have missed earlier

> This all shows XML needing to support at least two different but related mechanisms. I'm not saying any of this is bad or that it makes parsing impossible: its just a source of complexity. JSON has key value syntax as well. XML has this flexibility but it quickly adds up. This is not a fault - it's the whole point of XML.

It is not really two different mechanisms. It simply is part of XML's syntax, just in the same way as these two JSON examples are very similar

  [
    { "hello": "world"},
    { "hello": "world"},
    { "hello": "world"},
    { "hello": "world"}
  ]


  {
    "1": { "hello": "world"},
    "2": { "hello": "world"},
    "3": { "hello": "world"},
    "4": { "hello": "world"}
  }

Does any of that add complexity? Yes of course it does. If you dont want complexity you should probably go with a "Hello world" program, which incidentally will be also relatively bug-free ;)

However saying the additional syntax support of XML adds complexity which adds hours of CPU time when processing the same data in different formats (JSON and XML) borders ludicrous. Unless your XML parser is (deliberately) slow of course.

Most definitely no offence meant, but if you are talking about gigabytes in the context of JSON, XML, or any other text based format you are doing something wrong. And yes, in this case I will stand by my "lack of experience" concerning your entire team, I am sorry.

However you havent really addressed your use case anyhow but you just threw keywords around - gigabyte, IO, compressed, etc. You might want to elaborate on where you have to use XML files of the size of 50 gigabytes.

It doesnt really matter what you are using, Java was just one example. If the XML parser you employ has similar issues you must not be surprised if the outcome is similar. And you seem to be coming back over and over to software support (dependencies). Yes, particularly Java was poor when it came to that but as I said quite some time ago, that is an issue with that software not the document format.

I will disregard the 10M+ tests, but could you publish somewhere the results of the 5MB files?

Again, JSON and XML are way too similar to be anywhere close to what you described and aforementioned benchmark highlighted that. Yes, its dataset is average but I am sure you'll be able to extrapolate that for larger sets.

Apart from the apparent improper use for data of that magnitude, I could only imagine you used an XML parser that simply was not fit for the task and if you do that you shouldnt be surprised that it does not work.

Not that it actually matters much[1] but as you insist very much on performance here a benchmark

http://www.navioo.com/ajax/examples/json/test.php

In the first example XML actually is a tad faster, in the second example it is practically a tie (JSON wins by three or four milliseconds).

[1] Are we seriously arguing about milliseconds when it comes to document parsing?

I provided exactly one example and that was a comparison between XML and JSON. The follow up was just an additional remark that idiomatic XML would be even shorter.

I am afraid I cannot follow your argument about complexity as any parser worth its money WILL BE ABLE to parse XML without any significant overhead and - as I mentioned numerous times - issues do not stem from how an XML document is built but from the fact that (mostly) Java parsers attempted to implement about each possible OOP pattern instead of going for KISS. The code over-engineering is the issue, not the document structure. I am really not sure what point you are trying to make and why you are diverting from the actual topic I addressed.

I am slightly surprised about your bias remark, as it seems to be you who is strongly biased towards JSON despite my initial comments as well as the "significant benefits" as I never made any such claim, on the contrary it is you once again who seems to make such about JSON. Maybe you can post the "hard data" you referred to.

Bottom line (once again), XML and JSON are extremely similar and saying one is better than the other simply shows lack of experience. Then of course, if you parse 70 kilobyte JSON documents with a lean parser, but parse 12 megabyte XML documents with a typical Java parser, nobody needs to be surprised the latter will perform abysmally compared to the former, but that would be a whole different subject.

I dont think we need to go down the where there is smoke there is fire route. These implementations are bad for a variety of reasons but not because XML is bad itself.

As I said, XML on Java is often a hassle but that is neither XML's fault nor Java's but the responsibility of those developers who thought going bananas on interfaces, factories, and alike is actually a good idea.

As for XML, its syntax is somewhat more verbose than JSON's but thats about it.

-----

Just to provide one very basic example

XML

  <people>
    <person>
      <name>John Doe</name>
      <dob>2000-01-01</dob>
    </person>
    <person>
      <name>Peter Smith</name>
      <dob>2001-01-01</dob>
    </person>
  </people>

JSON

  [
    {
      "name": "John Doe",
      "dob": "2000-01-01"
    },
    {
      "name": "Peter Smith",
      "dob": "2001-01-01"
    }
  ]

Apart from XML being more verbose (but also providing more context), these two documents are virtually identical, they even have the same number of lines.

And if one used XML actually idiomatically the example would slim down by a lot

  <people>
    <person name="John Doe" dob="2000-01-01" />
    <person name="Peter Smith" dob="2001-01-01" />
  </people>