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

41–50 of 408 posts

Re: XML is the future

#41

Post by senttoschool »

hn_throwaway_99 wrote: post #29
senttoschool wrote: post #2

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 ded…

FWIW, after using serverless technologies in both AWS and GCP for years, I think the cloud vendors have largely fixed most of the issues you're complaining about. Few examples: 1. Amazon provides things like RDS Proxy, which is essentially a hosted version of pgbouncer, and Aurora, essentially a "serverless postgres" - no need to manage your own server for connection pooling. 2. Cloud vendors have largely fixed the c…

My main points are Vercel/Next.js focused.

1. That's extra cost and complexity and it's still a dedicated server.

2. If it's a min scaling of 1 and it processes many requests, isn't that just a server?

3. In the context of using APIs written inside Next.js for your mobile application.

4. Sure, Cloud Run is nice. I remember using Docker with Cloud Run as well. But it's a bit different than my main gripe with Next.js/Vercel.

Re: XML is the future

#42

Post by re-thc »

hardwaresofton wrote: post #17
gnulinux wrote: 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…

> 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…

> - What's the difference between CGI scripts and Serverless?

> - What's the difference between Terraform and Ansible?

Marketing and VCs

Re: XML is the future

#43

Post by deaddodo »

noduerme wrote: post #19
gnulinux wrote: 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…

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…

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 industry standards at app/tech companies and c) you won't get the same treatment as an engineering focused company.

The latter two are very much variable by company, but those are the general trends. They'll also vary in importance to different people. The former item, however, can be just as burn-out/tedium prone as tech company stack whiplash.

Re: XML is the future

#44

Post by Solvency »

senttoschool wrote: post #25
lijok wrote: 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…

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 can still provide benefits such as reduced network hops and improved response times.

4. Serverless architectures can offer advantages for scaling, but it's important to optimize load speed regardless of the architecture used. Serverless doesn't inherently add 3-5 seconds to loading times.

5. It can make sense to use Vercel's serverless APIs built inside Next.js for mobile apps, depending on the specific requirements and architecture of the application.

6. FaaS pricing can vary based on usage and provider, but it doesn't necessarily have more predictable pricing than using dedicated servers. Both options have their own pricing models and considerations.

7. While serverless functions are useful for many scenarios, there are certain tasks like cron jobs or persistent queues that may not be easily achievable with serverless functions alone. However, there are workarounds and alternative solutions available.

8.Building an entire stack on a FaaS like Vercel with Next.js may have implications for switching hosts compared to a Docker setup. Docker provides portability and flexibility, making it easier to switch hosts, whereas FaaS platforms may have specific dependencies or configurations that require adjustment when migrating.

Re: XML is the future

#45

Post by senttoschool »

Solvency wrote: post #44
senttoschool wrote: post #25

Earlier quoted context omitted.

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…

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?

Re: XML is the future

#46

Post by deaddodo »

rqtwteye wrote: post #15
lastyearmodel wrote: post #14

Earlier quoted context omitted.

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.

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…

It's not a career killer, it's a specialization. Focusing on nodeJS JS/TS frontend+backend stacks will equally disqualify you from .NET/Spring shops (against an equally qualified applicant, at least). The same goes for making the switch to gamedev or systems dev from many years webdev (you can do it, but you'll probably be dropping back down to a Jr or Mid-level IC position), going from COBOL/Erlang/Rust to another stack, doing Salesforce (or other CRM/specialty software) development, etc.

It's going to happen to anyone after 10-15years in the industry.

Re: XML is the future

#47

Post by plorkyeran »

rqtwteye wrote: post #15
lastyearmodel wrote: post #14

Earlier quoted context omitted.

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.

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…

I think this fear is not entirely wrong, but is significantly overblown. There's a significant gap between what job descriptions ask for and what companies will actually hire. A resume full of dead technology isn't going to help you ladder your way up to bigger and higher-paying roles, but it's also not going to make you unemployable.

A resume full of less-shiny but still relevant technologies, otoh, has a lot of potential. You have fewer places to look for jobs, but you're a lot more exciting to the places which do want your skills.

Re: XML is the future

#48

Post by pyeri »

paulddraper wrote: post #24

> 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!

Re: XML is the future

#49

Post by deaddodo »

seanp2k2 wrote: post #38
preommr wrote: 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…

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.

> 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.

Re: XML is the future

#50

Post by mcluck »

somsak2 wrote: post #40

> 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 deci…

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
Post reply on HN