Exploring the Webiny Framework: The StdLib Component

Originally published at: http://www.sitepoint.com/exploring-webiny-framework-stdlib-component/

There’s an adage about a developer’s career cycle:

  1. Doesn’t use frameworks
  2. Discovers frameworks
  3. Writes his own framework
  4. Doesn’t use frameworks

Point 4, of course, referring to the newfound ability to use Composer to build your own framework from various battle tested third party components.

We all know there’s no shortage of frameworks in the PHP ecosystem, so it surprised me quite a bit to see another pop up rather recently.

The framework is called Webiny, and, while packed to the brim with wheel reinventions they deem necessary, there are some genuinely interesting components in there that warrant taking a look. In this introductory tutorial, we won’t be focusing on the framework as a whole, but on the most basic of its components – the StdLib.

Continue reading this article on SitePoint

Frameworks:

For when you want to spend 8 hours/day trying to find and decode fan-fiction documentation, learning new rebus-like syntaxes, hammering squares into round holes and working around arbitrary artificial limitations.

…instead of 8 hours/day just coding stuff that works.

I completely disagree with that statement. Several frameworks have excellent documentation such as; Symfony and Laravel. As for limitations I always find that as a cop out answer for those people who don’t like using frameworks. At the end of the day if you can view source there are no limitations only the ones you impose. Not to mention using open source projects and contributing back enriches the community in general. When you chose to use open source frameworks over rolling your own you also provide more value for a client because the transition to other developers has less of a learning curve. For all these reasons I mentioned I truly believe that people who think like you to be very selfish individuals not enriching the community or helping the ecosystem which they are apart of. You’re also doing clients a disservice because if you get hit by a bus chances are that your documentation pales in comparison to that of most open source projects back by a community. The community will live on for large projects where as if something happens to the individual responsible for a custom system everything “dies” with them.

Every project I’ve worked on which has been custom code the idea of documentation has been basically no documentation. I don’t buy it for one minute that those rolling their own code are writing better documentation than that of Symfony of Laravel. What “people” like you are doing is building something that may be great but will be a nightmare to maintain by another individual and have huge costs associated with onboarding others. I’m not going to say open source code, frameworks, modules, plugins aren’t without their flaws but I tend to believe they have much fewer flaws than a single individuals code. Not to mention if a bug is found in one it can always be fixed and is a pull request away typically from helping others fix the same problem.

I also think that the article had it a bit backwards. It seems like everyone and their brother starts with building their own framework. However, it takes a true professional to recognize the available resources within the ecosystem that are available and use those instead of selfishly reinventing wheels. Also accepting the fact that open source code will have problems having enough humanity to fix and contribute back to the community. Once you know a programming language in and out that is the next step not building yet another framework but providing solutions to common problems that can be contributed back to the community that leverage the existing ecosystem. Being able to put ego aside and just enrich the community while also working for a client is stardum within our industry. Those that have the mentality that their code is better than everyone else are living in a fantasy land. Even if it is than you should be contributing back to the community and making people better around you and much of that starts with becoming involved and using thriving open source projects.

2 Likes

I think an unsung truth about those individuals against using open source code is that they are scared. Scared to have to deal with something besides their own outside their comfort zone. I don’t think it has anything to with control, flexibility, etc but simply comes down to being scared, plain and simple. Those individuals rather stay in their comfort zone than have to deal with something unknown.The disservice this does to the community though is astonishing in terms of both knowledge sharing and standardizing the ecosystem to decrease the onboarding efforts.

Does anyone use webiny? Can someone share their experience with it? From my point of view it

  • tries to fix PHP itself
  • is not malleable to one’s needs because it depends on a ton of traits and static calls and
  • is hard to read because of it’s coding style (mix of camelCase and underscores), static/trait jungle :smiley: and strange method names
$this->eventManager()->listen('some.event')->handler(new YourHandler())->method('customHandle');
// a method is called 'method'?

I can hardly imagine using it in a project. Finally this method makes me feel like it was year 2005. Why should a “data type” access super globals? Why should a data type try to set http headers (whithout calling headers_sent()) and even call die()?

Hi!

Framework author here, thanks for your feedback!

We value everyone’s constructive criticism and are constantly looking to improve, so definitely keep it coming. We actually do use the framework to power our own site and some other experiments currently in beta, but I understand if that’s not too convincing, yet : )

To answer what I can.

Tries to fix PHP itself

  • it doesn’t really, the StdLib component is more of helper to some common operations

Is not malleable to one’s needs because it depends on a ton of traits and static calls and

  • actually the public API is rather simple, only one trait, but if you think it can we done better, please propose us the solution

Is hard to read because of it’s coding style (mix of camelCase and underscores), static/trait jungle

  • we do follow the PSR coding standard, with the exception of defining the private and protected methods with a starting underscore (will probably drop that in the next release)

Why should a “data type” access super globals?
Why should a data type try to set http headers (without calling headers_sent()) and even call die()?

  • they shouldn’t you’re right, we’ll address that in the next patch

If you do notice anything else, feel free to open a github issue on our account.

As I said, we are at the very start, our framework is not to compete with Symfony, or something like that, it’s designed for a different purpose, but we still decided to open-source it, 'cause we think we have created couple of useful tools for the community, and to get feedback.

What is the purpose of the design? Maybe if other devs knew about the purpose and understood it, they can also use the framework the way it was intended to be used.:slight_smile:

Scott

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.