Live data from Hacker News

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

news.ycombinator.com

151–160 of 164 posts

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

#151
post #112
post #21

Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstra…

Yes. You won't even have to know to code. You'll just press a button that generates the code for you. In the future, all programming jobs will turn into data entry jobs where the programmer will be entering commands into a GUI to generate a button here and there.

I sense sarcasm.

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

#152
post #66

Earlier quoted context omitted.

That's what jsPDF is for.

I've looked at that, but it doesn't fit my use case.

Ya I'm currently doing some client side xlsx reading/writing along with jsPDF. It fits my meager needs but no where near as mature as the server side alternatives.

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

#153

Earlier quoted context omitted.

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.

There are tradeoffs. You don't have to keep Heroku patched, but you also can't tune it if you need something specific.

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

#154

Earlier quoted context omitted.

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

I'm gald you acknowledge that!

But seriously. Pushing to master, AND updating production...where are your unit tests!?!?

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

#155
post #21

Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstra…

This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes) "Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that…

It depends on what framework if any you choose to serve websites with. If you something like Chalice or Serverless then yes you are stuck with Lambda. But you use something like Zappa (https://github.com/miserlou/Zappa) that is basically converts API Gateway's request object to one that is WSGI compatible then you can take your app and skip down the road if you get ticked off with Lambda. The Heroku comparison one isn't a fair one either. The waya you pay for Heroku dynos is very similar how you pay for EC2 or any other VM. You are billed by the microsecond that part is very important and while technically you have a 100 req/s limit to start with it is a soft limit if you ask to have it removed. It is probably more useful to compare it to Google App Engine but even that isn't fair.

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

#156
post #80
post #47

Earlier quoted context omitted.

I agree in principle with most of what you've said here. The server-side is going to be a lot more intelligent in the near future though. My prediction is that every cloud provider is going to have some sort of AWS Lambda service that will eventually become like a server-less toolkit in the cloud. And these platforms could eventually have some augmented intelligence built-in. Essentially, we can't keep teaching each…

Come one, people still stick with PHP because anything else is too difficult to set up on a server. Its been like that for years already.

Not necessarily. Going forward, if we want to get more stuff done, these things have to be abstracted further. We can't continue with this constant learning mountain just to figure out how to do things that can be expressed with a few lines of well thought-out syntax.

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

#157
I tend to agree with development as we largely see will become obsolete or in other words development will/should become really easy. It is primarily because designing backend is very similar to designing a deterministic state machine albeit a large one. And strangely enough, there is much re-invention of that state machine that happens in different projects by different set of people using different frameworks.

And going a step futher - relationship between tables in database should reflect on how an operational/working UI will look like. eg: say blog and comments are two tables and related by foreign key. So in operational front end - it makes sense to see them linked together in say blog page.

Now sprinkle machine learning concepts to it - a relationship between two interlinked tables where 'p' columns are in blog table and 'q' columns in comment table can be represented in 'n' different ways in say 'm' different type of clients(like web mobile etc).

Now is it not possible to link design of whole web app to our voice commands and let some deep learning algorithm figure best schemas, front end, frameworks and even show a demo MVP.

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

#158
post #60

Earlier quoted context omitted.

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…

>hardware is getting faster Considering that the end of Moore's Law is more or less here already, as pointed out in many HN articles, that's really no longer something we can take for granted.

Moore law != progress

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

#159
post #142

Earlier quoted context omitted.

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

Why limit ourselves to a single UI format? Forget the part I said about a plugin. What if browsers were able to load and execute LLVM bitcode natively in a sandbox? You could get native performance in the browser using any language you'd like.

Please get non-Chrome browsers on board: https://developer.chrome.com/native-client

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

#160
post #142

Earlier quoted context omitted.

Why limit ourselves to a single UI format? Forget the part I said about a plugin. What if browsers were able to load and execute LLVM bitcode natively in a sandbox? You could get native performance in the browser using any language you'd like.

Please get non-Chrome browsers on board: https://developer.chrome.com/native-client

Please tell Google to publish a spec for the pepper api and to rewrite it so it doesn't require the blink rendering engine. As much as I dislike Mozilla, I give them props for trying to reverse engineer the pepper api from what was implemented in the chrome browser. But, expecting them to change their rendering engine to support an unpublished spec is ridiculous.
Post reply on HN