Hacker News new | past | comments | ask | show | jobs | submit | john_the_writer's comments login

If you measure download cost in time then sure.. If you measure download cost in terms of bytes downloaded, or server costs, then nope. The cost would be smaller to cache.

Not necessarily, compression is really effective at reducing downloaded bytes

In server terms the overhead of tracking one download is going to be less that the overhead of tracking the download of the multiple components

And for client side caching to be any use then a visitor would need to view more than one page and the harsh reality is many sessions are only one page long e.g. news sites, blogs etc


The include logic of include2.html missing everything else would also apply to all other includes.

If a user clicked a link with src="include.css" then it'll be rubbish.

It would be good for static data.. images, css, and static html content.


But that would apply to <header> and <footer> and <nav> too. We could cache them.

I've tried them, and say without a doubt, that I hate them. I've never even really been a fan of intellisence.

I hated co-pilot, it kept guessing and then I ended up spending more time reading and altering.. It took me out of the zone.


blockchained api for AI with anti-mushroom (non-fungible) recursion.

Yep years ago I was a palm-os dev and worked for cities. One government offical told us to switch to windows mobile, because "no one ever got fired buying microsoft"

God, the idea of microservices for humans is nightmare time. I work for a company that runs micorservices, and I can say I've spent days attempting to get everything running on my dev system. One upgrade and I can watch my whole day/week disappear into config hell.

I can't imagine how hard it would be to do this with people. Each working with their own little bubble.

Just the other week someone decided that an api needed a tweak, so they adjusted the code and the tests, but missed one external system. Took 4 days to fix, because we couldn't figure out what had changed. And the team who owned the external system wasn't around. People as microservices.. no just no.


> the idea of microservices for humans is nightmare time.

Works for supermarkets, department stores etc. Companies employ too much red tape in their acquisition processes.

I’ve seen organisations pay way over the going rate for cloud services by insisting on a bidding process and talking to salespeople, when they could have just purchased direct from the console.


If doing your own work requires you to "get everything running on your dev system", are you really working on a service-oriented architecture or was it that your company decided to board the bandwagon and botched the execution?

> people as microservices

No, departments as microservices.


What I'm seeing is more and more web based systems. My kids school is completely browser based. Nothing is installed beyond the browser. Same for the teachers, it's all web based.

That said, I love apple. Nothing else works like their hardware. It's not the best by a long shot, but I'm still able to use a mac-pro 8 years on. And my iphone is 7 years old (for me) and I got it used.


you should start teaching him before he thinks ^above^ is normal, rather than most conveinient for the school, let him know he will have superpowers.

What they likely mean is that MS says "Good luck enforcing this. Have you met our legal team?" Nothing they can't walk around, or drown you in legal fees while they smile.


I like the last bit. Hiring would be a nightmare. Most serious BE dev (myself included) don't have time to learn a new language that I can only use at a handful (or single company). I want the language I spend the most time with to be something I could take to a recruiter (should I need to).

I worked at a place that worked with Delphi, and for various reasons I had to use it exclusively for a few years. No recruiter would touch me. Not until I got some time with Rails did I have a chance to escape.

As a former mobile dev, I'd also like to add, being an app dev vs BE dev isn't just about the code either.. It's a very different way of looking at problems. The skills might transfer, but they're living in different worlds. The language isn't the only obstacle.


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: