Why create your own Framework?

[Ikadon]

I haven't checked IPB in a few years and now that I got a few emails I just thought I'd come back and read up some of the blog-entries.

It seems like IPS is still writing their own framework for 4.0?

Why's that? Why don't you use a framework such as Laravel or Yii that has covered all the basics already?

Finally PHP seems to be shaping up well, thanks to Composer and all the great opportunities it brings the developers and customers. No more reinventing the wheel over and over again, yet you decide to create your own framework instead of focusing what is really important, a great forum-software.

Your greatness always laid on the usability of the software, not on the code itself. It's sad to see you doing the same work others have done and most probably have done in a better way than the few of you could ever hope to do.

There are so many frameworks out there, some of which are really great (like I said) and there must be a licence that is absolutely compatible with what you intend on doing.

Think of the opportunity you would have being the first (big) commercial software that uses a framework that uses composer where you and others could easily recycle features and help the whole php community while gaining on momentum.

Well... just my .05

[Heyhoe]

Well, I have little to no knowledge of the subject.

But, would this not have the potential to become like what is happening with CKEditor? Just on a larger scale?

More power to IPS if they use their own framework...

[Aiwa]

Why use a pre-built framework and kludge it together to get it to do what you need it to within the constraints of the custom applications IPS writes?? Writing your own framework allows you to make it more efficient for YOUR use of it.

Not that it's a big factor, but security through obscurity... If you use a pre-built framework, any vulnerabilties in that framework now become a vulnerability to the IPS products that IPS has no control over fixing... Delaying the release of critical security patches.

Just my .05

[Ikadon]

They definetely have more power if they use their own framework but this has some downsides too:

1) They need to put work into the very basics such as security and stuff on a very low level, instead of, well, actually develop features that distinguish them from other software.

2) Third-Party-Developers create great plugins and addons that one can't easily combine with IPS-Software because they reinvented the wheel.

3) Great parts of the PHP-Community decided for one framework or the other. Now that more and more frameworks try to integrate with composer (a dependency-manager) one can quite easily add new functionality that was created by others if it is composer-ready.

That means you could, for example, use IP.Board with Drupal 8 (for example) without a problem.

The major downside I see is that they would have to compete more strongly with other, often even free software that does some jobs better than, let's say IP.Content does.

@Aiwa: "Security by Obscurity" is actually an argument against what you said. One should NEVER think that obscurity adds a layer of security. That's the very basics you learn at university, regarding security in IT.

Also I guess it's quite the opposite. If you look at the linux-kernel. It has vulnerabilities just like any other software, still it gets patched much faster than security problems with MacOS or Windows, because the larger community covers more aspects that a handful of developers can't find on their own.

[bfarber]

We have looked at third party PHP frameworks in the past, and we don't feel that they are best suited to our needs. There are many factors to consider:

1) Firstly, no matter what we chose if we did use one, someone would tell us how awful it is and that xyz framework is better.

2) We then become tied in to the framework over the lifespan of our codebase. If the developers of the framework stop putting out updates, we have to maintain third party code. If they can't get the framework working with a new php version, we have to figure it out ourselves. If a critical security update comes out, we have to update our software ASAP, and if we leverage advanced functionality it could become difficult (API changes, etc.).

3) We are quite competent to create our own underlying framework. We've done it since IP.Board 1.0. As you said, the typical end user doesn't care what's under the hood anyways.

4) Writing our own framework allows us to absolutely tailor it to our needs. We don't have to worry about extra code that we don't need consuming resources. We also don't have to rely on the coding abilities of people we do not know.

Really, this is one of those things only general PHP developers used to working with third party frameworks would care about. Our underlying code base will, in the end, be well suited for our purposes, as efficient as it can be for our needs without additional features or code we won't use, and will be powerful enough to accomplish everything we want to throw at it.

[Charles]

I think #4 is the key point :)

[ADKGamers]

I think #4 is the key point :smile:

I agree. Why would you want to rely on a third party for a project like this. Sure people have to learn the framework to develop for it and that might be a downside to some people, but it obviously isn't a big one since things still seem to be going full steam ahead here.

[Marcher Technologies]

I haven't checked IPB in a few years and now that I got a few emails I just thought I'd come back and read up some of the blog-entries.

It seems like IPS is still writing their own framework for 4.0?

Your greatness always laid on the usability of the software, not on the code itself.

As a modification author, having tinkered with these other frameworks, I wholeheartedly disagree with this statement.... As a user, yes. As a dev? Good lords, this code base, this framework has been a step above the cut since 3.x.... 4.x just makes the toolbox better/tidier.

[Ikadon]

Well I see your point.

The old saying "what if others stop supporting their code" is the main reason why everyone started to develop his own code in the beginning.

Reinventing the wheel over and over again. Yeah!

I'm glad others see my point and many software is moving down the composer-route.

(Even forum-software. Beware IPS, free software is getting better and better while you stand here.)

I wish you success then.

@Marcher: Ever looked at Laravel? To me there is no framework out there that is more readable and understandable and yet it's by far more powerful than IPS-Framework.

[Marcher Technologies]

Well I see your point.

The old saying "what if others stop supporting their code" is the main reason why everyone started to develop his own code in the beginning.

Reinventing the wheel over and over again. Yeah!

I'm glad others see my point and many software is moving down the composer-route.

(Even forum-software. Beware IPS, free software is getting better and better while you stand here.)

I wish you success then.

@Marcher: Ever looked at Laravel? To me there is no framework out there that is more readable and understandable and yet it's by far more powerful than IPS-Framework.

Yes. Ever seen the hooks system? Literally. There is no framework out there that the core is as flexible in, and any stock is malleable without hard file edits.... you find me that, in a script that allows entire new applications, and functionality added to those applications and the core as needed without file edits by third party, and I'd work/play with it.

This is one reason why IPS cannot use the PSR-# standards literal, that functionality is so... powerful and baked into the script since 3.x, and so MUCH is easier/so much more possible because of it.

Tis not *just* normal PHP Class extension, they chain and compound to greater effect and maximize compatibility.... They make what other systems and frameworks *call* 'hooks' a literal bad joke.

[Charles]

(Even forum-software. Beware IPS, free software is getting better and better while you stand here.)

I have been hearing that for 11 years now :)

[ADKGamers]

I have been hearing that for 11 years now :smile:

LOL Clearly it's caused a lot of problems for the paid forum software industry.

I feel there's some things that you get from paid forum software that you don't get from the free stuff.

[Charles]

I feel there's some things that you get from paid forum software that you don't get from the free stuff.

Yes like guaranteed development, support, etc.

And me.

[Ikadon]

Yes. Ever seen the hooks system? Literally. There is no framework out there that the core is as flexible in, and any stock is malleable without hard file edits.... you find me that, in a script that allows entire new applications, and functionality added to those applications and the core as needed without file edits by third party, and I'd work/play with it.
This is one reason why IPS cannot use the PSR-# standards literal, that functionality is so... powerful and baked into the script since 3.x, and so MUCH is easier/so much more possible because of it.
Tis not *just* normal PHP Class extension, they chain and compound to greater effect and maximize compatibility.... They make what other systems and frameworks *call* 'hooks' a literal bad joke.

Let's agree to disagree here.

Charles: Composer and Frameworks aren't on their way since eleven years.

I hope the best for you. Maybe I'll be using IPS-products at some distant point in the future.

Until then, farewell.

[Grimace`]

And me.

And his cheerleader team which consists of bfarber [brandon] and Matt ;)

[Ikadon]

Yes like guaranteed development, support, etc.

And me.

Yes, because companies can't go bankrupt ... oh if life was that easy.

[Charles]

Yes, because companies can't go bankrupt ... oh if life was that easy.

The fact that any company can go bankrupt is not relevant. The same could be said of just about anything. "Oh I shouldn't buy X because the company making it COULD go bankrupt" is not a very fun way to live.

[Grimace`]

The fact that any company can go bankrupt is not relevant. The same could be said of just about anything. "Oh I shouldn't buy X because the company making it COULD go bankrupt" is not a very fun way to live.

It's like saying you won't fly with Virgin America because they might go bankrupt the next day. It's not a logical way to think in life.

[Ikadon]

The fact that any company can go bankrupt is not relevant. The same could be said of just about anything. "Oh I shouldn't buy X because the company making it COULD go bankrupt" is not a very fun way to live.

It's the same as saying "Oh, I won't use a framework because development and support could stop." (There are frameworks out there that are developed by professionals, as part of their fulltime job)

Well, I asked a question, I got an answer, I disagree... I haven't used IPS-products in years and I'm glad all the support requests I got stopped.

Now that I left the newsletter-system I won't bother you anymore.

Have a nice day!

[Marcher Technologies]

Let's agree to disagree here.

Charles: Composer and Frameworks aren't on their way since eleven years.

I hope the best for you. Maybe I'll be using IPS-products at some distant point in the future.

Until then, farewell.

answer the question I asked please.

I have looked high and low for such in any other framework..... modifying anything about the core of any other script out there is troublesome and bound for compatibility conflicts where two mods mesh perfectly otherwise, if they even allow it via 'hooks', I have yet to see another script that chains in the manner IPS has it.

Hard file edits of another's code to enhance or change existing functionality is for the birds, and quite prone to breakage upon upgrade, and is generally way more painful when doing what one can do with a hook, which is generally anything.

so... where is this framework that can do that? that allows and supports that type of direct nigh-unlimited extension, compatibility *between* extensions, and modification without editing any 'stock' files?

[Ikadon]

I have never ever had to change a core-file, neither of IPS-software nor of Laravel or YII-framework.

Why should I? This would be bad frameworks where one is forced to change the core. The maintainability and updatability would be lost. That's insane.

Have a closer look at Laravel (especially Laravel 4, which is in beta currently) and shoot me a message if you feel the need to edit a core-file. I would love to see a situation where you'd need to do that.

What you asked for: Any modern framework can do what you specified, that's what they were made for oO

Either that or I don't get the question. (Bear with me, english isn't my mothertongue)

edit: Even better, have a look at composer and tell me again why you would need to hack core-files. That would lead the whole concept of a dependency manager ad absurdum.

[Marcher Technologies]

I have never ever had to change a core-file, neither of IPS-software nor of Laravel or YII-framework.

Why should I? This would be bad frameworks where one is forced to change the core. The maintainability and updatability would be lost. That's insane.

Have a closer look at Laravel (especially Laravel 4, which is in beta currently) and shoot me a message if you feel the need to edit a core-file. I would love to see a situation where you'd need to do that.

What you asked for: Any modern framework can do what you specified, that's what they were made for oO

Either that or I don't get the question. (Bear with me, english isn't my mothertongue)

edit: Even better, have a look at composer and tell me again why you would need to hack core-files. That would lead the whole concept of a dependency manager ad absurdum.

re-read friend, a 'stock' file is any modders stock, a 'stock' file is part of an app, this has to do with not having to edit the app x person made to do x to add some customized feature, not directly to do with modifying the 'core' of the suite. any framework is only as good as how extensible it is, and how extensible what is built atop it is with minimal to no effort, and nothing is ideal for every situation Out Of Box.

I'm talking about the fact you can make an application, and I can modify any functionality about it, without touching your files, and then someone *else* could further modify a different functionality, or the same for that matter(the chaining I speak of)... again, tell me what does that?

Class extension itself is nothing new, but what IPS has with hooks is unique, and it does take a modder to actually appreciate that we can modify not only the core, but basically every app installed at need to meet the client's needs perfectly with minimal effort, versus 're-inventing the wheel' literally where an app is simply missing x vital function, but you do not actually have the ability to add it to the source as it is not your app, upgrade would boink any file edits and tis crude to need to anyway.

[Ikadon]

re-read friend, a 'stock' file is any modders stock, a 'stock' file is part of an app, this has to do with not having to edit the app x person made to do x to add some customized feature, not directly to do with modifying the 'core' of the suite. any framework is only as good as how extensible it is, and how extensible what is built atop it is with minimal to no effort, and nothing is ideal for every situation Out Of Box.

I'm talking about the fact you can make an application, and I can modify any functionality about it, without touching your files, and then someone *else* could further modify a different functionality, or the same for that matter(the chaining I speak of)... again, tell me what does that?

Class extension itself is nothing new, but what IPS has with hooks is unique, and it does take a modder to actually appreciate that we can modify not only the core, but basically every app installed at need to meet the client's needs perfectly with minimal effort, versus 're-inventing the wheel' literally where an app is simply missing x vital function, but you do not actually have the ability to add it to the source as it is not your app, upgrade would boink any file edits and tis crude to need to anyway.

It would depend on how the guy programmed his app, wouldn't it? I mean if he just made it to be spaghetticode in one file I'd sure have to edit his code to add functionality, but this depends on the app itself.

Have a look at: https://packagist.org/

All these, and more, are available out of the box to your composer-projects. You just add a few lines to a composer.json-file and composer does the rest for you.

The Hooks I know from IP-Products are great but certainly not unique. Just have a look at modern frameworks.

I never had to change the code I used from packagist, but I did extend it (without any hassle)

Why would I spend my precious time to work with an application backed by one company if I can work with composer that intertwines with major frameworks such as Laravel, YII or Symfony 2.

Hell even CI had hooks years back.

edit: It seems like some of you feel attacked by my opinion. Well, this wasn't my intention and I'm sorry. It's just that once I really liked IPB and I got a little excited when the newsletter reached me.

But now I simply don't wanna support twenty frameworks anymore. These times have passed (luckily) so IPS-Products are not an alternative anymore, currently.

I just love to be able to share my code without the need to adapt it to five different frameworks and others are glad as well, because they spend less time porting applications that were made for Framework A to Framework B. It's also great to be able to use the efforts others have already taken without much of a hassle.

To me it's just a waste of time to develop the same stuff over and over again for different frameworks. I wouldn't mind if IPS would use their own framework if it was composer-ready and thus easily extendable by all applications. But I guess this could lead to more support-requests on your side and less control of the people. Now you need to use a bridge to integrate differend software with IP.B. Then you could simply add IP.Board to, let's say, Drupal 8.

So basically people who's needs are fulfilled with D8 and IP.Board wouldn't think about buying IP.Content and all the other products.

In my eyes composer is the bright future of PHP. Something Ruby (on Rails) has since eons. This development brought me back to this language.

Anyways, so this was it from my side. Have a nice day, enjoy your products and farewell.

[Marcher Technologies]

It would depend on how the guy programmed his app, wouldn't it? I mean if he just made it to be spaghetticode in one file I'd sure have to edit his code to add functionality, but this depends on the app itself.

Have a look at: https://packagist.org/

All these, and more, are available out of the box to your composer-projects. You just add a few lines to a composer.json-file and composer does the rest for you.

The Hooks I know from IP-Products are great but certainly not unique. Just have a look at modern frameworks.

I never had to change the code I used from packagist, but I did extend it (without any hassle)

Why would I spend my precious time to work with an application backed by one company if I can work with composer that intertwines with major frameworks such as Laravel, YII or Symfony 2.

Hell even CI had hooks years back.

how many times? 'hooks' in any other framework means one and done that I have seen, extending a class once is not framework, it is native PHP.

In a world of multiple programmers making applications and hooks independently for consumption, it is not that one can 'hook', it is that one can 'hook' and be certain anyone else 'hook'ing can 'hook' in after you at the same spot.

Also... what Is this about package dependencies? auto-load *everything* for my app, even if I don't *need* or *use* it at x view? Wasteful IMO.... at least as a single config file unable to be handled at run-time.

[Ikadon]

how many times? 'hooks' in any other framework means one and done that I have seen, extending a class once is not framework, it is native PHP.

"How many times"? Wow. I'm sorry I was even talking (and answering your questions) to you anymore, my glorious, superiour human. I've talked about hooks as you have, but as far as I see it you've worked with Laravel 4 and YII and Symfony 2 much longer than I did and thus have a far better understanding of all these frameworks than I do.

In a world of multiple programmers making applications and hooks independently for consumption, it is not that one can 'hook', it is that one can 'hook' and be certain anyone else 'hook'ing can 'hook' in after you at the same spot.

Also... what Is this about package dependencies? load *everything* for my app, even if I don't *need* or *use* it at x view? Wasteful IMO.... at least as a single config file unable to be handled at run-time.

That's why packages try to be as small as possible. But yes, you're loading all the stuff that belongs to that package. If that is wasteful to you, that may well be your opinion. I'd rather "waste" some disk-space than my time in reinventing half of an application of thrice the size of IP.Board ;) Which can be dozens of hours someone has to pay for.

This was my very last post here, I don't feel the need to discuss in a tone like that.