Good evening, Internals!
*Disclaimer: *I wanted to bring this discussion inside the internals
mailing list not only because of the fact that the PHP.net website's source
code on GitHub doesn't have issues enabled, but especially because I think
it's part of the PHP environment, just like the spec or the actual C code
itself.
You all know the http://php.net website and it's source code
https://github.com/php/web-php. It comes to my attention that this source
code is pretty much a very good example of how *not *to build websites in
PHP — the source code predates the PHP 3 days, but that's just one of the
problems. I'm not go further into the details of the problems we actually
have inside that code, as they are very obvious and the source code speaks
for itself — of course, if needed, we can discuss this in more detail later.
What I wanted to know from you is: would it be interesting if we started a
complete rewrite of the website, not only for actually improving it, but
also for making it serve as a reference for people to see how the PHP
environment has evolved and what are the good practices we use these days
for building websites?
Cheers!
Daniel Ribeiro
http://danielribeiro.org
I'm not go further into the details of the problems we actually
have inside that code, as they are very obvious and the source code speaks
for itself
I'm all for having a discussion about updating the website. But on the
flip side of that token, you can't just "drive by" here, suggest a complete
rewrite of the website because the code is "bad" somehow, then decline to
provide any specific examples. You need to outline exactly what it is that
you believe is outdated or poorly written, as both could be considered
largely subjective. Merely stating that they're "very obvious" does not
constitute a sufficient argument.
Please include details, including the ones you believe to be "very
obvious", then we'll talk. As it stands now, all you've offered is
basically, "It's broken. Go fix it."
--Kris
You all know the http://php.net website and it's source code
https://github.com/php/web-php. It comes to my attention that this source
code is pretty much a very good example of how *not *to build websites in
PHP — the source code predates the PHP 3 days, but that's just one of the
problems. I'm not go further into the details of the problems we actually
have inside that code, as they are very obvious and the source code speaks
for itself — of course, if needed, we can discuss this in more detail later.What I wanted to know from you is: would it be interesting if we started a
complete rewrite of the website, not only for actually improving it, but
also for making it serve as a reference for people to see how the PHP
environment has evolved and what are the good practices we use these days
for building websites?
Interesting? Maybe. A good idea? Definitely not.
If there’s one rule in refactoring, it’s that you never do ground-up rewrites of something which works. They always go badly. If there are problems, you can refactor. There is no need for a rewrite.
--
Andrea Faulds
http://ajf.me/
What I wanted to know from you is: would it be interesting if we started a
complete rewrite of the website, not only for actually improving it, but
also for making it serve as a reference for people to see how the PHP
environment has evolved and what are the good practices we use these days
for building websites?Interesting? Maybe. A good idea? Definitely not.
If there’s one rule in refactoring, it’s that you never do ground-up rewrites of something which works. They always go badly. If there are problems, you can refactor. There is no need for a rewrite.
Agreed: don't rewrite from scratch.
I think our HTML/CSS is in need of a lift once browser adoption is
better for some of the more recent improvements. Using something like
Polymer for our front-end would drastically simplify the code and
significantly improve the user experience. I've already done a port on
my local copy and it works pretty nicely. However, I don't think
Polymer is fully stable yet and I don't think we're ready to ditch IE
9 either. I haven't said anything on list about this because the
browser adoption rates need to improve and Polymer (and other similar
projects) need to stabilize.
The reason I bring this up in this discussion is that switching to
something like Polymer is going to require a few changes on how we
generate the HTML and CSS. The the best time to refactor code is when
you are already changing it for something already, so it would be
better to delay refactoring code until we have some need to change it.
Daniel Ribeiro wrote on 24/10/2014 19:52:
*Disclaimer: *I wanted to bring this discussion inside the internals
mailing list not only because of the fact that the PHP.net website's source
code on GitHub doesn't have issues enabled, but especially because I think
it's part of the PHP environment, just like the spec or the actual C code
itself.
In case you hadn't seen it already, there's a list of all the mailing
lists for PHP here: http://php.net/mailing-lists.php
In this case, I would have thought either php.webmaster or php.doc would
be more appropriate than php.internals, which really does tend to focus
on the internal implementation of the language, rather than how it used
or documented.
Meanwhile, I agree with both Kris and Andrea's responses: you need to be
specific about what problems you propose to fix, and you need to be
extremely wary of breaking existing functionality just because it's
"interesting" or "modern".
Regards,
Rowan Collins
[IMSoP]
Daniel Ribeiro wrote on 24/10/2014 19:52:
*Disclaimer: *I wanted to bring this discussion inside the internals
mailing list not only because of the fact that the PHP.net website's
source
code on GitHub doesn't have issues enabled, but especially because I think
it's part of the PHP environment, just like the spec or the actual C code
itself.In this case, I would have thought either php.webmaster or php.doc would be
more appropriate than php.internals, which really does tend to focus on the
internal implementation of the language, rather than how it used or
documented.
Yep, this is php.webmaster material (I've cc:d that list, and would
suggest that follow ups should probably go there and exclude
Internals). #php.doc on efnet is also a good place to float things
more informally, particularly if you hit it at the right time of day
(morning/early afternoon PST tends to be good, given a lot of the
regular Web site committers are in North America).
Meanwhile, I agree with both Kris and Andrea's responses: you need to be
specific about what problems you propose to fix, and you need to be
extremely wary of breaking existing functionality just because it's
"interesting" or "modern".
+1.
There are also a lot of technological constraints that aren't obvious
at a glance: not controlling our (entirely volunteer) mirrors means
that the baseline PHP functionality we can rely on is much, much lower
than you may expect. (Don't even ask about databases.) Remember, we
have literally no budget, and rely entirely on the generosity of our
hosting sponsors.
I'm certainly not claiming that what we have in web-php today is good,
but it has the advantage of having been proven over a very long period
of time, being easily and widely distributed, and coping with the
loads that it has to. A rewrite would have to have compelling
advantages over that, and be done for better reasons than just "the
existing code is old and terrible".
Adam