Live data from Hacker News

PHP the Wrong Way

phpthewrongway.com

191–194 of 194 posts

Re: PHP the Wrong Way

#191

Earlier quoted context omitted.

Curl isn't a framework. >Do we really need to also be responsible to dealing with already solved problems as well as the problems specific to our domain? No? What does that have to do with anything? >Do we really want to also deal with the not-fully-compliant HTTP client or making sure we support HTTP/2, or do we want to use widely accepted solutions for those so we can focus on the real problem at hand (which is usu…

> Curl isn't a framework. I wasn't under the impression we should be limiting this to frameworks. What's the difference between a framework and a library for the purpose of this discussion? I think they are functionally equivalent. I was clear to equate it to crypto originally, which doesn't really make sense when viewed as applying to frameworks only. We're a couple comments removed from that, I thought that wasn't…

>I wasn't under the impression we should be limiting this to frameworks

The discussion is entirely and solely about frameworks..

>What's the difference between a framework and a library for the purpose of this discussion?

Wikipedia exists.

>See above

Above what? Nothing you said above answers my question.

>And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making sense?

Because it has absolutely nothing to do with anything I said, like I clearly stated.

Re: PHP the Wrong Way

#192

Earlier quoted context omitted.

> Curl isn't a framework. I wasn't under the impression we should be limiting this to frameworks. What's the difference between a framework and a library for the purpose of this discussion? I think they are functionally equivalent. I was clear to equate it to crypto originally, which doesn't really make sense when viewed as applying to frameworks only. We're a couple comments removed from that, I thought that wasn't…

>I wasn't under the impression we should be limiting this to frameworks The discussion is entirely and solely about frameworks.. >What's the difference between a framework and a library for the purpose of this discussion? Wikipedia exists. >See above Above what? Nothing you said above answers my question. >And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making se…

My point was frameworks are functionally no different than a large complex library, and as such, the same arguments apply.

That said, I'm not entirely happy with the way the tone of this conversation is heading, so I'll excuse myself now.

Re: PHP the Wrong Way

#193

Earlier quoted context omitted.

>I wasn't under the impression we should be limiting this to frameworks The discussion is entirely and solely about frameworks.. >What's the difference between a framework and a library for the purpose of this discussion? Wikipedia exists. >See above Above what? Nothing you said above answers my question. >And I've been sticking with the same examples since the first comment. Why is this all of a sudden not making se…

My point was frameworks are functionally no different than a large complex library, and as such, the same arguments apply. That said, I'm not entirely happy with the way the tone of this conversation is heading, so I'll excuse myself now.

>My point was frameworks are functionally no different than a large complex library

You'll have to forgive me for not guessing that given that nothing in your post came anywhere close to even suggesting anything of the sort. I am limited to reading what you write, and can not read your mind.

Yes, frameworks are different from libraries. Boy, that was productive.

Re: PHP the Wrong Way

#194
post #172

Earlier quoted context omitted.

Not much difference: {{ var | escape }} Nevertheless, I used DOM/libxml on the server side in PHP/C, since 10 years ago, and was happy about it. It avoids all the other the template issues (balancing open/close tags, etc.) very well. A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP. Though, some coding customers don't know what to…

Twig does not require you to write escape so you can have to write just {{ var }} That is a big difference because beginners always forget about escaping. > Nevertheless, I used DOM/libxml on the server side in PHP/C, There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.

Not that much bloated. And it can be quite readable if done well. You also don't need to learn peculiarities of for loops or macro language in a given templating system. The host language is it's own macro language with all the features you already know, and not limited to whatever template language authors decided to implement.

Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction.

Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree.

It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.

Post reply on HN