Live data from Hacker News

Ask HN: What is the future of back-end development?

news.ycombinator.com

131–140 of 164 posts

Re: Ask HN: What is the future of back-end development?

#131
post #53

Earlier quoted context omitted.

People host their blogs on AWS lambda for less than dollar per month [1] compared to "standard" $5 or so for VPS. How's that a waste of money? Docker and containers are also a paradigm change, but the world seem to have adopted it just fine. [1] https://news.ycombinator.com/item?id=11644042

That's not website hosting, it's comment processing. Lambda is doing input processing , not serving a site. It's clever, although if I just wanted comments I'd just use disqus and spare myself the trouble. S3 is hosting the site. S3 is awesome for static site hosting, in fact. I also use it.

Whenever I'm behind a corporate firewall, which is often, I find that a lot of third-party services like Disqus are blocked. At those times I would have preferred the site to host it's own comments. Generally speaking corporate firewalls block a lot of stuff by default and the sysadmins don't bother to try and differentiate.

Re: Ask HN: What is the future of back-end development?

#132
post #103

Personally I don't see any of that happening - client-side app development on the web is a chaotic mess with no "official" (whatever that means) way of doing things. Throw into that mix the constant reinvention thats going on (yeah can't wait to see everything get re-invented AGAIN when web-assembly comes along), for what constitute incredibly marginal gains in the UI space (the web UI was already way fast enough 5 y…

What do you think about a browser plugin that runs arbitrary .exe code via a plugin? It would have to be sandboxed, of course, but it would give you all of the benefits of a browser distribution model without having to deal with the DOM.

Why not just make QML a media type and a spec that browsers can to implement? Then we can do away with all this HMTL-Page-Is-An-App nonsense

Re: Ask HN: What is the future of back-end development?

#133

Earlier quoted context omitted.

What about the second time you ran a Django app on Heroku? But Heroku is not even in `mabbo's first course (maybe the appetizer?) so that's slightly a straw man.

I don't know how valid that argument is, because the second time I set up a server was just tweaking two Ansible variable files and running the "provision" command.

Sure, but what I was getting at was parent was just having learn how to use Heroku. And while it's true that automation is something you can do yourself, what about keeping the server up-to-date and patched and so forth? Also, repeating myself here, Lambda et. al. are a step further than Heroku.

Re: Ask HN: What is the future of back-end development?

#134
It depends of the QE and next central banks announcement.

If liquidity is cheap on the market, innovations will tends towards KPEX=0 thus more SaaS and stuff will be produced backed with heavy marketing disguised as technical conf/blogs, and corps will have the money to kill competition by buying it. Hence it will not be a truly competitive market.

If there is a contraction of liquidity however only the fittest will survive (low OPEX) and then SaaS, p2p, BaaS will die for more «old school» kind of development based on costing/pricing. Clearly this would mean the return of GUI and all kind of transactional databases and small meaningful data.

The problem with financial markets is they are like weather : hard to forecast.

And for the same reason we know there is a global warming, there is clearly a tech bubble. The more we wait for solving the problem, the more it will hurt.

An industry future is always related to the confidence and money investors have in investing into it to expect ROI.

With the paranoia going on all around the world, expect security to be the next money maker.

Re: Ask HN: What is the future of back-end development?

#135
post #60

Earlier quoted context omitted.

"Serverless" such as AWS lambda removes the ability to take advantage of so many Computer Science principles that are integral to writing a fast backend. From one request to the next there is no CPU cache optimization, in-memory caching, and no IPC to other useful programs. Serverless has it's niche for some tasks such as responding to events, but to do any heavy lifting I'd take a handful of beefy VMs over unlimited…

This is based on the assumption that server without those optimizations is not fast enough. That used to be definitely true in the nineties, but hardware is getting faster while human reaction time stays relatively flat. Hardware is also getting cheaper, so throwing a beefier server is a much easier and better solution than investing months of error prone and non-scalable human labor. Everyone is ditching those beaut…

It matters a lot!

1. Response time. A dedicated machine that stores state in-memory from request to request can respond orders of magnitude quicker than one that does not.

2. Resource Efficiency. 1-2 machines running optimized code will cost less than the 10-20 machines (or 100-200 machines) the cloud provider will have to allocate behind the scenes to run less efficient code.

Re: Ask HN: What is the future of back-end development?

#136
post #131

Earlier quoted context omitted.

That's not website hosting, it's comment processing. Lambda is doing input processing , not serving a site. It's clever, although if I just wanted comments I'd just use disqus and spare myself the trouble. S3 is hosting the site. S3 is awesome for static site hosting, in fact. I also use it.

Whenever I'm behind a corporate firewall, which is often, I find that a lot of third-party services like Disqus are blocked. At those times I would have preferred the site to host it's own comments. Generally speaking corporate firewalls block a lot of stuff by default and the sysadmins don't bother to try and differentiate.

I appreciate the conendrum but I don't think people running the sort of static blog you host on S3/github pages care about overbearing corporate policies.

If I bothered setting up my own blog, I certainly wouldn't spend a bunch of time setting up comments on Lambda just for my two corporate-firewalled readers when I can just use a hosted solution. That is, if I even cared about comments in the first place. There's just much more interesting things to work on, with and without Lambda.

Re: Ask HN: What is the future of back-end development?

#137
I always thought that backend development would converge around a Parse-style API -- basically just CRUD as a service. There's always going to be special bits of logic that need to be executed in certain conditions, so probably some straightforward way of handling that (like Parse's Cloud Code feature) is needed + some way to handle recurring jobs/background workers.

IMO, right now, web development is just an exercise in how complex we can make string concatenation. Getting away from that would be really nice.

Things I hope don't happen: everyone uses lambda for everything, everything happens on a blockchain style network, etc. Those technologies are cool, but I feel like a lot of people view them as a golden hammer.

Re: Ask HN: What is the future of back-end development?

#138
post #90

I don't think WebAssembly is going to revolutionize front end development. What you can do with WebAssembly regarding front-end development is running your Qt/GTK+ type of programs on web. But noone is interested in that. As a matter of fact, current trend seems to be ditching that sort of program on desktops and using HTML/JS/CSS stack for desktops as well (atom, slack, etc) because its much easier to create a top-n…

> because its much easier to create a top-notch UX using HTML stack No, because it's what the hordes of inexpensive web developers know how to use.

> inexpensive web developers

Ask most companies how much they are spending on their web-dev teams and they might disagree with you on that one

Re: Ask HN: What is the future of back-end development?

#139

Earlier quoted context omitted.

Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you ar…

> Push to master. Update production. You monster. You fucking monster. The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code…

I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.

Re: Ask HN: What is the future of back-end development?

#140

Earlier quoted context omitted.

Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just: Put bagel in toaster. Update the db model. Add a migration. Update the viewmodel db model translation in relevant requests. Get bagel and butter it. Commit. Test the migration on a staging db if feeling paranoid, cause it's just adding a column. Push to master. Update production. Take last bite of bagel. If you ar…

> Push to master. Update production. You monster. You fucking monster. The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code…

I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.
Post reply on HN