20 ms·

XML is the future

• taeric 3y ago
  It wouldn't shock me to find that a ton of the ideas in XML do become the future, all told. We railed against it being overly complicated, but then it seems we have slowly walked back down that path as the years go on.
• senttoschool 3y ago
  In my opinion, one of the worst was things was going from servers to serverless for web apps. Vercel (formerly Zeit) made a complete switch from servers to serverless for hosting and Next.js. Everyone jumped in without realizing just how much more complicated serverless architectures are compared to servers. 1. Having your APIs as lambdas now means you can't simply connect to a Postgres/MySQL without setting up a dedicated server that serve as a connection pool. So you're now "serverless" but you now have to add a server as a connection pool. /facepalm 2. Putting your APIs on the edge means absolutely nothing if your Postgres/MySQL/Redis/3rd party services is still in one location. 3. Serverless edge databases started popping up but they were significantly more expensive (because you have to replicate data everywhere) and more complicated with limited upside. 4. Cold starts on lambda APIs meant that your web app/web site often load slower than a centralized server. 5. You can't reliably share APIs between your web app and mobile app anymore. Previously, a single server could easily be made to serve both your web app and mobile app. 6. Serverless is often more expensive and unpredictable when it comes to billing. Previously, if you paid $15 for a server, you're going to be billed for $15. 7. Serverless is significantly more complicated when you're just trying to build an MVP. There's no need to try to scale like you're Google when you're just trying to create a proof of concept. 8. You're far more likely to be vendor-locked doing serverless. Serverless should not have been the default option for webapps. Serverless should have been the exotic option for companies that had a special scaling/edge need. Instead, servers should still be the default. The problem is that Next.js is so popular and so intertwined with Vercel that serverless is the default now. If Vercel/Next.js were honest, they would tell everyone to use serverless only if they're making a static website. Everything else should start out as a server.
  • tannhaeuser 3y ago
    Of course, but this is just an instance of TFA's key observation: > Geeks think they're rational beings, while they're completely influenced by buzz, marketing, and their emotions. To which I want to add 1. that geeks young and old try also to pad their resume and eg use React and under all circumstances whether it's warranted or not (which seems at least rational from a personal career development PoV) 2. geeks think the web is about them, completely and utterly failing to understand that its entire point is easy self-publishing. As to next.js specifically, it obviously doesn't make sense to tie serverless to React. Also, it doesn't make sense, like at all, to use React for smallish trivial internal web UIs when the main app is written in another backend language and your team has no js coding experience which just invites security nightmares and endless updates, and breaks agility and job rotation for no reason. As to XML, there's a minor factual misunderstanding here in that DTDs, like XML itself, isn't a genuine inception, but rather a simplification and proper subset of SGML intended for the web where it has failed (even though it sees plenty use outside). But that should't take away from the main point: that you don't go around advertising your fscking format without checking requirements. In this case, using XML (or SGML and HTML) for something that isn't document data, or conversely, using eg JSON for text documents. Just makes you look like a one trick pony.
  • phendrenad2 3y ago
    Right, I've come to believe that the software development world is led by the nose by snake oil salesmen. Most software developers don't have a range of experience outside of a CS degree, so they easily fall into "this is the new best practice" traps, especially if they look flashy and professional (examples: https://12factor.net https://12factor.net https://machalliance.org https://machalliance.org)
  • douglasmoore 3y ago
    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) nextjs server side data fetching is an amazing feature that deserves it's place in future of web development (the react team agrees since they've added server components). Grabbing data before reaching the client is amazing. If you have a centralized db all the more reason to grab as much as you can in one trip. Other than that I can agree. I think the advice should generally be to not ever recommend a framework too early or without including its use case. Current recommendations for the different tiers: Static: GitHub/cloudflare pages Server-lite: render.com Serverless: vercel
• rektide 3y ago
  This is a pretty low-grade reactionary ism. Usually without saying so directly the effort seems to be to lambast, to shame & berate. But it does spend a good three paragraphs catastophizing & melting down over Javascript & left-pad. > We were told to stay on top of the most modern ecosystem, and by that I mean dealing with compatibility being broken every two months. Some people just want to be ornery & cantankerous. The article can be not wrong about saying there's too much hype, marketing, and rationalizing that we know real answers. Fools with certainty are everywhere. But it can still be wrong & have a jerk attitude. That we still have to figure things out & can be wrong or overadopt is not some horrible flaw. It doesn't mean we can skewer all these ideas & crap on them like this cavalcade of schlock. So many of these various ideas do keep reoccurring, keep having real use. XML is reborn as jsonld which has some great uses. Isomorphic JS is alive & well in the new server side react craze. GRPC and Kubernetes and dozens of these other techs provide a normative baseline that let many teams work together where before we had anarchy & disorder. There's some good messages & ideas here. We do need to iterate & refine & assess value. But also this is a conservative paean. A back to the land, just simple code ideology that is so appealing, that let's folks look down their nose & reject assessing technology fairly, that doesn't allow for valid complexity. Rakishly anti-elitist, thinking itself better for being such a smart source of truth only because it can smash other works so effectively. Be more liberal & open minded, not so fixed: accept that most of these things have some really good morsels or kernels that have value Modern software is a couple decades old. Of course we are still refining & learning. Most of the things here have provided real value & informed where we go next, happened for real reasons. Some will fade, but many of the ideas will reoccur, will be better more creatively worked in or worked together in more cohesive wholes. This is a great amazing process, we happening live, in a young industry. Absolutely, beware of hype & bandwagons & marketing, of anyone who would tell you this is the way. For we don't know, and we have a long road ahead with many unexpected turns to figure out where computing's truest values lie. Stay young, stay hungry, and stay a bit foolish.
• gnulinux 3y ago
  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. Hype after hype, fad after fad, modern after modern, refactor after refactor. I have a workflow, I know how to build apps. Then one day director of Ops comes and completely and utterly changes the workflow. Ok fine, I'm young, will learn this. Month passes, it is now Terraform. Ok fine I'm young, will learn this. Now we're serverless. Ok fine, will learn. Now everything is container. Ok. Now everything microservice. K. Now turns out lambdas aren't good, so everything is ECS. OK will rewrite everything... Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. I don't even know how I would do it. Maybe I would do this the same way if I had any power. But that doesn't change the fact that it's a bit ridiculous. Fun but tiring. Entertaining but exhausting. Cute but frustrating.
  • deleted 3y ago
    [deleted]
  • lastyearmodel 3y ago
    Completely anecdotally, but the most productive I've ever been in a company has been was a company in 2016-2019 who was on a monolith .ENT Framework with no kube/container setup at all. Sure, it felt like absolute chaos some days, but I"ve never felt more productive and in a flow as then, mainly because we weren't chasing the latest and greatest thing but focusing on what's working for us and perfecting it.
    • rqtwteye 3y ago
      The sad thing is that in many cases working on such a system is a career killer. Nobody wants to hire you. Some years ago a colleague and I realized that our company wouldn’t hire us judging from the job descriptions because we worked on systems that had been working for years but weren’t shiny. Since then I always something new to every project. Not because it makes sense but because it’s good for the resume. Other groups are even worse. Three devs writing 13 micro services on Kubernetes for maybe a thousand users ever.
• ArunRaja 3y ago
  There should be a threshold to adopt new technology, with dead focus on the deliverables. Chasing the fad is endlessly tiring and costly.
  • Gigachad 3y ago
    There is. It's called "the market". A company that wastes too much time and money on non returning investments will not last.
    • anonzzzies 3y ago
      Every non-startup wastes incredible amounts on fads and other inefficiencies while still lasting perfectly fine. It's just business as usual. I could probably save my current largest clients many millions/year on dev if the CTO (& his tech leads) wasn't such a fad guy; he basically pops on Twitter every morning and starts sending over 'new stuff the team should look at'. There are 1000s of applications in that company and there is an incredible rot-fighting effort because of the use of the latest and the greatest frameworks. But millions/year is chump-change for this company so it's not happening any time soon. He does deliver, so the perception is that he gets things done; that entire teams are busy just updating 1 year old code dependencies for 0 business benefit is taken for granted.
      • Gigachad 3y ago
        If it's chump change, then it isn't really that much waste. Majority of the funds are going to proven successful methods, and the chump change goes on future bets on what might take off. I don't see anything wrong with it. This is basically how evolution works as well. Take 99% of a proven thing, randomize 1% and then either keep the change or discard it later as not useful. A lot of things which are now proven successful ideas were once indistinguishable from fads.
      • fifticon 3y ago
        I misread that as "poops on twitter every morning", but it didn't change the meaning of the paragraph..
• pjmlp 3y ago
  Lovely, being from the generation that predated OOP hype, it was a great read and I sign it.
• sideproject 3y ago
  That post was a good (or bad?) walk down the memory lane. :)
• noduerme 3y ago
  I really love this review of the past 20 years. It gets to the heart of the hype/FOMO cycle that's driven so many of these stacks to short-lived superstardom, and then quickly into irreversible technical debt. I have never really understood this. My favorite comment I ever got on a coding board when I was debating the pros and cons of building my next project in the trendy platform of the day was >> STFU, go out and make web.
  • pyeri 3y ago
    I wouldn't call XML entirely a hype or FOMO, it has become part of what we call the modern web even today. 1. The very language that websites are written in today (HTML5/XHTML) are nothing but XML dialects. 2. React's JXS language which many sites use today is also an XML dialect. 3. RSS and ATOM standards used to publish your blog or website feeds are XML standards. 4. JSON replaced XML only as an efficient transport medium, it's not a substitute for XML entirely. XML nodes have attributes which is an additional layer in describing your data. As your data structure gets more and more complex, XML becomes a better way of defining it. By contrast, many JS frameworks which came after XML like backbone, knockout, angular.js (1.x), etc. are eating dust today and will probably never see the light of day again.
    • otherme123 3y ago
      Rss/Atom feels like a case of Querty keyboard. https://www.jsonfeed.org/ https://www.jsonfeed.org/ would be a better choice, but only a few readers implement it, and a lot of frameworks has Rss/Atom by default with a click. As you explain in (4), Xml makes sense for complex data, but feeds are basically in their final version.
      • gottlobflegel 3y ago
        I really find it interesting that some people consider working with xml such a pain that they develop a whole new standard with the sole raison d'être being "It's not xml"
    • noduerme 3y ago
• _8j50 3y ago
  I can't overstate how much I hate xml. I'd rather parse binary structs.
• paulddraper 3y ago
  > XML is the future That kinda happened, just not in the way everyone thought. In 2023, JavaScript XML is the most popular way to develop web applications, and a common choice for mobile and desktop applications. --- EDIT: JSX/React/React Native, in case that wasn't clear.
  • deleted 3y ago
    [deleted]
  • jonnycomputer 3y ago
    Can you elaborate on that?
    • preommr 3y ago
      JSX - stands for Javascript XML. React components can be referenced as custom tags in a markup that's an extension of html - pretty much xml.
      • deleted 3y ago
        [deleted]
      • baq 3y ago
        Yes. It won because the name starts with JS and I’m only half joking. What I desperately need now is JSML so I can free myself from the madness of YAML.
        • Ygg2 3y ago
          As someone working on Yaml parser. I fully understand that pain.
      • jonnycomputer 3y ago
        Thank you.
    • deleted 3y ago
      [deleted]
• chunkyks 3y ago
  Time to link grug brain again! https://grugbrain.dev/ https://grugbrain.dev/
  • isoprophlex 3y ago
    Thanks to chatGPT there's an infinite supply of Grug wisdom on this specific topic: Grug see tribe use XML for talk between cave wall. But XML talk too loud. XML say <message>Hello</message>. Why not just say Hello? JSON talk quiet. JSON just say "message": "Hello". Grug like quiet talk. Grug also see XML not consistent. Sometimes XML use attribute, sometimes use element. Make Grug confused. JSON always use key-value. Grug like consistency. Grug think XML like big, heavy rock. Hard to carry, hard to use. JSON like small, sharp tool. Easy to carry, easy to use. Grug choose JSON.
    • klabb3 3y ago
      It’s good in the shallow style but that’s not exactly why grug would prefer JSON. I think mostly it’s because fewer things can go wrong, and parsers are widely available and always works. Grug would also admit that JSON lacks features (like timestamps), but that the workarounds (number as unix timestamp) works just fine.
• preommr 3y ago
  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 json+comments would be the ideal format. Time and time again we see that people prefer simple solutions that they can get jump into easily. Maybe certain problems don't require solutions with those traits, but anything with sharing data among a diverse group of consumers does. The XML ecosystem with things like XSLT, Xquery,etc, were elegant, but also overengineered and clunky. I would even say that markup itself with closing tags were more annoying than just closing brackets. Software is still so young... I think it's good that we tried and learned something from it in the short term. Maybe one day we'll get a proper standard with all the right data types that becomes the defacto solution that people learn it even if it's more complicated.
  • seanp2k2 3y ago
    Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" and easier to work with using normal text-based tools / curl / etc. The internet felt like magic growing up once I learned about SMTP and HTTP using telnet and played with quite a few serial terminal devices. Now with many APIs behind OAuth or worse, it's getting much less trivial to hack around with in simple ways.
    • deaddodo 3y ago
      > Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" This is like comparing a Mustang engine to a racetrack. They're not even equivalent technologies. GRPC and GraphQL would equate to SOAP, REST or some other interface protocol. JSON equates to protobuf, XML or another transport format. Of those three options, I have no idea how JSON would be considered the "closest to the wire". Protobuf is definitely the lowest level, while XML and JSON are about equivalent in abstraction.
  • eduction 3y ago
    >but I think it's much more worthwile to dive into the particulars of why it failed If you’re going to deep dive, define your terms: what did it fail at? At being the future? Kind of a straw man, even if some people did argue that. As a document interchange format? Between RSS — including podcasts! — Microsoft Office, and LibreOffice it seems to have done reasonably well. As a data interchange format? Undoubtedly JSON is now preferred for this, but keep in mind that for several crucial years, as the “X” in “AJAX,” it paved the way for modern web apps via Google Maps, Gmail, and before that Outlook for the Web (literally the original AJAX app). I think it’s not really interesting to examine how and where JSON displaced XML given this is not hard to grasp and well covered. Much more interesting to extract lessons that also work on JSON and predict what might displace it and where and how. For example it’s interesting that JSON is simpler than XML. Might it have discarded something valuable? The “X” is for extensibility - if we could extend JSON, which we can’t, how would we? First class date times might nice, mmm? Or to be able to add arbitrary other self describing data types? UUIDs? What is XML still ideal for? Etc
• js8 3y ago
  Well, turns out you don't really need large antlers either, but the deer just won't listen.
• LispSporks22 3y ago
  Just in case you came down in the last shower, as someone stayed the technical track and lived through it all, it’s 100% correct. Most hilarious line from the article: > That was the last straw, so out of tiredness, devs went back to simple ways... > Just kidding
• somsak2 3y ago
  > So we watched beginners put their data with no schema, no consistency, and broken validation in a big bag of blobs. The projects fail in mass. source? although I was also a mongo hater at the time it was being hyped, I've yet to see anything concrete that would show this technology choice made a company more likely to fail. over time, I've actually come to believe that tech choice is one of the least important decisions in terms of impact on a company's market success. which makes me not care so much about fads either way.
  • mcluck 3y ago
    I worked on two different projects that were going fine until someone decided we needed Mongo. The bugs piled up and the projects were dying when I left
• EugeneOZ 3y ago
  The only good thing about this article - it will attract all the headhunting bots. So many keywords!
• devjab 3y ago
  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 several calls. We ended up buying an API for the APIs, but that is besides the point I’m trying to make. The point is that it was very designed, but the XML. Well… you’d have things like: <ssn ssn=“123”/><id>123</id> and worse. And it’s like, why would they spend all that time designing micro-service and data architectures and then output really inconsistent and often even standards breaking XML? But I know why, because out of the maybe 300 different systems to output XML that I’ve worked with over the years, none of them did it “right”. If the future is XML then we better step up our game!
  • mythhabit 3y ago
    > 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 several calls. The official CPR API you can get all of that information with a single call and I think it returns JSON. I'm not sure when that API was released, but I think it was quite a while ago. There is one for companies as well (CVR API, but technically it's just an Elastic Search query iirc).
  • olsgaarddk 3y ago
    At the tax authority we could query that directly from a database. But yes, the public sector suffers from countless different systems that have accumulated over the years. It happens because everything has to go out to a public bid and throughout the times it has been considered anti competitive to built things in-house.
    • TeMPOraL 3y ago
      More than that, the vendor winning the bid will happily use the opportunity to latch itself to the flow of taxpayer money. That's a big reason you end up with XML hell - the systems are designed to make future interop impossible without going through the vendor. In fact, wasn't Denmark a case study of that? I remember there was someone on HN a while ago, IIRC working in public service of some country in Europe, who posted stories about their constant fighting with a vendor who intentionally makes it very hard to have any kind of integration and data exchange between various administrative branches.
• bradley13 3y ago
  Great, if cynical article. If you have a company that chases fads, you need to work for a better company. Find one where the older developers aren't 30-something. Usually, gray hair brings a certain immunity to fads.
• espe 3y ago
  it is easy to paint XML as anachronistic, and as crude serialization format it certainly is. but as many analogies, that only goes so far. there is still the excellent tooling (XSLT, DTD, schematron..) and the fact that there are elaborate data modeling use cases still using it because there is nothing that comes close to that combination of expressivity and tooling. take for example the TEI: https://tei-c.org https://tei-c.org you could do it with OWL or UML of course, but would you, really? in some ways we haven't really explored the possibilities of data modeling. there is things that json+some schema will never be able to do. ps: i enjoyed the article.
• frithsun 3y ago
  XML finna make a big comeback.
• emodendroket 3y ago
  Seems like there is a blending here of features and technologies. Your users will probably not know or care whether you choose YAML, XML, or JSON, but they'll notice gamification features.
• nologic01 3y ago
  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 instructions on a single computer. Now you have multi-billions of devices. * 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. * The role of bigtech (oligopolies solving their own problems to maintain / expand their dominance and abnormal profitability) which creates a collective osmosis to imitate whatever they are doing. * There is also intrinsic redundancy and near equivalence of solutions. You only have one way to roll a concrete something on a surface: it must be round. But one can have an infinity of ways to split a workload between a client and a server machine (let alone more servers). Most of those factors will continue for the foreseeable future so there will be no respite. E.g., Now we are firmly into AI hysteria and this again already shakes things up as it deprecates/de-emphasizes patterns that are not part of the bandwagon and puts emphasis on obscure niches that are deemed critical.
  • anonzzzies 3y ago
    > * 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.
  • ilaksh 3y ago
    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.
• dmje 3y ago
  What a cracking article. I nodded so much my neck hurts. I'm 50 and although by HN standards, not a proper nerd (I'm a ..."web generalist?" - more project manager who can dabble in code than anything ey) and I've seen all this stuff come and go for 30+ years in the web industry. The thing I've always done is stuck to the core trio of technologies: html, CSS and a smattering of JS when you need it. Then it's PHP for serverside. For a very large proportion of cases, this is perfect. It's solid, known, reliable and built to last. Granted, I build websites and not web apps. But for me this highlights the oft-quoted truism that you use the right set of tools for the job. There's no reason for me to go all SPA on my builds because that's not what I need. Ditto with React or Kubernetes or Docker. It's just adding complexity in my scenario that isn't needed. Then there's another side which I have in spades same as every other nerd - curiosity. So yeh, I've fiddled with htmx and docker and microservices but because I'm interested in finding out more. The crucial point comes when these two parts collide. And then really the only way is to ask - boringly - "is this the right tool for the job?", when I take in all the factors: sustainability, ease of deployment, documentation, etc. So yeh, beware the bling of new tech blindness. Most of the time it's the boring old stuff that is best suited for the job. There's a reason after all why these technologies are still around...
  • RachelF 3y ago
    Yeah, I've been in this game for 40+ years. Fads come and go. When I started 4GLs were going to take over everything. 10 years later it was SDDs and SDSs, then it was UML and it goes on to what's mentioned in the article. Perhaps it is the triumph of hope over experience, perhaps those new in the field prefer to use the new tools rather than understand how the old ones work. I think the quality of software has deteriorated, but then complexity has also gone up. One never writes anything from scratch these days, there's a tower of libraries underneath now.
• Mikhail_Edoshin 3y ago
  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 you can get a rather concise and elegant result. XML is normally way more verbose, although not that much, if well done. Yet the expressiveness is exactly the same. Notation is what you need when you manually compose some data for machine processing. XML as a data interchange format is a misuse. Yet XML as a data description format is what it is very good at. The difference is that data interchange goes from one machine to another, but data description is what goes from a human to a machine. Data input, in other words. Complex data input. Language-like data input. This is why XML is widely used, for example, in user interface frameworks where you need to describe very elaborate data structures. Markup is another obvious example; here you also have complex data structures tied to a piece of text. Yet markup is just a special case. So if we are to add something to this article’s sentiment it could be an observation that we are also prone to misunderstanding things and jumping too quickly to conclusions.
  • tannhaeuser 3y ago
    > 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 in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML.
    • Mikhail_Edoshin 3y ago
      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.
• bugbuddy 3y ago
  > The cloud is often just as complicated as running things yourself, and it's usually ridiculously more expensive. This was obvious to anyone who was willing to do the maths from the beginning. One big reason for the success of the cloud that no one has talked about is that developers often have a disdainful view of the IT department and the operation people. So pushing DevOps, let them go around those people and have the instant gratification of getting all the computing resources they want when they want it immediately without going through the IT department and operation people. Ironically, some of those developers are starting to get sick of managing the operations and want to just go back to focusing on development. Thus, the pendulum swings back.
• d--b 3y ago
  > geeks think they are rational beings, while they are completely influenced by buzz, marketing, and their emotions. Also geeks are influenced by whatever tool is most convenient. I’ve used XML knowing pretty damn well it was annoyingly verbose. But hey it came with all the tooling: a library to parse it efficiently, auto formatting in my editor (with folding and auto-correcting), all the docs for graduates who didn’t know it. And there was nothing else! The same is true of : Electron, Pandas, etc. Sometimes the “best” tool is just the “only” tool…
• abdellah123 3y ago
  This is Gold!
• bullen 3y ago
  As per usual with XML I post my node/tree graph editor: http://move.rupy.se/file/logic.html http://move.rupy.se/file/logic.html Still works great, I currently use it to chop up sprite sheets and bundle them with my app as base64 encoded pngs! XD XML must be the future. Also use this parser: http://edit.rupy.se/?host=move.rupy.se&path=/file/Parser.java&space http://edit.rupy.se/?host=move.rupy.se&path=/file/Parser.jav... Indentation from hell and some code missing but you get the point. No bloat... and XML! :P
• MPlus88 3y ago
  [dead]
• trabant00 3y ago
  True but unavoidable for an industry as young as ours. We'll explore every nook and cranny for possible solutions before settling on slowly evolving proven tools. And that will take generations. More than 10 IMHO, so by the time the complaints from the article will be obsolete our bones will also be dust. We're in the gold rush phase of IT and will endure everything that comes with it: hype cycles, snake-oil, depressions, shady and downright criminal activity, lots of stress, etc.
• hooby 3y ago
  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).
• HelloNurse 3y ago
  "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.
• yarg 3y ago
  XML has been around for long enough that a lot of people have developed a tacit understanding of it, it's not reasonable in all cases (I once went to war with an 8000 line build.xml file - fuck everything about that), but for simple cases it's an easy to parse hierarchical format that most people who need to can get a handle on. But there's one vestigial artefact that irks me. <tree> <leaf colour="green"/> <leaf colour="yellow"/> </tree> Why can't I just do this? Validation and highlighting are well past the point where it should be a viable option. <tree> <leaf colour="green"/> <leaf colour="yellow"/> </>
  • tomgp 3y ago
    I’m not sure, but possible legibility? Like if you have a bunch of nested nodes it’s nice to be able to see where one ends at a glance.
    • yarg 3y ago
      Decent indenting generally helps there (and siblings are often of the same type anyway, in which case it doesn't improve indistinguishability). Beyond that syntax highlighting and marcation of the head and tail of the currently selected tree can improve things when you're manually editing a document.
  • MawKKe 3y ago
    why not go further, why can't we just write <tree <leaf colour="green"> <leaf colour="yellow"> > although now that ="foo" business seems too noisy. how about <tree <leaf :colour green> <leaf :colour yellow> > also, those angle brackets are too pointy, let's swap them to something more pleasant (tree (leaf :colour green) (leaf :colour yellow))
    • yarg 3y ago
      The change I suggested is backwards compatible - probably a relatively small change to a single method in parsing. You, on the other hand, took the pre-existing syntax and contemptuously threw it out the window - and completely ignored the advantage of widespread tacit understanding.
• BlackFly 3y ago
  If you want a constructive take on the problem this rant is aimed at (I'm rant happy too, so don't take that description pejoratively), read "No silver bullet" by Fred Brooks, written in 1986. The problem hasn't really changed over time. I think the past four decades have proven his point. This is the article that highlighted the idea of accidental complexity and essential complexity. Then he points out that the hard problem is making incremental improvements to how we handle essential complexity and that there is no silver bullet. Nothing will ever give you an order of magnitude improvement. So the corollary here is that if you want an order of magnitude improvement, you will need multiple incremental improvements. You need to make seven 10% improvements to double your efficiency and you need 24 to obtain 10x. An excellent student solves problems correctly 95% of the time, or makes a mistake 1 time in 20. So that excellent student who becomes an engineer may make a mistake 1 time in 20. Not everyone will be so accurate, many of the fads which have promise may be dead ends as well: it might not be possible to increment on them.
• boffinAudio 3y ago
  For everything anyone wants to use XML, I use Lua. Its just better. Yes, even config files. Especially config files.
• tuyiown 3y ago
  > But above all, I learned that geeks think they are rational beings, while they are completely influenced by buzz, marketing, and their emotions. Even more so than the average person, because they believe they are less susceptible to it than normies, so they have a blind spot. This is so spot on, so much that 9 hours after publication, it looks like I'm the first that I'm picking on it to start a thread. The author has written the essay to illustrate that point, what I see is strong denial from commenters.
• steve_adams_86 3y ago
  I absolutely get the sentiment about things breaking every 2 months and how hype dominated where cool heads should have prevailed… Yet these tools allowed me to build great things over the last ten years. Only two projects I started professionally were never finished, and one was only because my son was born and I decided to be a stay at home parent. I don’t have this problem of unspeakable dead projects. For all of the warts, this crazy ecosystem has been a productivity power house for my employers. React native is absolutely awful to build things with, but it worked. Unified code from server to web client to mobile client actually worked, and it worked well. That’s crazy. So on one hand I get it. On the other, I feel like we’ve forgotten how much better things have gotten. Building for the web is leaps and bounds ahead of where it was, but it took a lot to get here. Yeah there are still issues and no XML wasn’t the future, but I think it was worth it. I’m probably lucky too though, because I accidentally picked technologies with relatively good staying power. I never did the Angular 2 rewrite, for example. I was deep in React and redux and stayed there for years. I can see this being a lot worse if you didn’t get to transfer as many skills over the years.
• phrenicfraud 3y ago
  [flagged]
• cateye 3y ago
  "The only constant in life is change." Indeed, the rate of technological change seems ever-accelerating, leading us through cycles of adaptation and learning. While this constant shift may sometimes be seen as tedious or even chaotic, it's also a reflection of our growth as an industry. Each new tool or practice arises from the shortcomings of the previous ones. Serverless wasn't born in a vacuum, it was born out of the limitations of servers. Microservices weren't born out of nothing, they came from the monolithic application era's shortcomings. The key lies in discerning between meaningful progress and trend-induced churn. Not every new tool or practice is necessarily an improvement, and even those that are may not be the right fit for every organization or use case. On a personal level, how can one keep up? Find your anchors in the fundamentals. Concepts like abstraction, encapsulation, concurrency, state management, and others are applicable across a multitude of tech stacks and paradigms.
• dathinab 3y ago
  While there are much better parsers by now XML has some major problems (in no specific order): - it's quite complicated with a lot of niche issues many parsers don't handle nicely - it has serious issues when it comes to semantic vs. non-semantic white spaces, this happens to not matter for some applications does does matter a lot for others - it is in a uncanny valley between being good for human writing and good for machine consumption, for most use-cases there are objectively better formats - people did ran into endless problems with it. Some at it's fault many more not but still associated with it. This gave it a negative image outlasting hype cycles. - it needs to compete with JSON, which in many use-cases fails by default no matter if it's good choice or not - compared to some alternatives there are often way too many ways to encode the same thing, this is also an issue e.g. for JSON, but way way worse for XML - non us-ascii string encoding..., it's old enough for there to be a bunch of legacy messiness, often you can ignore it but not always Now there are use-cases where XML was and is used with successful and I don't see that changing, but a resurgence of XML in other areas would IMHO be a failure of the IT industry to not learn from past mistakes. For data serialization (even if human readable) you want native support for maps and fully encoded strings (e.g. JSON), for configurations you most times want something more simple (sadly YAML fails this due to some subtle issues). For huge datasets you probably want something more compact then XML. Still there are some good use-cases for XML where it's many machine processed, but not only, not very little amount of data but not a huge amount, need for a lot of annotations, need to coordinate changing schemas of "cold stored" files of that format between different companies, mainly used for encoding in a file, not between life communicating servers. I.e. UI encodings without a custom language, some but not al cases of scientific data, dumps of complicated configurations normally never writing by humans, but sometimes inspected by them. But please never again tightly couple it with security schemas, especially the way strings are handled in XML makes that a terrible choice for such use cases. And it's also not a grate choice for any life communication between programs.
  • ShamelessC 3y ago
    Article isn’t really about XML, fyi.
• makach 3y ago
  The brutal truth is that the "pro-dev" is aggregating all these buzz words in the application you are destined to take over. It's not him that will maintain his academic overly enthusiastic code base. Once he has completed his task he will brush some documentation off his shoulder and condescendingly assume that everyone smart and capable shall understand the produce of his loins. heed the buzz-words. simplify your solution and beware developers incapable of cooperating with the entire team. Predictability and long time consistency equals professionality.
• ChicagoDave 3y ago
  I absolutely love this rant. It’s why as an application architect we get “it depends” drilled into every decision we make. But I’d also add one of my own observations. I believe U.S. based companies tend to look for scapegoats when building software, so they lean into packages and products. Outside the U.S., you see much more raw architecture and principle-based design, believing that if you craft a solution based on the actual needs of the business, your outcomes will be significantly better.
• revskill 3y ago
  Programmers, in reality, is like trader. We jump on hype, just like you jump on a new coin, pump, dump happens, of course. So, it's reality, what's future is based on usefulness to the masses (enterprises).
• yodelinghambone 3y ago
  Any interaction I've had with XML has been a negative experience. Can someone explain to me how JSON is not superior in every way?
  • phlakaton 3y ago
    I'll give just one obvious one: XML is far more resilient against syntax errors. Miss a closing tag in XML and a clever parser might even be able to infer it. With JSON, you know you're missing a brace at the end, but you have no idea where it should go.
• lawgimenez 3y ago
  I’m surprised with the lack of mention of Android development.
• eliasmacpherson 3y ago
  Reminds me of this old skit article about Docker, "It's the future": https://web.archive.org/web/20160817120102/https://circleci.com/blog/its-the-future/ https://web.archive.org/web/20160817120102/https://circleci.... Discussion here: https://news.ycombinator.com/item?id=12303075 https://news.ycombinator.com/item?id=12303075 The single greatest thing about minimalism is the ease of replacement and maintainability in comparison with maximalism, to my humble experience. "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." ― Antoine de Saint-Exupéry
• robertlagrant 3y ago
  I can't help but think, "Finally, someone exaggerating the reason why technologies are invented."
• Tade0 3y ago
  Akin's laws of spacecraft design apply to software engineering with only minimal adjustments: https://spacecraft.ssl.umd.edu/akins_laws.html https://spacecraft.ssl.umd.edu/akins_laws.html For 39. replace "launch vehicle" with "technology". In any case after over a decade of "web development" (as it was still called back when I started out) my position is that to an extent we need this sort of circus because it's the only way for businesses to invest into moving this field forward. Take for example the titular XML: largely hot garbage in applications where we learned to use JSON now, pretty damn solid as a text representation of file formats, 5024 pages of OOXML's specification notwithstanding. The author points that out as well. If you want less of that go work in a financial institution, where you'll find unironically rock-solid Java 8(or perhaps even 11 nowadays) and associated frameworks.
• alkonaut 3y ago
  Doing any kind of development apart from web, is bliss. It doesn’t even matter what other genre of software dev it is. Embedded, mobile apps, desktop, PLC, HPC, … just so long as you stay out of the whole front end/backend/cloud/browser nightmare, these cycles are much less noticeable.
• b7r6 3y ago
  God damn I miss Naggum. "In many ways, the current American presidency and XML have much in common. Both have clear lineages back to very intelligent people. Both demonstrate what happens when you give retards the tools of the intelligent." The list is just too long now: OOP, COM, CORBA, UML, Scrum, Microservices, JSON RPC, ReactJS, writing shit in JavaScript when you don't have to, LangChain, all of it. It's just fucking stupid and wrong and frankly the software business isn't for everyone. It doesn't make you a bad person that you're not serious about this shit. https://www.schnada.de/grapt/eriknaggum-xmlrant.html https://www.schnada.de/grapt/eriknaggum-xmlrant.html
• dicroce 3y ago
  Never heard such a good argument for why we should all be replaced by AI.
• akudha 3y ago
  Genuinely curious, not being sarcastic or cute here. With hype everywhere, and job ads filled with buzzwords and acronyms, how does one choose what to learn? Something that is sane, that is joyful to work with, that will be around for at least a few years, but also puts food on the table? I suppose SQL is going to be around for a while? Any other recommendations?
  • fifticon 3y ago
    We ask 'does this bring joy?'
  • TillE 3y ago
    If you're a software developer, cultivate deep expertise in one or two popular languages that are likely to stick around. Everything else - the hot new web framework or whatever - is downstream from the actual language, and is easy enough to pick up. If you're in IT operations I guess it's harder to keep up, because everything is different.
• foxbyte 3y ago
  It's interesting to consider the hype around XML and MongoDB. But it's also crucial to remember that each tool has its pros and cons and we need to choose wisely based on our project's needs. Hype isn't always a reliable indicator of utility ...
• jononomo 3y ago
  Fantastic article. I was on the isomorphic JavaScript hype train for a couple of years with Meteor.js and that really burned me. Now I can't stand JavaScript and I like Elixir and Python.
• Temporary_31337 3y ago
  On the specific point of XML being for everything it was not meant to be. It was a document format and the extensible part meant you could have an island of SVG in your XHTML and it was all still a well formed XML. But some people ran away with the idea and extended it to uses that should have never been done in XML such as streaming.
• brightball 3y ago
  This hype cycle was at the very start of my career. “Java and XML! Portable code and portable data!” was the big slogan. I took a course on XML, DTD, XSD, XLST, JAXB, etc. It was everywhere. There were tools specifically to design XSD schemas, so that you could generate classes for them using JAXB and validate the data. SOAP and XML Web Services were everywhere, using WSDL which was a glorified XSD. The WSDL would allow you to generate a client library and validate the data prior to making an API call. It was pretty useful and I still prefer it to REST, despite its warts. Such a distraction though. All of the obsession with perfected static types and schemas got in the way of any productive work. When I discovered how much more I could accomplish with a dynamic language and a SQL database I never looked back.
• sickcodebruh 3y ago
  Doesn’t this strike anyone as overly cynical and just… incurious? Yes, hype and trends are obnoxious, there are individuals and organizations that reflexively seek sexy tech and apply it wrong, but isn’t this also part of how we find things that work and things that don’t? It’s easy to run through decades of tech trends and present them as the only things that dominated the industry, just like it’s easy to rattle off one-hit-wonders or movies that flopped and claim that the arts are dead. But I remember Apache fading in favor of nginx. MySQL being shouted down by Postgres. Frameworks like Rails and Django becoming popular over the LAMP stack (with the aforementioned A and M…). Docker over Vagrant for dev environments. TypeScript, unidirectional data flow, the decline of OOP. I can go on and on and these are just the ones that spring to mind immediately! I’m still very much a “choose boring tech” guy. I also sometimes feel frustrated by how fast technology changes and how the winners of hearts and minds are often the result of marketing effort, not good technology. But unless you’re a technology blogger, you probably don’t need to be bothered by this. New tech emerges for a reason. Some of it will be overhyped, some of it will be unfairly ignored, some things will win and some will lose. I feel fortunate to live in a time when there’s so much enthusiasm and creativity for new ways to solve old problems.
  • afry1 3y ago
    I don't know about incurious, maybe "extreme". A lot of the tools, techniques, etc. mentioned in the article aren't appropriate for ... well, most websites probably. But they do have their roles to play in large, complicated systems.
• commandlinefan 3y ago
  > it inspired teams everywhere in the world to make things harder on themselves Actually, this has an easier explanation: usually the people doing the planning aren't the people doing the work.
• vpastore 3y ago
  [dead]
• zagrebian 3y ago
  It is probably not the best idea that your website’s start page is a full-screen dialog that cannot be closed without allowing JavaScript.
• mempko 3y ago
  I started coding in C++ back in the 90s. The secret is, if you wait long enough, things become popular again. Thanks to webassembly, I can code fast web apps in C++. And of course webassembly is just a hybrid of a java like runtime + ActiveX. Fashion has cycles!
• davidy123 3y ago
  It (or maybe a new version of it) is the future. But people got bored and justiably frustrated in how clunky it is, because it can be and do everything. As often happens, people started abandoning it just as it was getting really interesting - w3c xlink, the hypertext/data document of our dreams, and we're not talking about some neato mostly-great thing someone came up in popular language, rather a set of precise standards with implementations in every language. But in its era, the current "get er done/yagni" startup culture was really kicking in as people realized it was a hassle and less immediately rewarding to think of the web as a standards based platform past using the browser as a client.
• marcelr 3y ago
  So.. there's a lot to unpack here. There's a few ways to interpret the "hype-train" of mainstream development 1 - it's gonna solve all my problems 2 - everyone else is talking about it so I should learn it 3 - incremental ad-hoc solution to a real problem someone encountered, may or may not apply to me Many juniors are guilty of 1 & 2, few make it to realize that most of the time these lie in camp 3. There's a real use case for this, but you have to train your mind to not see it as a silver-bullet or worry about hype train. The difference between academia & industry is that academia tends to develop general solutions to problems few if any people encounter. The best of the industrial programmer will take the bits of academia & try to make our ad-hoc solutions slightly more general while staying practical. This is endless, and depending on your perspective its fascinating OR exhausting. To me its a bit of both, but with distance & the realization that I do not need to care about virtually any new tech, I usually lean to the fascinating side. As a language designer its humbling to see the milage people get out of many half-baked solutions in the JS ecosystem, and a sign that generality isn't the whole picture.
• uhtred 3y ago
  Wondering why web apps that do genuinely need to be react based or similar because of complex interactivity aren't being built as cross platform desktop apps using something like GTK. Performance would be much better, there would be a rich set of ready to use GUI components to use etc
• shortrounddev2 3y ago
  All development frameworks and new tech are about reducing the amount of labor required to produce outcomes. This can mean reducing the amount of up-front labor required (running JS on the frontend and backend means that junior devs only need to know one language), or reducing the amount of refactoring required later on (more structured SPA frameworks like angular turn everything you want to do into a matter of boilerplate CRUD). In both cases, it's about having a uniform pattern for anything you want to do so that onboarding new people to the project is easier. Want to get some blog posts for this view? Inject the IBlogService. Want to get a list of all authors? Inject the IAuthorService. Without having read the docs, you can starting typing "I{ThingIWant}Service" and your IDE will pop up whatever services are available. I see a lot of old school developers complaining about the abstraction of frameworks and how it was simpler to code things in CGI, PHP, C, etc. when you were closer to the machine, or at least were managing the state of the program manually and not through some framework which uses reflection and @Decorators/Annotations everywhere to declare things. But such systems mean that whenever you bring some new junior dev on, they have to spend 6 months learning how your system works, being totally useless to the company in the meantime (especially since college doesn't seem to teach useful job skills anymore). As it is now, even though there's a million different fad frameworks out there, they're mostly all about the same. I can easily transition between nestjs, .net mvc, or spring boot because they all imitate spring. Frontend frameworks are usually about the same too, and sometimes the frontend is shockingly similar to the backend (like Angular). I'd much rather work with the banality of angular/react CRUD/boilerplate than have to write another line of unframeworked PHP, or manually write another Apache2 routing config file ever again. That's not to mention operations stuff: CI/CD, despite all of its attempts to boil all possible program states and logic down into infinitely complex declarative yaml files and containerizing everything, is better than the alternative: SSH'ing into a server, manually dealing with system library dependencies, and copying files into /var/www
• pier25 3y ago
  After doing web dev since the late 90s I've seen plenty of trends come and go. It's all about tradeoffs. There's no silver bullet. Analyze the problem and then decide on a solution. People praise the last hyped trend as the next coming of Christ until they find out the drawbacks and move on to the next hype.
• prabhu-yu 3y ago
  I think, Python Dictionary format can represent structured data well. i.e., I need to re-present some data, I use Python dictionary format, then YAML, then JSON. Possibly never in XML as I feel the tags simply redundant, verbose, prone to missing when we are constructing with hands.
• somat 3y ago
  I recently had a project where I was munging some vendor xml so I get to have an opinion(python + lxml) xml is not that bad. until you add namespaces. then it gets ugly real quick. But I think the fundamental problem of xml is that it is trying to be two things. a markup language and a structured data object format. It started life as a markup language(text with interposed tags) however the lure of a well defined, human readable, flexable format proved too much and people started using it for object storage(mostly tags, never mixed tags and text)