51–60 of 408 posts
Earlier quoted context omitted.
Can you elaborate on that?
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.
What I desperately need now is JSML so I can free myself from the madness of YAML.
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…
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
Earlier quoted context omitted.
1. Connection pooling can be set up with dedicated servers, but it doesn't mean that all clients like Knex and Prisma do it by default without an external server. Some clients may handle connection pooling internally, while others require external setup. 2, 3. While serverless APIs deployed on the edge can improve latency, it is not accurate to say that the edge doesn't matter if your data is centralized. The edge ca…
ChatGPT response?
> 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.
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…
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.
> 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.
Even the AJAX technology was initially sold as "Asynchronous JavaScript and XML". Today, it's most common to send AJAX requests from frontends and most of them have nothing to do with XML data, but funny how that acronym still stays till today!
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 rarely heard the term post-2010 (same as how "DHTML" died around 2005).
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…
> 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. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that…
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'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…
I've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…
Some possible factors are that the company is not that big and we have a feature list to deliver. We are not VC, so we cannot afford to burn money. The devs churn is low, so we don't need to be attractive to many people all at once.
TBH, I don't like it all the time, but it works and our clients are happy with the results.
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…
You can sort of do the same with JSON though to be fair, in theory, and there are probably tools, but it wouldn't be as tight and then the "XSD" part I am not sure if there is a single spec to go with.
Overall though, I prefer JSONland!