I disagree. It is more accurate to say that more working hours is a continuum of productivity. Imagine that you have two nearly identical software engineers. One works 40 hours per week and the other 41 hours per week. Which will be more productive? Very likely the 41 hour per week engineer. Now, if you compare 50 vs 51, then 60 vs 61, and so forth, the productivity gap will become much smaller, possibly hard to measure after 60. I have witnessed a few young engineers in my career with simply unbelievable work ethic and talents that could work 80+ hours a week for months on end. It was amazing to see, and their output was unmatched.
From personal experience, I worked like a dog in my younger years for two reasons: (1) To become a better engineer, you need to make a lot of mistakes and fix them yourself. (2) Much junior engineering work is just time in front of the screen pounding out simple features for a CRUD app. The more that you complete, the quicker you get promoted.
You're making a feely argument for a phenomenon that has evidence. The evidence is that there's a max amount of work you do per week, and the more you work the less you do per hour - and that max amount is below 40 hours, incidentally.
There's effective evidence that people who work 6 hours a day are more productive than people working 8 hours a day, and after 4 hours of active practice, you aren't getting any better.
And on top of this, perpetually tired and exhausted people are not at their best.
Regardless of whether or not you accept that someone working 41 hours really isn't doing more work than someone doing 40 - you can see that two people working 30 is much better than one person working 60. Working people for long hours is mismanagement, at some level.
I agree, but the issue is the impetus behind the statement. The tone which that poster took and the default negative assumption is a negative trait to most hiring managers - especially at the early stage. At an early stage organization, you want your employees to be self-motivated but also open to pull crunchtime if needed (eg. customer escalation, rolled up product launch, pivot)
It's religion. The church pastor would visit the family if a young couple didn't have children within a year to ask what's up.
That being said: I don't get the discussions in this thread. The world can't sustain billions of people anyway. I think decline in the population is a very good thing to happen.
It's silly to think of it as some sort of insurmountable challenge that should be avoided at all cost.
To be fair, an iframe would accomplish that too, but the loaded content would have its own html header that adds to the amount of kilobytes used. So maybe that's the reason.
It's not about performance, it's about load time and the restrictions of your client apps.
Also, you're thinking way too much in a SPA architecture. Using just server side rendering with just a tiny bit of javascript like the article states removes most of the problems you describe like Initial load time and cross team collaboration. The load time of the described websites would be instant, and there is no front end team needed.
ASML is already a good industry leader in it's field of expertise, expanding into other areas like green technologies and defence (lots of finances being freed up for that currently) will be very beneficial. I just read France has found an enormous amount of naturally occurring Hydrogen. Hydrogen powered cars would also be a good area for scientific research. And of course, genetics and medicine in general, the Netherlands started vaccinating poultry against bird flu last month in a world exclusive trial.
That would be nice. I've always wondered why it's so hard to harvest excess solar power as hydrogen gas by electrolysis, from what I understand the process is pretty inefficient. That would also be a good area for research.
I ditched my Google account a while ago. That was tricky because I used it to log in to several websites.
I fortunately also got rid of Facebook a while ago. This gave me a lot more time back. It's difficult at first, because there's a little fomo, but now I am very happy.
I never started with all the other social media. No Instagram, no Twitter. So that makes it easy.
My computers have always run Linux, very happy with that.
Streaming services are next. At least the US ones.
Replacing whatsapp with signal also. I noticed a lot of my contacts are already in there, just not actively using it. It's a question of just starting communications and groups there.
It's quite doable, but you have to really want to "vote with your wallet" so to speak. I think it's a worthwhile sacrifice. In fact, it rids you of psychological warfare, reduces anxiety, costs less money and gives you your time back.
If you think about it that way, it's a no brainer.
You can't be more wrong. You're saying that only logic performed on the client side can be considered an application? State can be stored in the server. Screen changes can be done by loading html, it doesn't need a framework. React is far from crucial for web development, but people haven't learned anything else the last decade. Most front end developers these days don't even know what a template engine is, and some don't even know how to create a website without a backend rest api that spews json data.
I wasn't comparing SSR to non-SSR (Server Side Rendering). As long as you can refresh portions of a webpage (or states of GUI elements), after a user action (button click or whatever), that's fine.
However the reason my Dialog Boxes open in a millisecond, and close in a millisecond too, is because I choose to render them locally. I'm not against SSR tho, as a viable concept. That's a different complex discussion where there are trade-offs to consider.
reply