zmxz

European here. You're spot on with your question. Europe is an extremely hostile place to start a business compared to USA.

USA embraced capitalism and is geared towards proving concepts FAST and enabling networking. I love that about USA and I miss that in Europe, when it comes to IT/Tech sector in particular.

I'm not aware if Europe produced anything of significance in the past 30 years, we're lagging heavily behind USA/China and that's a fact. One could argue that Linus Torvalds is European hence Linux === European but I won't resort to such petty claims.

We produced very little value. We're having issues due to language discrepancy. Even though a lot of people speak English, it's often the case that we Europeans aren't able to communicate as well using English as we can in our native tongue. The lack of unified language is visible. The diversity in culture drives people to favor their own, we're bad at teamplay (this is from my personal experience and I am guilty of this).

There's many valuable lessons we could have learned from USA but we failed to apply them. We have various freely available systems that are great at, say, education - but education means nothing when it's difficult to apply it once people are done with it.

I worked with plenty of people from USA and I had huge prejudices towards them, in terms of "they talk a lot" or "they are not as competent, they are really slow when it comes to pumping out code" but I learned I was wrong to the point it's not funny. If anything, USA is really good at starting and pushing projects out that actually work.

Ultimately, do we even have a microchip factory (we might, but I'm unaware of it)?

Sorry for the wall of text, I just wanted to explain my POV and agree with you.

Personally, I'd love to see movement in EU's tech sector. We're 30 years behind USA in tech. I won't touch upon quality of life or similar topics because I'm interested in exploring technology.

Looks like Elon was too busy farming in Path of Exile and now Tesla's customers have to wait until he asserts he's the god's gift to gaming first.

It's obvious you have no idea what ZTS build of PHP does and you're just spewing nonsense at this point.

Creating a few thousand "new object" takes less than 5 msec. Test it. I have.

FrankenPHP uses a Go-based balancer that distributes requests to array of pre-started workers. Just like PHP-FPM does.

If you already used PHP's parallel extension, then you should at least know the difference between thread and process instead of typing buzzwords, thinking it makes you look cool if you use them :)

It doesn't even depend. The underlying engine that executes opcodes is the same. Minimal speedup from not having to execute several "new objectname" commands isn't even a drop in the sea when it comes to what servers do.

I, for one, would love to be wrong about this and that FrankenPHP with all the other alternative runtimes actually brought benefits.

There are claims this is faster. It's not. I used it, together with other "alternative" runtimes which are just PHP command line interface long running scripts with some sort of task distribution balancer in front. Just like PHP-FPM is.

The apparent speedup comes from the fact it's not shared-nothing, meaning that objects from previous requests (and variables) are persisted and present in subsequent requests. This makes it work exactly like Node.js, removing the wonderful part of PHP which is that it automatically cleans up all the crap devs created and creates clean slate when next request is to be executed.

All of these "alternative" runtimes are false positives, because they're quick for first few requests but get slower and slower for the subsequent ones. Then, the workers are killed and restarted (precisely what PHP-FPM does too).

Since there's no new engine behind executing PHP, the only way FrankenPHP (and others) can yield any performance is when they're benchmarked against misconfigured PHP-FPM (opcache off, JIT off, persistent connections off).

It's not my cup of tea. I like that there are attempts at doing <something> but turning PHP execution model into Node.js execution model isn't the way to go.

I find it cheaper to throw a few bucks at stronger hardware compared to risking accurate execution to become flaky because shared-nothing is now unavailable.

Function has 3 arguments. It's documented. Use cases are documented. You are trained. You ask for.. even more protection? From what? There's a limit to laziness, it takes more time to do this word-warrioring on HN than to learn how to use the function correctly and how to create a wrapper around it that serves as the protection you seek.

This really isn't that hard, we're not trying to travel to Mars.

Check this - if it's something important.. don't forget it and implement something called "function" that would pass the third parameter by default?

Anyone who is not capable of taking care of what you called footgun in a way where they automate - that person is not serious.

If there's a pretty huge problem - manage it. That's your job as programmer. If you're lazy, sloppy and prefer whining online over being proud of your work - there's no programming language that will take care of that for you.

No, it's not a function that causes it. It's the dev who is sloppy and causes issues. Would you blame the scalpel or brain surgeon for mishap while cutting important bits in the brain?

What kind of logic is this, to blame the tool because you have no clue how to use it?

So not knowing how to use a function in programming language is equivalent to a car exploding? Man, your logic is broken in ways that actually hurt.

The problem is that you're trying to use PHP as if it's a different language.

If I have to deal with files, I'll create a class and I'll combine functions file_exists, is_file, is_writable, file_get_contents, file_put_contents (and new fsync) in conjunction with stream_context_create. I can even get the errors that OS spits out and test for what exactly went wrong, but you obviously ignored that and gave up. I can tell you used the language sporadically, not professionally.

You're taking a small, localized issue that arose, while your job as programmer is to get around idiosyncrasies in programming languages with the focus on achieving the end goal.

I've a list of terrible things that PHP does but I have one for JS/TypeScript/Go/Rust/<you name it>.

My job is to know these and achieve goals, not to criticize languages because file handling in it is not the same as in C++ and language didn't fire up 50 AWS instances to spam X.com with messages in hopes that I somehow notice them.

But I didn't forget the third strict parameter, because I'm diligent in reading documentation and at my job.

Was that everything? You basically state there's a problem because you didn't use the function correctly and language didn't fall head over heels to stop you from doing silly things due to slopiness?

P.I.C.N.I.C.

"there is no way I can get an error code from fopen()",

You can, it's via `error_get_last()`. We've had that for 17 years..

Can you share precisely what "mishmash with a bunch of hidden landmines" is?

It's hard to trust a stranger from internet claiming something, but we are in IT so it should be relatively trivial to prove your claims, right?

Exciting news! Glad to find out Serbia was the pioneer and helped create Apple!

I'm one of those who used Internet Explorer 5.0 and was there to complain about Internet Explorer in general. I'm not sure why you are amazed with Chrome transition, but let me give insights from experience.

We had Firefox 0.3 which was very, very slow browser but still much better than Internet Explorer. There was a lot of mental gymnastics involved to get pages display at least similar for both browsers.

When Chrome 1 was released, it was absolutely awesome. Minimal interface. Focused on browsing. Incredibly fast, it just executed JS stupidly quick and we could create web app interfaces that didn't lag

You can still download Chrome 1 and see what it's about. It was basically what users wanted: supports more CSS features than other browsers, starts fast, executes JS fast, provides adequate developer console, renders pages correctly.

It took all of us by storm because it was genuinely good software. That era was the era of good software, not spam advertising.

Today, in 2023. this is not true any more and you are entirely correct when asking why people would use Chrome. Answer is: laziness, lack of info, apathy, lack of knowledge.

This protocol seems to also depend on JS

It doesn't mention any dependency on JS, there's pseudocode in Python to demonstrate generating/using the token.

but some web apps use JS and sessionStorage on browser to store session token instead of using cookie

This is particularly strange, I've seen that frontend apps do this but I can't understand why because it's error prone and excellent attack vector. It boils down to emulating cookies, having to have some sort of request interceptor that includes the token on every XHR/fetch to serverside and another interceptor that saves updated token on every valid response from serverside. It seems like a misguided attempt to rectify problems that stem from CORS handling or shortsighted design where auth was bolted on as an afterthought.

then it's gonna leave a bad impression

My company's frontend team (comprised mostly of people who believe anything written) jumped the wagon on Bun.

After a few days of working with it, it turned out that Bun isn't really faster in real world scenarios.

This brings up the question - why market it as so much faster then?

Many frameworks and tools market themselves primarily as faster than $otherThing but it won't fix suboptimal code, wrong choices for data structures, silly things like "let's select * and sort in browser". When you remove those mistakes that bad devs make, it turns out node/deno are more than fast enough. What we need is less bloat, more engineering and no lazy development by "packagemanager install lib-that-could-do-my-work"

So are you saying that you didn't see a salary difference between PHP roles and C# or Java roles?

No. What I said was that language was not as relevant as the complete engineering ability that makes someone a valuable (financially viable) employee.

but smart/good developers will find that CV/Salary pressures steers them away from PHP

I never met a person who entered world of IT with the criteria that you highlighted there. My recent experience shows that people enter IT/development based on salary alone, not based on research they conducted taking into account industry they'd work in, language features etc.

If this case you wrote of actually existed, world of software would be a place of much more high quality software and not of "it barely works" projects that resemble Frankenstein's monster.

So it wasn't the language, it was you? But it was the language?

I was job hunting this year, I'm a long-time PHP developer (since '99).

It wasn't the language, it's everything around it. It's knowing frontend and how it works, it's knowing about cloud/operating systems, databases, 3rd party integration, IAM, SSO and the list goes on.

These skills are applicable everywhere, next to any language. Compensation I was offered revolved around the ability to be non-invasive towards younger teammates and to provide education with emphasis on critical thinking. During the years I've done this job, I learned other languages as well and I can safely claim that initial language one learns has huge impact but it's learning additional skills that makes up for a valuable employee.

In the end, knowing C# but not knowing PHP bears little insight into whether you're capable of listening about a requirement and coming up with a solution that satisfies the need, code it in such a way code can safely die one day and make in such a way that additional people in the team can jump in and manage it.

I also found a lot of job offers and opportunities. My previous engagement was insurtech/fintech, there's quite a bit of PHP used there (and it works well).

Wordpress, Magento, Facebook - these aren't the only places where PHP is/was used, the world we don't hear or read about is larger than the blogo-investo-googlesphere we're used to reading about.

Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider

No, the whole point of client-side rendering is to apply parasitic computing and offload the server by having the client perform work it can thus saving the bandwith and compute power.

Next benefit is application that's "snappy" and works well, which is what almost never happens sadly.

that’s why you have JWTs and stuff like that.

No, you don't have JWT and "stuff like that" because of this. JWT is for offloading databases so you don't have to talk to a DB on every request since you can verify the token via signature check and thus implement distributed services that don't have to talk to central authority to authorize a request.

where state is able to be maintained per user usually up by the same thread on the same physical server

And now you're trying to sound smart by adding servers and "threads". I've a feeling you're pulling my leg right now so I'll excuse myself since you started spouting absolute nonsense.

Why would the elements HAVE to be loaded for different roles? You're talking as if every single client-side app approaches authorization and authentication the same way and that's just not true.

There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface.

The choices related to displaying appropriate elements based on current user's role that's tied to entire logic of the app has literally zero to do with security.

SSR has nothing to do with roles being sent and what a user can see. It's as related as Jupiter is to a brick.

In limited topics I took part on SO, what frustrated me the most were the "users". I deliberately put word users in quotes because I worked as a consultant and often saw guides on how to ask questions on SO (i.e. use an account with female name and picture, deliberately misspell words/interpunction). There was this Magento company and I was consultant for their (UK) client, one of the devs gave me the tour of how they use SO.

What was frustrating is that day in and day out, similar questions were asked - ones that are googleable.

One day I received a comment from such "user", under a question I answered and explained in detail. The "user" went to discredit me, without arguments or links and was pretty rude through all of the misspellings he did to avoid some automatic triggers. I replied rudely as well, asking him to read other people's answers before discrediting and providing no info.

Result was that I was sent to "cool off" for 2 weeks, and was given a speech from mod as if I was a child. At that point SO changed their ToS and claimed that all content was theirs, including answers I provided.

And that's where I departed from SO because from my experience - I was free debugging service for various agencies who went a little bit overboard with claims of their experience and in case someone was rude to me - I get no protection, however if I'm rude to "users" then I get slap on the wrist.

Working for free, being patronized, interacting with people who are too lazy to read - that were my reasons for abandoning SO.

Besides, when it started - all of the big questions about nearly every language were covered fast and there was very little to do except write SQL for other people and get praise for it as form of payment.

Why would you imply I tried to say anything against frameworks in general? My comment was specifically about Laravel because it was singled out as a great framework.

To indulge you, about good frameworks: Symfony, Aphiria. Aphiria in particular because it's small, cuts down on repetitive tasks and doesn't reinvent the language with things like "Macros" or abuse of Reflection or mishandled patterns like singletons - all of which Laravel gets wrong.

Symfony because of active development. Every large tool is bound to be bad at something. Symfony is no exception, however it's not an advertising platform - and Laravel is an advertising platform. Sane choice is to use the tool with maximum benefit and least negative impact.

Laravel is prime example of a bad framework trying to reinvent the language, educating young developers to use it and its ecosystem and to never get out of the stranglehold.

I'm not sure what made you think it's an "appropriate" framework, it's literally antipattern on antipattern and it's not even the worst thing, neither is the fact it's 10x slower than anything else out there - what's worst is the blatant lying, bunch of security issues and using it as an advertising platform to push subpar services onto devs stuck with it.

Forming an understanding of the basic concepts rarely happens in 10 minutes

It happens when you're working and have sufficient experience, knowledge and practice when it comes to web, programming and HTTP.

It's impractical, irresponsible and insane to have anyone other than a person with sufficient knowledge to work on application / API that supports OAuth and for person with proper expertise - the protocol is simple because it's literally the bare minimum needed to establish secure request/response pattern.

I work with SAML 2.0 and OAuth2/OIDC, I deal with programmers and other people within areas of API, authentication, authorization and it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. But, I did interact with several brilliant people with far less experience compared to me who did get the purpose of this protocol and who implemented it successfully and have done so quite fast.

What the wall of text means is that where there's will - there's a way. You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.

You need 10 minutes of focused reading to understand what the purpose of the protocol is and you don't need all of the OAuth RFCs to implement the bare-minimum nor do you have to support all the grants available.

Most people I worked with don't understand the purpose of OAuth and that's what the 10 minutes should be invested into.

Or, you can, you know - nitpick and live in the world of gloom and doom where everything sucks.

Correct me if I'm wrong, but what you're implying here is that PKCE and URI allowlist are the same feature because if you specify URI allowlist while initializing the flow - it somehow helps public clients to prove they're the apps that initialized the flow and are the ones who are finalizing it?

Could you please expand on that thought, I'm genuinely curious if you actually might be right or whether this assumption of yours is how we get security holes.

It doesn't suck, it's literally bare-minimum what you need in order to securely retrieve the token.

It's by far not THE worst, you're spouting total nonsense. What's THE worst is lack of attention, and one needs quite literally 10 minutes to read the RFC and understand it's fairly simple protocol with minimal number of parameters.

I'm sorry you had a hard time with OAuth, but have you ever thought the problem is in you and not the protocol? Reason I'm asking is because you declare it sucks but you are not providing any kind of alternative of how it would not suck.