Hacker News Reader

Comment by pcote | Hacker News Reader

>> If something really is unnecessarily complex, better alternatives are likely to arise, perhaps suddenly. (This assumes people are free to choose alternatives, not prohibited by law, for example.)

Not being free to pick alternatives is a common case. There are a lot of dev teams out there that have "approved technology lists". What gets on this list is decided by management and/or a lead architect. It can often be the case that simpler alternatives can't get used because they aren't approved.

This isn't necessarily a bad thing. I could see project management saying "no" to simpler solutions in the name of preserving the stability of a project. Besides, a sufficiently talented team should be able to work within such resource constraints and come up with creative solutions anyways.

View on HN

I've had to face the most horrible people with the most horrible requests.One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible.I understand maintaining a high quality of code.But a major part of the reason for using archaic/available-for-the-past-10-years technology is 2 fold: 1.The HPBs do not want to/cannot learn anything new lest they need to one day code in those languages 2.They do not want to risk 'wasting time' of the sub-ordinates on learning something new which would benificial compared to actually doing the work needed.

Another third situation that I would agree with: Clients sometimes really do not like to trust new technology.An age old anecdote is always brought ; "Why fix what is working?"

Or, "No one ever got fired for picking Microsoft or IBM."

> One of them being a request to "Send a payload with a Get request" . I spent nearly 2 months of my life convincing them this was not possible

I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is not possible is IMHO misleading. And there are sometimes valid business reasons to use (invalid) technical solutions.

I understand your point, but neither extreme (always staying with legacy / always rebuilding) is particularly good.

Maybe one could try to split up the payload into mutiple GET-request packets, then assemble them server-side. >:‑)

don't forget all that storage space in the cookies too!

But the AJAX spec says that if the the request type is GET,the body/data is set to null[1] or am I reading it wrong.

[1]:http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-send

Depends on what you meant by "Payload" in the first comment. I assumed it to mean "a bunch of bytes", so you could have just used URL parameters, which don't have a standardised maximum length, but you can generally rely up to about 2,000[0] or so. If that wasn't enough, you could split up the requests like the other comments said[1], or go full hack-mode and use the cookies[2]. (using a Set-Cookie response header to clear them after the request was made)

Edit: Of course this isn't recommended, but I think the time wasted trying to convince the (seemingly terrible) manager could have been better spent.

[0] http://www.boutell.com/newfaq/misc/urllength.html

[1] https://news.ycombinator.com/item?id=10649995

[2] https://news.ycombinator.com/item?id=10650110

Do the servers really throw away the POST data on GET requests, like the RFC say they do?

Because that would be an easy place to send data.

And I agree with you. I was not even talking about rebuilding.Its more of.Like imagine if you were asked to make up http handling code from scratch in every project.If you were asked to ignore things like Jquery Ajax or Angular or any other such libraries which are designed to make your work easier and no matter how much you do you can never test the robustness of your private library compared to these. My Point essentially is: I do not want to reinvent the wheel every time.There are a large number of wheels in todays FOSS world.When I can concentrate on the things that matter like stream lining the business logic better,Why should is spend time trying to make framework level code work.

To summarize: You do not need to always rebuild or always stay with legacy code.You need to adapt and determine where would you spend more of your development effort.I cannot spend 80% of my time solving problems that the world has already solved

Agreed. :)

Reply on news.ycombinator.com