• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[split] Real time? [CodeIgniter 4 Important Features]

#11
(09-15-2016, 06:15 AM)Narf Wrote: No, that is exactly the opposite of what I'm saying.

You're equating effort to result, and also comparing a comparatively low-level (it being a language; PHP) server-side technology to a framework that has both server-side and client-side components.

Neither makes sense.

The client is irrelevant since PHP only runs on the server. Regardless of which stack you use on the server the client will always be JS.

Due to it's design Node will always be more efficient at handling high throughput. If it wasn't why would every single real-time framework use it?
Reply

#12
(09-16-2016, 11:48 AM)spjonez Wrote:
(09-15-2016, 06:15 AM)Narf Wrote: No, that is exactly the opposite of what I'm saying.

You're equating effort to result, and also comparing a comparatively low-level (it being a language; PHP) server-side technology to a framework that has both server-side and client-side components.

Neither makes sense.

The client is irrelevant since PHP only runs on the server. Regardless of which stack you use on the server the client will always be JS.

Which is why it's an unfair comparison.
I assumed you were talking about NodeJS from the get-go; you mentioned sockets.io later ...

(09-16-2016, 11:48 AM)spjonez Wrote: Due to it's design Node will always be more efficient at handling high throughput.

No, it is simply far easier to use NodeJS for similar purposes, because that's what it is designed for.
Easier to work with by design, not the same thing as more efficient.

(09-16-2016, 11:48 AM)spjonez Wrote: If it wasn't why would every single real-time framework use it?

I just answered that, but here's some extra info from a familiar source:

https://philsturgeon.uk/php/2013/11/12/b...ejs-v-php/
Reply

#13
Narf Wrote:Which is why it's an unfair comparison.

It's not unfair the thread asked if CI would implement this and the answer to that is no.

Narf Wrote:Easier to work with by design, not the same thing as more efficient.

A non-blocking request is the same in any language. Node was designed this way from the ground up and you have to go out of your way to make blocking requests. PHP has evolved in the opposite direction and while they've made great strides it's toolkit is still inferior in that regard. How many third party PHP libraries were written to be asynchronous? What about Node?

I'm not going to argue with you as this is all common knowledge. Most server side languages were not designed with realtime in mind and writing tests in a vacuum is not indicative of real world results. Can they do it? Sure, you can make most languages do almost anything. Should you? The answer to that is a resounding no.
Reply

#14
(09-16-2016, 01:14 PM)spjonez Wrote:
Narf Wrote:Which is why it's an unfair comparison.

It's not unfair the thread asked if CI would implement this and the answer to that is no.

You've made no comparisons to CI.

You quite literally advertised sockets.io, while claiming that PHP sucks compared to it.

And it was not even clear that you were talking about the sockets.io framework, as you said simply "sockets".

(09-16-2016, 01:14 PM)spjonez Wrote:
Narf Wrote:Easier to work with by design, not the same thing as more efficient.

A non-blocking request is the same in any language.

Exactly why you cannot claim that a NodeJS-initiated connection is superior to one created by PHP.

It's networking; languages and frameworks don't change it.

(09-16-2016, 01:14 PM)spjonez Wrote: Node was designed this way from the ground up and you have to go out of your way to make blocking requests.

And while that is true, I don't see how it supports your claims or contradicts mine.

(09-16-2016, 01:14 PM)spjonez Wrote: PHP has evolved in the opposite direction and while they've made great strides it's toolkit is still inferior in that regard.

PHP hasn't evolved in the opposite direction.
PHP hasn't evolved in any way, either direction.

And I've always been angry with that, but that doesn't make its capabilities inferior.

It's APIs have just always been using blocking requests by default and that doesn't make it bad, nor good. Just easier to work with in one area and harder in another, because we're talking about default behavior, not technical limitations.

(09-16-2016, 01:14 PM)spjonez Wrote: How many third party PHP libraries were written to be asynchronous? What about Node?

How is that relevant?

(09-16-2016, 01:14 PM)spjonez Wrote: I'm not going to argue with you as this is all common knowledge.

Sure ... it's so common knowledge, that you even had to talk about some "great strides" that never happened.

(09-16-2016, 01:14 PM)spjonez Wrote: Most server side languages suck at this

What the hell are you talking about?

(09-16-2016, 01:14 PM)spjonez Wrote: and writing tests in a vacuum is not indicative of real world results.

Of course, when a fact doesn't fit the plot - just ignore it.
I realize I probably sound quite arrogant by this point, but seriously, at least I make a logical argument. You're just shouting out your claims as if written in a holy book or something.

(09-16-2016, 01:14 PM)spjonez Wrote: Can they do it? Sure, you can make any language do almost anything. Should you? The answer to that is a resounding no.

"Should I" is something that I decide for myself, not a predefined answer.
But regardless of that, this argument started with you claiming that the result with PHP will always suck, which is patently false.
Reply

#15
Narf Wrote:But regardless of that, this argument started with you claiming that the result with PHP will always suck, which is patently false.

That depends on your perspective and what is achievable with other languages. Every language has it's limitations; JS apps can run offline and PHP will never be capable of that. PHP is better at large file processing, image processing, has a great ecosystem and documentation. They all have their place but there is no one ring to rule them all.
Reply

#16
As of the moment, I don't think this is practical to implement as part of the framework. The framework itself must have event-driven workflow in order to achieve asynchronous features. I don't believe this is a technical difficulty however, previous CI version base users (including beginners), prefer simple and straight forward synchronous workflow.

If ever there are plans to integrate features such as RealTime, I believe the CI community must first introduce and sell the idea of event-driven workflow in the framework itself. Once everyone's comfortable with that, then the idea of having RealTime would be nice.
Long live CodeIgniter!
Reply

#17
(09-16-2016, 03:38 PM)spjonez Wrote:
Narf Wrote:But regardless of that, this argument started with you claiming that the result with PHP will always suck, which is patently false.

That depends on your perspective and what is achievable with other languages.

No, it doesn't.

(09-16-2016, 03:38 PM)spjonez Wrote: Every language has it's limitations; JS apps can run offline and PHP will never be capable of that.

PHP is and has always been capable of doing that.
It's the fact that that browsers run JavaScript that makes offline execute useful with JS and useless with PHP when talking about web applications.

(09-16-2016, 03:38 PM)spjonez Wrote: PHP is better at large file processing, image processing

Is it, really?
Not that I care, but unless you can't open a file descriptor in JS, there's no inherent limitation in that regard.

See, this is my problem with your continuously made-up claims - you're stating that one language is better than another language in dealing with language-agnostic features.

If you were to say that PHP is better at OOP and JavaScript is better at event-driven programming, we'd have no problem as these are indeed language-level concepts. But you're not doing that; you're making comparisons akin to "biologists cook better than mathematicians".

(09-16-2016, 03:38 PM)spjonez Wrote: has a great ecosystem and documentation. They all have their place but there is no one ring to rule them all.

Indeed, and that has never been the question here.
Reply

#18
(09-16-2016, 03:38 PM)spjonez Wrote:
Narf Wrote:But regardless of that, this argument started with you claiming that the result with PHP will always suck, which is patently false.

That depends on your perspective and what is achievable with other languages. Every language has it's limitations; JS apps can run offline and PHP will never be capable of that. PHP is better at large file processing, image processing, has a great ecosystem and documentation. They all have their place but there is no one ring to rule them all.

To further Narf's point, it wasn't that long ago that JS apps couldn't do much if you were offline. It also wasn't that long ago that most programmers held the opinion that JavaScript was useless.

Most of the capabilities which everyone has been discussing in this thread have nothing to do with the programming language, and everything to do with the run-time environment and libraries being used with the language. Node.js was not the first platform for server-side JavaScript, it was simply the first popular platform for server-side JS (was ASP the first? I don't know, but it was the first place I encountered JS on the server, years before node.js and in a codebase which was old before I started working on it).

JavaScript is not inherently blocking or non-blocking, but its use in the browser and the simplicity of passing functions and closures around make most JavaScript developers more comfortable with developing event-driven applications, and many developers eventually become aware of when they've created problems for themselves by blocking execution in their environment.

It is not JS that makes node.js non-blocking, nor does it prevent the developer from creating applications which block execution. What makes node.js non-blocking is that it uses a cross-platform library which performs "non-blocking I/O" by utilizing a combination of event-driven programming and a thread pool. The same library can be used in PHP. The library is written in C.

Before someone starts talking about why C is better/worse for asynchronous/non-blocking programming, it's important to note that C is commonly used for cross-platform development simply because native APIs are available to programs written in C in the most popular operating systems.
Reply

#19
Narf Wrote:Not that I care, but unless you can't open a file descriptor in JS, there's no inherent limitation in that regard.

Work with compressed files or perform any computationally expensive image manipulation. Or try to do any serious math because JS sucks at precision.

mwhitney Wrote:It also wasn't that long ago that most programmers held the opinion that JavaScript was useless.

A lot of developers still say that. I'd say that opinion is short sighted.  PHP doesn't have the best reputation either.

mwhitney Wrote:It is not JS that makes node.js non-blocking, nor does it prevent the developer from creating applications which block execution. What makes node.js non-blocking is that it uses a cross-platform library which performs "non-blocking I/O" by utilizing a combination of event-driven programming and a thread pool. The same library can be used in PHP. The library is written in C.

That's exactly my point. One technology pushes the developer to write asynchronous code and punishes you when you don't and another has no opinion. You can write subjectively equivalent PHP but that is not the norm and requires an exorbitant amount of effort compared to the other. I don't believe PHP is capable of pushing certain limits that Node.js is able to. There isn't a single major player who uses a PHP backend for realtime services.
Reply

#20
(09-22-2016, 06:16 PM)spjonez Wrote:
Narf Wrote:Not that I care, but unless you can't open a file descriptor in JS, there's no inherent limitation in that regard.

Work with compressed files or perform any computationally expensive image manipulation. Or try to do any serious math because JS sucks at precision.

Are you claiming that it is impossible to work with compressed files or do image manipulation with JavaScript?
If so, you're full of shit.
If not, that's a non-argument.

That's not an answer.

(09-22-2016, 06:16 PM)spjonez Wrote:
mwhitney Wrote:It is not JS that makes node.js non-blocking, nor does it prevent the developer from creating applications which block execution. What makes node.js non-blocking is that it uses a cross-platform library which performs "non-blocking I/O" by utilizing a combination of event-driven programming and a thread pool. The same library can be used in PHP. The library is written in C.

That's exactly my point.

That is in no way your point.

(09-22-2016, 06:16 PM)spjonez Wrote: One technology pushes the developer to write asynchronous code and punishes you when you don't and another has no opinion. You can write subjectively equivalent PHP but that is not the norm and requires an exorbitant amount of effort compared to the other.

It requires taking your head out of your ass first, having the knowledge to do it second, and by that time it's not much of an effort left to put in.

I've personally written PHP code that uses non-blocking sockets, at a time when PHP version 5.1.x was the latest, IIRC.

To be more specific - it was a network-wide "Seen" bot for IRC, and by network wide I mean it ran as a network service, not limited to a single channel. And yes, that does imply it also being a stand-alone daemon process - another thing that you'd probably say PHP sucks at.

(09-22-2016, 06:16 PM)spjonez Wrote: I don't believe PHP is capable of pushing certain limits that Node.js is able to.

Your belief is wrong, and you're again comparing a language to a framework built for a specific purpose.
And there's more than one Node.js alternative in the PHP world, this being one of them: https://github.com/amphp/amp

(09-22-2016, 06:16 PM)spjonez Wrote: There isn't a single major player who uses a PHP backend for realtime services.

You don't know this.
And even if it was possible to prove it, it would still mean nothing.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.