
Kill your index.php - dools
http://www.workingsoftware.com.au/page/Kill_your_index.php
======
secstate
I'm pretty sure Rails, et al, use a single point of contact because that's
kinda what web servers do.

I actually shivered a little bit thinking about an app where each url was in a
new file somewhere. I mean, ack is only going to take you so far when you're
trying to find out where something was implemented.

And that's to say nothing of URL passing between different URL paths.

Honestly, Django doesn't have an index.py file anywhere. Rather it has a
urls.py and apart from some really gnarly projects, if you wanna know where
something is implemented, you open the root urls.py file and follow the chain
down to the app where your URL is being generated. That points you at a view
and usually the form or model that's causing issues.

~~~
dools
_I actually shivered a little bit thinking about an app where each url was in
a new file somewhere. I mean, ack is only going to take you so far when you
're trying to find out where something was implemented._

That's essentially what controllers are. How a URL gets mapped to a controller
is somewhat moot, in reality most "pages" equate to either a file or a class
somewhere.

I'm not advocating that one shouldn't have a single entry point. I'm
advocating that it shouldn't be part of a centralised framework.

~~~
oinksoft
As Rasmus Lerdorf and folks like Terry Chay have been saying forever, PHP _is_
the framework.

------
talles
Theres a lot going on in the article that I simply have no idea whats about
(sorry, php is not _my stack_ ).

Probably unrelated to article, but indeed to the title: make your index.php a
index.html. No, not completely static, make your application generate one.
Most of your traffic hits is at your index (kinda obvious right). If you have
a super dynamic index makes more sense generate a static html file with the
new content, let's say, every 3 minutes, rather than generate the thing for
everybody that hits your website root.

It's not exactly a secret, but sometimes people forgets completely about this.
Not that useful for all scenarios though.

~~~
fleitz
Or instead of doing that add some cache headers... and have nginx cache the
page instead of reinventing your own cache.

------
healsdata
I can't read this without thinking that the author isn't paying attention to
the rest of the PHP community. Every point on the checklist is what composer
was built to solve and it can be used without any framework. Even in terms of
package creation, PSR-4 allows the author of a package to define their own
directory structure and inform the autoloader what that structure is.

It's great to revisit assumptions, like using one index.php file for a whole
project, but I think that's an area where talking to lots of people leads to
the best solution.

~~~
dools
_I can 't read this without thinking that the author isn't paying attention to
the rest of the PHP community. Every point on the checklist is what composer
was built to solve and it can be used without any framework._

I don't really like composer so I wrote my own package manager[1], but you
could just as easily use composer with the cut down "framework" that
RocketSled became if you preferred it. And yes, composer (and RocketPack) can
be used without a framework. That's sort of the point: PHP doesn't need a
"framework" as such, just various tools of choice (like composer if that's
your bag).

 _in terms of package creation, PSR-4 allows the author of a package to define
their own directory structure and inform the autoloader what that structure
is_

Actually, PHP allows you to do that with spl_autoload_register.

I find the "PSR-*" conversations to be pretty pointless and not very
interesting. I have a basic autoloader that I wrote and I'm happy with ... BUT
in PHP anyone can use any autoloading implementation that they like very
simply. There doesn't need to be a standard way of doing things, so long as
you provide me with something like a "bootstrap" or autoloader file that I can
include in my project and have everything "Just Work(TM)".

The only time it becomes a challenge is if you're working within a framework
which dictates your directory structure and/or the main entry point of the
application. If I'm just creating my own index.php I can include whatever
packages, autoloaders, whatever very simply.

[1]
[https://github.com/iaindooley/RocketPack](https://github.com/iaindooley/RocketPack)

------
fleitz
PHP is the framework because it's also the runtime, the language, the VM, the
std library and the template language.

Yet another, it's not a framework, it a mess, just copy some files, edit them,
whatever, the framework is your application. So zen.

Imagine what a disaster it would be if every rails app had it's own slightly
modified version of rails.

~~~
vezzy-fnord
_Imagine what a disaster it would be if every rails app had it 's own slightly
modified version of rails._

I don't know how extensible of a language Ruby is (certainly nowhere near as
much as Forth and Lisp, though probably more than most other mainstream
languages), but couldn't one argue that if you're building an app on top of
Rails as your framework... you are, in fact, making a slightly modified
version of Rails?

This is pure semantics, I know. But on the other hand, would such a thing
really be bad? A Lisp web framework would be all about that, for instance.

I'm by no means a fan of PHP, but the author does have a point that it's
essentially an ad-hoc templating system which lets you glue your own framework
on the spot. Obviously it becomes a mess eventually, but it may be useful for
small projects where you want to develop rapidly with minimal dependencies, or
as a sort of Mozart coding philosophy.

I actually think it'd be very refreshing if we got more frameworks that aren't
based on MVC, which instead simply give you some APIs and let you use them as
you see fit. I know there are some, but they're not widespread. Although you
could essentially just grab a bunch of libraries and that'd be equivalent.

~~~
fleitz
PHP is an amazing tool for quick 50 line webpages.

The problem with non-MVC frameworks is that generally most programmers won't
go through the hassle of making MVC style classes. MVC cuts across so many
domains that there have to be some really compelling reasons to abandon it.
I'm interested though, what do you like to use as an architecture alternative
to MVC?

~~~
vezzy-fnord
I'm not entirely sure of a concrete alternative pattern MVC for the web. I
like the style of independent modules that frameworks like web.py provide, but
that's not a unified pattern.

Pretty much all web design patterns are based on models and views, including
MVC, HMVC, MVP, MVVM and so forth. Perhaps more of the latter two would be
welcome, especially MVP.

Decentralized modules can still be quite useful for small apps. I don't think
the hassle of forcing rigorous design patterns is necessary there.

------
rnovak
_this could well be Java 's influence, which took the C language's "main"
function and hid it from the developer altogether_

I don't believe Java has ever hid main. Neither does JavaFX, or J2EE, from
what I've gathered working in the area. I could be wrong, and if I am, someone
please correct me.

~~~
dools
You're correct. What I was thinking of is actually the difference between C++
and Java. Whilst C++ has Object Orientation built into it, you still have to
have a separate main function where as in Java you define a main method on at
least one of your classes.

That'll teach me to write something without looking it up first :)

I'll update when I get back on a real computer (typing on the go right now),
thanks.

------
krapp
Don't you need an index, or something approximating an index? Having an index
lets you redirect requests which aren't to public resources (images, js, css)
through that single point and by extension the url router. That's what it's
for.

I actually don't mind an index.php with some gnarly procedural code. Sometimes
code has to do what it has to do, and it doesn't always have to be pretty.

~~~
erichurkman
Access to static, public resources (images, js, css) should not be run through
any dynamic language. Let the web server do what they do well: serve files. Or
better yet, push that junk to a CDN.

~~~
krapp
Yeah, I wasn't clear, sorry, lack of sleep. It's usually .htaccess that either
serves the static file or routes requests which don't hit a resource into
index.php... but to me, that process, including .htaccess and an index file,
would have to be an integral part of the framework.

------
awinder
The part that casually drops "PHP as a config language" is where this jumped
the shark for me. I guess this isn't the worst practice I've seen in PHP, but
it's definitely a notable one.

~~~
bandushrew
the author specifically mentions that this is in the context of a php
application.

and in that context, it is perfectly reasonable, I think.

what issues do you have with the idea exactly?

~~~
awinder
I guess it depends on what the use case is for configuration, but I'm
envisioning times you want to allow for user/developer configurability of your
program, or an installation being able to write out values that your program
can use in its execution. Do you really want full programming language tools
in your configuration level? Do you want an installation routine writing out a
php script, or should it just serialize a config object to json / yaml?

~~~
dools
I don't really have a problem with caching application writable config as
something like serialized json or something like that, but I really dislike
composer's configuration file format.

------
TuxLyn
I can still see >
[http://www.workingsoftware.com.au/index.php](http://www.workingsoftware.com.au/index.php)
Do as I say, not as I do :-)

~~~
dools
Most web applications will still have an index.php, what I'm saying is that it
shouldn't be part of the core framework in a PHP application.

------
datahack
Rails made php start using mvc? I'm not the only one thinking that's
completely wrong, right? I was writing mvc based web apps in php long before
rails arrived.

------
jbb555
Perhaps look at this as "write libraries, not frameworks". And write lot of
small independent ones, not one big one, as much as possible

------
Misiek
btw of "rise in popularity of Ruby on Rails":

[http://www.google.com/trends/explore#q=Ruby%20on%20Rails%2C%...](http://www.google.com/trends/explore#q=Ruby%20on%20Rails%2C%20Laravel&cmpt=q)

