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

XML is the future

bitecode.dev

Post reply on HN
Print view View original

131–140 of 408 posts

Re: XML is the future

#131

Post by hughesjj »

charcircuit wrote: post #18
douglasmoore wrote: post #5

Earlier quoted context omitted.

Just want to comment on the first two points as a vercel fan (1) pooling becomes the solution very early. You get massive speed benefits by keeping a connection open. Hitting connection limits is too easy without it. I feel like a push towards pooling is fine because it has great benefits for scale, speed and reliability. Services like Supabase have connection pooled postgres by default even in their free tier. (2) n…

>nextjs server side data fetching is an amazing feature that deserves it's place in future of web development It was a thing in the past too. It's how almost all a CGI and PHP sites worked.

And jsp and asp and literally everything before ajax

Re: XML is the future

#132

Post by hooby »

In my previous company we had - back in the day - a newly hired junior developer that fully subscribed to that particular XML hype.

We had our uses for XML - we liked it especially for API endpoints and import/export files we exchanged with third party companies. Reason being, you could create a Schema Definition, send it to the other company, and tell them not to bother you, until their data validated against that XSD. We used XML for stuff like that extensively.

But that one junior was like "You are using databases? How silly of you! Just use an XML file and x-path. There's nothing a database can do, that XML can't! You really should switch over your production frontend to xml immediately!"

We gave him a little side project and allowed him to write that using xml instead of a database, which he did. When his results turned out to be pretty much unusable, and did not convince us to switch everything to xml, he left the company to find a more "modern" workplace...

To this day I'm not sure if he actually truly believed that xml/xpath would soon replace all databases - or if he just didn't want to learn SQL (and hide the fact that he was pretty bad at it).

Re: XML is the future

#133

Post by wizofaus »

madsbuch wrote: post #106
Mikhail_Edoshin wrote: post #88

XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because y…

You could say the same about JSON. It is arguably closer to how and AST is represented in software as it does not posses the two dimensional notation like XML does. The unique thing about XML is that you can both have children and attributes. My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections. This is IMHO the w…

> My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections.

Can't say I've ever thought of it that way - attributes just seemed like a simpler syntax for the common case of basic properties that were sensibly represented as strings (i.e. single, literal values). I don't think it would have made much fundamental difference if they were never part of the spec and you had to use sub-elements to define such properties, except perhaps for the fact an attribute of a given name can only be declared be once (which an interesting difference between JSON and XML - XML lacks any syntax for declaring arrays, so you must be able to declare multiple sub-elements with the same name).

Re: XML is the future

#134

Post by HelloNurse »

"At this stage, so much time and money were obliterated the cloud felt like a savior: they will do all that for you, for a fee."

I think "the cloud" and its cohort of friends did a lot to increase the mindshare of the gratuitously complicated ways to do things the article reviews.

For example, there is scale-shaming: if you don't want to invest in allowing your todo list or your ERP for small businesses to scale to infinite users, you are 1) nobody on a business plane, not even ambitious; 2) ignorant, lazy and behind the times on a technical plane.

Re: XML is the future

#135

Post by 28304283409234 »

hardwaresofton wrote: post #71
andrewflnr wrote: post #58

Earlier quoted context omitted.

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

> I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the differ…

A better comparison would perhaps be “ansible” vs “puppet” vs “chef”.

I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.

Re: XML is the future

#136

Post by deaddodo »

mschuster91 wrote: post #113
deaddodo wrote: post #43

Earlier quoted context omitted.

Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than indus…

> your payrate is generally going to be quite a bit lower than industry standards at app/tech companies And so will be the workload. No semi-mandatory after-work drinking, no constant "hustling", no bullshit.

This is completely anecdotal, but I was far more overworked as an engineer at a non-engineering company than at any engineering company I've worked at. The entire reason I went back to that work environment was because I was tired of "wearing multiple hats" (e.g. doing three people's work) for 2/3 the pay of wearing one of those hats at some random adtech company.

Re: XML is the future

#137

Post by anonzzzies »

nologic01 wrote: post #74

Some thoughts of why software is so hype prone and will likely remain so, if not accelerate * Its intrinsically easy to come up with new approaches. Thinking and writing software is a mental process, it is not limited by physical constraints and messy manufacturing. * The scope of use contexts in society exploded. You only needed the formula-translation language when you had five whitecoats in a research lab punching…

> * The process is self-feeding. With the internet came the development of online interaction tools, techies use them more than any other segment and this creates a large coherent mass of lemmings and network effects

I feel it's mostly this; there are a few people actually creating these 'new' (most are just the same thing without little benefit, however, some people are better talkers/pr/marketers than others and so win a lot of souls) technologies and then they get many followers with more loud voices than brain who also start to shout about how everything before this was crap. A lot of effort in software is destroyed for not much reason but resume, ego and opinions. I like software that runs without issues for 10-20 years; it keeps me sane. As with all this tech, not many companies need it but their internal 'gurus' push it along anyway, wasting money and time and speeding up the rot.

Re: XML is the future

#138

Post by wizofaus »

dheera wrote: post #64
deaddodo wrote: post #56

Earlier quoted context omitted.

The original XMLHttpRequest introduced in Microsoft's IE was intended to transport XML messages from a backend to a frontend, since JSON didn't exist at the time. Realistically, originally it was just used to directly inject blobs of html into the page. Ajax just referred to utilizing that feature along with JavaScript's async functionality to create dynamic webpages. It wasn't really a technology, and I've very rare…

I had the equivalent of XMLHttpRequest LONG before XMLHttpRequest existed, back in the IE4 days. I did it by creating a tiny iframe with the target URL and then retrieving its contents. Never mind that I could also read users' hard drives, but I had AJAX long before AJAX was launched. Unfortunately there was a period of time when Microsoft patched the security issues with iframes and that was no longer possible, but…

iframes didn't become common across browsers much earlier than XMLHttpRequest from what I recall - maybe a year or so? But I certainly remember playing similar tricks to get smoother page updates, in some cases even using actual FRAME elements (are there any pages at all these days still using those? They appear to be deprecated anyway.)

Re: XML is the future

#139

Post by Mikhail_Edoshin »

tannhaeuser wrote: post #104
Mikhail_Edoshin wrote: post #88

XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because y…

> XML is somewhat unique as a concept. There was nothing like it and still isn’t. That's just incorrect. XML is a proper SGML subset, nothing more. Why do intelligent people like you come here to lecture about markup languages but don't even bother to read the XML specification which clearly states (as in chapter 1, sentence 1): > The Extensible Markup Language (XML) is a subset of SGML that is completely described i…

Indeed it is. But being simplified and separated from SGML it somehow revealed a clearer idea of what a notation is. SGML is a markup language and as far as I remember it (not too well), it never was disassociated from the text; maybe it was possible, but not widespread. XML without text content is perfectly usable and is even more convenient.

Re: XML is the future

#140

Post by mcv »

Blaiz0r wrote: post #130
mcv wrote: post #117

Earlier quoted context omitted.

Yeah, you can't jump on every hype. I started in web dev almost 20 years ago (did some Visual C++ before that). First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Was pretty cool, but there's always something that didn't fit that paradigm. Some coworkers went a bit overboard and used XSLT to generate the XSLT to create the H…

Microservices are more an organisational thing than a recommended pattern, when a project grows and wants to hire more staff to increase its bandwidth then microservices are a great way to support that, the additional benefit is that they work great in a CI/CD setup so you can release seamlessly. GraphQL from what I can tell supports web developers rewriting their APIs when they need to instead of waiting on back-end…

Most of my projects have just a single team in charge of a single code base, so there seems to be no need for microservices at all, and yet some people keep bringing up that we should really look into microservices.

My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are. Again, with a single team doing everything, there's no need for it at all. But we're using it anyway.

Also, they keep talking about a Single SPA Application, and I can't tell if that's just a redundant way to say SPA, or if it's really something new, or if they're just messing with me.

Post reply on HN