eftpotrm · HackerTrans

hace 8 mesesdiscuss

Aside from the other commenter's point about this being a misleading comparison, you didn't need to reinvent the whole XML ecosystem from scratch, it was already there and functional. One of the big claims I've seen for JSON though is that it has array support, which XML doesn't. And which is correct as far as it goes, but also it would have been far from impossible to code up a serializer/deserializer that let you treat a collection of identically typed XML nodes as an array. Heck, for all I know it exists, it's not conceptually difficult.

eftpotrm

hace 8 mesesdiscuss

What makes XSLT inherently unsuitable for an interactive application in your mind? All it does is transform one XML document into another; there's no earthly reason why you can't ornament that XML output in a way that supports interactive JS-driven features, or use XSLT to built fragments of dynamically created pages that get compiled into the final rendered artifact elsewhere.

eftpotrm

hace 8 mesesdiscuss

I'm aware I'm in a minority, but I find it sad that XSLT stalled and is mostly dead in the market. The amount of effort put into replicating most the XML+XPath+XSLT ecosystem we had as open standards 25 years ago using ever-changing libraries with their own host of incompatible limitations, rather than improving what we already had, has been a colossal waste of talent.

Was SOAP a bad system that misunderstood HTTP while being vastly overarchitected for most of its use cases? Yes. Could overuse of XML schemas render your documents unreadable and overcomplex to work with? Of course. Were early XML libraries well designed around the reality of existing programming languages? No. But also was JSON's early implementation of 'you can just eval() it into memory' ever good engineering? No, and by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had.

RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else.

eftpotrm

hace 6 añosdiscuss

I once worked on a project that only existed because the end users had seen the SAP web UI and rebelled, hard. In fairness I don't blame them; when we dug down it was easily the worst HTML I've ever seen and some impressively weird behaviour. I can't quite imagine which team at SAP thought it was appropriate to release as a tool.

So, we spent 6 months or so building a front-end that the users wouldn't refuse to touch. HTML5, responsive, attractive, flexible. I mostly worked on the toolkit side of the project to try and keep UIs vaguely standard across the multitude of screens.

And alongside us, the two highest paid contractors I've ever worked with (who seemed to be earning their money), were building what amounted to SQL stored procedures that went into a tool that let them be interfaced as REST APIs. The article talks about the amount to which businesses have to mash themselves around how SAP works - from what I saw and heard, that was even after they'd spent more customising SAP than I would expect to bill to have built very large parts of it from scratch.

So yes. I'm sure that, at a really large corporate scale, SAP has its advantages to organisations. But in a 20 year career it's probably my least favourite technology, including the email server which you could misconfigure so receiving an email would bring down the whole machine. I wouldn't be remotely surprised to see SAP disrupted into oblivion, and a bit of me would love to be part of the disruption.

comments