Live data from Hacker News

XML is the future

bitecode.dev

221–230 of 408 posts

Re: XML is the future

#221
post #10

Earlier quoted context omitted.

Your points do nothing to back up your claim that "serverless architectures are much more complicated compared to servers" 1. You still have to do polling with servers 2. Not a serverless problem 3. Not a serverless problem 4. This is a tradeoff, not complexity 5. Why not? What does serverless have to do with this? 6. Appears you're confusing serverless and FaaS. Regarldess, FaaS has incredibly predictable pricing. P…

1. Pooling is trivial to setup with servers. In fact, pretty much all clients like Knex and Prisma does connection pooling by default without an external dedicated server. 2, 3. The promise is that serverless APIs can be deployed on the edge for improved latency. The edge does not matter if your data is centralized. So you're adding complexity without the benefit of speed. 4. One of the most important aspects of any…

> Even if you want a simple cron job ..., you can't do it with serverless functions.

I don't understand this. Can't you have a AWS lambda run on a timer, for example?

Re: XML is the future

#222
post #187
post #178

Earlier quoted context omitted.

As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions. You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do somet…

> forget about it for a few years No version upgrade required. :D

At the time we were reluctant to update even our linux servers. We had only critical security fix repos enabled and checked them once a week.

No, we didn't update PHP unless strictly needed.

Re: XML is the future

#223

Earlier quoted context omitted.

I think "XML" is way too broad to meaningful discuss anything. XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-job…

> The insistence of the JSON-people to sabotage any kind of data validation is absurd to me. I don't understand what you mean by this. JSON supports schemas which can be used to validate input. It's not super advanced, but it's functional.

JSON schema aren't part of the JSON definition, and JSON itself suffers from lacking good handling of types such as dates.

JSON itself succeeds as a way to represent JavaScript objects but it is far less useful than XML for representing custom types, which are easily enforced through XML Schema.

JSON Schema adds some of this, but it isn't a standard (yet).

Re: XML is the future

#224
post #125
post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

Its incredible to look back at the arguments against XML and XHTML and realise just how poorly thought out they were.

Now, we've wasted the past few decades re-implementing everything that XML provided, but worse, and will spend the next few decades doing that all over again.

Re: XML is the future

#225
post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

Wow, this resonates with me! I stopped doing full-stack development a while ago, and have since January been contributing to open source projects as a contractor (my next gig will be for ISRG, the makers of Let's Encrypt, :D). By working on open source libraries I get to tackle interesting problems without being bogged down too much by accidental complexity. It feels like the ideal solution to me (though it is difficult to replicate, as it takes quite some luck).

Re: XML is the future

#226
post #61

I worked a decade in public sector digitalisation in Denmark, where for some reason they still use a lot of SOAP and thus XML. I’m not so against XML in theory, but I hate it in practice. You’d have these completely over engineered solutions where you’d basically need to call a separate micro services for every “field” of anything. So if you wanted a name, a ssn, and, an address for a citizen you’d need to make sever…

> If the future is XML then we’d better step up our game!

I don't think you understood the meaning of the article. It's talking about how XML was, at the end, a red hearing and not best solutions for everything as it was tooted by the industry.

Re: XML is the future

#227

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…

I think you left out the main factor which is that programmers are people and people subconsciously copy what other people are doing. We are herd animals. Also most people are not really good at judging novel things and are mainly influenced (subconsciously) by surface appearance and popularity.

Re: XML is the future

#228
post #189

Earlier quoted context omitted.

If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container. Setting up monitoring for your docker containers is also a whole thing. :) I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the…

The biggest thing with containers is, these 40 vulnerabilities won't matter as much if they're about erasing your directories or killing your machine. It will get rebooted in a pristine state and an attacker would need to stick there killing it at every reboot to have lasting effect. Which is also the point of monitoring a container, which is fairly reliable nowadays, compared to managing your own health check servic…

> won't matter as much if they're about erasing your directories or killing your machine

Those sort of attacks have tapered off though, right? Unless you're engaged in a specific feud, or have caught the ire of a social justice warrior, these days we're mostly looking at data exfiltration as the primary goal. That being said, there are a lot of ongoing feuds and active social justice warriors.

Re: XML is the future

#229

Earlier quoted context omitted.

The X in AJAX is there because the devs had to put it in MSXML, because they couldn't add it to IE itself due to a code freeze, and because XML sounded cool back then. https://web.archive.org/web/20170424220609/http://www.alexho... While there probably were some pages using XML in AJAX, many were just sending HTML fragments.

> This was the good-old-days when critical features were crammed in just days before a release Fascinating article, but really? I would have thought "cramming in" critical features days before release was more common these days, esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.

> esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.

What does releasing regularly have to do with cramming stuff in? We release when stuff is ready. That could be multiple times a day or once a week.

I think of people with set release dates as the most likely candidates of "cramming stuff in" because they fear they will miss the release and it might be a month (or worse) before the next release

Re: XML is the future

#230
post #125
post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

That's all fancy fluff. It's just optional benefit, we don't need all that in most cases. So if we add the flaws of XML into the evaluation, it naturally loses in most use cases.
Post reply on HN