I don't like Li3 because... #887

Open
jails opened this Issue Apr 15, 2013 · 54 comments

Projects

None yet
@jails
Contributor
jails commented Apr 15, 2013

Don't be shy, express yourself on things you don't like in Li3. Don't be stingy with criticisms (I personally like being abused). Makes your criticism as detailed as possible with comparisons with how it works with your favorite framework if possible.

Thanks in advance for helping us to make Li3 an even better framework.

@nateabele
Member

Hey, good idea. Let 'er rip with the feedback, everyone!

@fduarte
fduarte commented Apr 16, 2013

I think the documentation has a long way to go as it needs MORE EXAMPLES, and certain sections have no documentation whatsoever.

Besides that, features that I would personally like to see added to the core are:
A) A way to relate M-N models (i.e. A 'user' can have many 'posts', in other frameworks this is called a HABTM relationship). Anyone that's developing upon a relational db needs this.
B) Migrations: it would be great to have db migrations tied to the core with 'up' and 'down' statements or something along those lines, to facilitate db maintenance.

@blainesch
Member

@fduarte thanks for the suggestions!

I agree there should be more documentation. Maybe we can have a documentation hack day like symfony did a few weeks ago? I'd love to participate! Thoughts @jails @nateabele ?

  1. Here is a wiki page with some examples with relationships.

  2. There is a migration plugin here, I've not personally used it mostly because mongo is awesome. However I do think this would be a great core feature.

@marcghorayeb
Member

The doc needs a tutorial that goes a little more in depth into all the little things you can do with Lithium. Maybe incorporate the advent series you did on sphere into the doc??
Maybe make the lithify.me website a little clearer/more attractive for a newcomer? :)

@mackstar
Member

Yo guys!

You know I love lithium but these are reasons we either can't use it in production at the BBC or the reasons why it is difficult.

I have chatted to Nate about these things so he knows I love you!

  • Base class for everything
  • Libraries/Components are not decoupled enough
  • If you are not using the testing #li3 framework you shouldn't have to need to download it
  • The view rendering system is too hard to break out of - need examples of this running alone
  • Adapters need to be more transparent and a recommended method of dependency injection (_classes or adapters not both is less confusing)
  • Not naming tools as li3_ something should be promoted as standalone tools (ie test framework, li3_quality), we can let get contributors from people who do not use lithium as their main framework.
  • Compatibility with composer autoloading may be nice.
  • Model layer should be its own project - PHP seems to be missing a great active-record library, #li3 models do this well but should be standalone
  • Vendor Namespace should be UnionOfRad - not lithium - leeds to better componentization.
  • Custom Auth adapters are too sticky/tricky too much magic - maybe Interfaces aren't too bad in such cases?
  • Filters need to be more testable - ie classes

Just some ideas

@nervetattoo
Member

Great initiative :)

  • No god damn 1.0, yet. This should have happened a lot earlier with a reduced scope, people get tired of waiting for something officially done.
  • The docs needs a lot of love, love that I think there will be many contributors to (myself included) but only once someone takes the lead and shows the way.
    • I'd prefer a stop in development of the framework for 2 months if that meant doc improvements.
  • The website needs to look less rad, it makes lithium come off as unserious
    • You could very quickly add some seriousness by doing a *Built with Lithium section
  • It also needs to be completely composer-d, you should be able to install with a composer create-project command
  • lithium/framework is imo a weird name, maybe lithium/app or something
  • Separate the different parts into modules; core, data, http? whatnot, I should be able to build a CLI app using lithium components without having controllers and vice versa.

I've chosen lithium as the framework for 2 in-production web applications, one DAM serving hundreds of thousands of media files and one sms application sending 500k messages a month, and I think at the current standing I would have to bring some good arguments to the table for my team to use it in another app.
Things work, but I have a hard time bringing other developers properly into the knowledge fold of the framework, and when we hit a roadbump that bump turns out to be a rock that sends the developer crashing for too long.

@marcghorayeb
Member

A proper universal debugger that's stylish and useful !
we developed one for our main website but it's not quite ready for primetime, I might get around to open-sourcing it in the next weeks ! (works with static pages, ajax calls, and in console mode)

@blainesch
Member

@mackstar I feel filters are testable now. Obviously they can be a pain in the rear if used incorrectly. At the day job we ended up making a directory app/filters so each filter does have it's own class. There are two methods for each class enabled and apply. If enabled is true, we call apply. Now we can unit test them. Of course you can still have integration tests for filters that just test the behavior of the filtered method/class. Now most of my filters have a standard if(Foo::enabled()) { return Foo::apply($self, $params, $chain); } maybe it's possible to get a new syntax:

Foo::applyFilter('bar', 'FooClass');
Foo::applyFilter('bar', 'FooClass::Bar', array('if' => 'FooClass::Enabled'));

@marcghorayeb what are some features of a debugger that you'd like to see? I love how we can currently click through the stack trace, but I suppose compared to pry or better errors it could use some work. Although I'm not sure how much is possible without a php extension.

@ericcholis
Contributor

@BlaineSch I like that implementation for filters, perhaps this could be added to framework bootstrap with a sample.

Honestly, I don't think I'm experienced enough as a PHP developer to pick out things about the framework itself. I think there are other non-code related issues that need to be address to help make 1.0 amazing.

Updated website to "sell" the framework.
Think of lithium as a product, we need to tell people what the framework is and why they should use it. Showing quick code examples on the homepage would be key. Also, some attention to SEO would be useful.

As @nervetattoo mentioned, a "built with lithium" section would be useful. Also, links to featured tutorials and presentations would help ease in newcomers.

A more unified community
While the idea behind sphere and lithium101 are nice, it all seems a bit disjointed from promoting the framework. Also an attempt was made at starting a forum, but it never caught on. I really enjoy having IRC as a resource, but it can be tough to get questions answered on there. Perhaps promoting posting to Stack Overflow directly from lithify.me.

Documentation
Just reiterating what's been said, the docs need some help. They are amazing right now, but they are lacking some final polish. Also, I'm always unsure of which version the docs apply to. Easy answer is to either put the version tag directly on the docs, or a link to the latest branch.

Versions
I know that we are rapidly iterating the framework, with new pull requests being merged to dev multiple times a day. Would it be possible to use a versioning pattern that was more indicative of these changes?

Activism
In line with unifying the community, we need to get the word out there. Many of us love Lithium, but that message isn't catching on elsewhere. Having the backing of EngineYard is great, let's use that!

@marcghorayeb
Member

@BlaineSch I was more referring to a profiler that spits out the requests / exec time of db requests needed to display the page. My profiler currently handles different levels of details, db, cache, framework time, view render time. The current error page is sufficient I think.

@me23
me23 commented Apr 16, 2013

Nice idea :-)
First of all thanks for all your work!

i would like to see

  • more examples
  • more background/best practices of the core concepts of the framework
    (where can i configure things)
  • Support by using forum platform (why not using Sphere?) not IRC
    IRC is very frustrating because of pastbins which no longer exists
    and so the solution is gone;
    also i have to read the whole log only to find out that there was no
    solution given;
    to much other QaAs between these i am looking for...
  • dev.lithify.me should be renewed/disabled, because of last entry of
    commit is 2011-06-14, i first thought lithium is dead already...
  • lithify.me should be more center of the whole movement!
    it should cumulate all resource for lithium e.g.
    -docs
    -forum
    -news
    -latest release
    -links to external tutorials/plugins etc
    currently i think the github site is more filled with life then the
    main homepage
    -render process should be easier to extend
    • i would like to easily render a sublayout for all actions of a
      controller
    • easily set the path to look for the template
      -auth adapter don't allow logins if your password field is renamed to
      something else because of the "password" filter deeper in the process
      -Sometimes i stuck on easy things: I have a document (Mongo) and would
      like to know if the model has a field
    • $model->hasField('firstname'); => won't work. have to be $m =
      $model->model(); $m::hasField('firstname') little things that slow down
      development.
  • i would like to have the label of the Model fields defined in the
    model too (like in yii framework)
    if it needs to change i only have to change it in one place and not
    in more view files...

Enough for know may be more to come later...

@brandonwestcott
Contributor

2 major things I wish LI3 was stronger at:

  1. Relationships. This is an essential part of any ORM/ODM. Besides mysql, relationships support is somewhat lacking. Also, given the awesome power of data sources, I think that relationships should not be tied to the data sources themselves, but rather be abstracted out into the model layer. This allows models of different sources, such as external apis, filesystem, or even multiple db to have relationships to each other independent of the data source. Of course, if both models on each side of of the relationship had the same data source, the model could delegate the operation to the data source if it supported relationships natively (eg. to mysql adapter to do sql joins).
  2. Documentation. The doc blocks are great, and give great insight into the individual methods. However, the complexity of tracking down the chain of methods or just the overall stack is high. It would be great to have documentation that existed at a higher level than just methods (eg http://guides.rubyonrails.org/initialization.html). This gives developers the ability to understand how the pieces of the application work together without having to trace through application method by method (eg. more of this). In addition, I think more of these types of tutorials would be beneficial for newcomers and help lower the barrier to entry into using li3.
@al-the-x
Contributor

Concur with most of these sentiments:

  • Documentation and coding examples need improvement.
  • Documentation should be built and deployed to some official location.
  • The "official location" should look a little more "official"... Sorry, Picard.
  • Model relationships are hard, particularly across data sources, but that's what an ORM is supposed to do.
  • Method calls on Entity should proxy to Model, i.e. $user->hasField('first_name');
  • Composer is not the future, it is the present. It's actually the past for most other dynamic languages.
  • Improve modularization and decouple components.
  • Use interfaces and abstract classes to describe contracts that must be fulfilled by subclasses, e.g. Adapters.
  • Establish and follow a Semantic Versioning release pattern.

My own frustrations:

  • I hate constantly typing conditions all the time. The most common use case for an ORM in my experience is fetching instances based on multiple criteria; rarely can I take advantage of the __callStatic() magic configurations... Which also need documentation.
  • The last tagged releases were 6 mos ago (0.11) and 2 years ago (0.10). While it would be nice to have a 1.0 release in the tree, there's a purpose behind point releases. IMO, Lithium hit 1.0 a long time ago, it was just never tagged as such. Version 0.X means core interfaces and implementations are subject to change; version 1.X means no backwards compatibility changes. What was the last change that broke backwards compatibility?
@Ciaro
Contributor
Ciaro commented Apr 20, 2013

... it's not where it could be. Not a finger pointer, just sad this is the case right now.

A more listy approach:

also don't like the fact that li3 makes all the other frameworks look 'ugly', but that's probably a good thing ;)

P.S. I don't think open source means making other people doing the job, @jails @gwoo. If I could do the job, I would do it. It's just above my paygrade. But I do try to contribute to Lithium if I can, when I can, where I can...

@rapzo
Member
rapzo commented Apr 22, 2013

I don't like not being able to keep up as fast as others do, but that is more about me than about the tool itself eheh. But i have to confess, sometimes it still looks like rocket science hehe.
@Ciaro was on spot with some things such as the roadmap. I think if there was more info people would try to contribute more... You guys know lithium is top notch in the framework talk (let's keep it only with php from here) you talked about it so, the lack of orientation may be the major issue around the lack of contributions. It's not easy to master the best tool.
Also, i miss the labs... It was such a great idea, plugging with composer, it could be the npm for lithium stuff.
Oh, and the docs. Please guys, write down a roadmap, hack day or something, there would be a bunch of dudes (myself included) willing to help out where needed, no doubt in that.
Oh, upgrading sphere, pastium and other stuff would be a good idea. They don't work properly so, they could use a hand or two.
Rest of it, i bloody love lithium, its brand, its lemma and stuff and it's the only thing i use to rig php (that util stuff is handy everywhere, as others) and probably will be the last since php had seen better days so, keep up the awesome work fellaz.

@nateabele
Member

First of all, great thoughts everyone, thanks for all your feedback so far.

@Ciaro:

session/cookies still has a lot of unresolved issues.

I agree there are still some outstanding issues with sessions and cookies that need to be resolved. Just so I have all the details (and maybe this should be a separate issue), what do you see as being the big issues, and how would you see that interface working?

@SayB
SayB commented May 5, 2013

@mackstar this is an attempt to make Lithium's model layer available to any project in any framework and / or flat php for that matter:

https://github.com/SayB/Li3Models

I guess now you can check that off your list :)

@mackstar
Member
mackstar commented May 5, 2013

@SayB Thanks I am glad you are looking at this, but I am thinking about having a UOR driven 'Active Record' based library based on what we have learnt from #li3 models. There is a gaping hole in the PHP open source world for a decent library that is not Doctrine - which I am sure is why you created your library. Maybe you could help us in this?!

Cheers

@SayB
SayB commented May 5, 2013

@mackstar helping out in building such a library would definitely be exciting ... however, I wonder what else would need to be added ? - if not then it's just a matter of carving out the relevant classes and we're done, no ?

@ghost
ghost commented Jun 20, 2013

First I would just like to say, I've been using lithium for a while now and it's been such a boon to productivity. It is such a great balance between having an opinionated framework and something that is flexible enough to not get in your way. It is pretty amazing that whenever I run in to a problem that seems like it would clash with how lithium does things by default, I'm usually able to solve it with reconfiguring behavior via some class extending Adaptable. That being said here are two things I'd like to see.

  1. More documentation, specifically on how the filter system can completely modify behavior. I feel like most people don't "get" this. The filter system is basically a built in way to add middleware to literally any method of any class. It is a great design that needs to be promoted much more. This kind of idea is promoted way more in other communities, specifically in node and the Express framework.
  2. 1.0 Release. It seams like 0.11 has been the standard for anyone who wants to use lithium for too long. Are relationships in Mongo the only thing holding this up? At least a new stable build would be nice. Lithium has changed significantly since 0.11.

Other than that, I could probably nitpick over other issues that would make the framework seem more legit or trendy, but really those are the two things that are holding lithium back in my opinion. When I first started following lithium, there was a great deal of excitement, especially after using CakePHP for some time. But like others have said before me, because 0.11 has been around for so long, I almost felt like the development had stopped and that the project was dead.

I know the framework very well at this point, so please let me know your vision for a 1.0 release and I will try to contribute as much as I can.

@ThomasWunderlich

I'm using lithium in production at work and what we've found that lithium itself is very inefficient, in particular with the models/ORM. Retrieving > 6 records means rewriting to directly connect to the database. At the same time, we see the memory spike on each request so it's slow and memory-intensive.

The other problem is that we still haven't found a really good way to debug lithium problems because of the use of filters. Has anybody found a good way to debug the filters?
XDebug died when one of our other devs used it.

Besides that the other problems have been mentioned already: better/more documentation and tutorials, composer integration

@ericcholis
Contributor

@ThomasWunderlich I debug Lithium using XDebug on a Windows box and never have any issues. Currently, I'm using PHP 5.4.11 and XDebug 2.2.1. Perhaps your xdebug.max_nesting_level is set too low?

@ThomasWunderlich

@ericcholis The other dev said he hit 175 levels, so I'm not sure what he was debugging. I would hope that he wouldn't have to increase the levels above that. Obviously something caused it to go recursive but I didn't ask what.
But thanks.

@tmaiaroto
Member

Weird, I've always seen Lithium perform very well with profiling. Part of why I love Lithium is because of its high performance. I'd be careful with how many filters you use. They are a wonderful feature with Lithium, but they must be used appropriately. Yes - debugging them is difficult and it may also be the source of some of your performance issues (and recursive issues) depending on what you're doing.

@jails
Contributor
jails commented Jul 11, 2013

@ThomasWunderlich, thanks for reporting, however it would be really interesting to see the code behind these performance issues, otherwise we can't do much to improve things.

@kszucs
kszucs commented Dec 14, 2013

I often recommend Lithium to my coworkers.
Firstly all of them are impressed, but shortly after they recognize the lack of manual and particularly the incompleteness of mongo relations they just turn away.

The latter one would be wonderful as a Christmas Gift!

@blainesch
Member

@kszucs
The funny part mongo relations, but I completely understand. You can still have mongo relations I believe there are a few plugins our team has developed/used.

li3_fake_model
li3_relations

The li3_fake_model does a bit more specific to our needs like not creating excessive objects for nested items in your mongo object, and does great with relationship querying for performance boosts.

@davidpersson
Member

@nervetattoo, @ericcholis There is now an "in the wild"/built with li3 section in the wiki at https://github.com/UnionOfRAD/lithium/wiki/In-The-Wild.
@ericcholis There's now a page with all presentations and talks I've found so far at https://github.com/UnionOfRAD/lithium/wiki/Presentations%2C-Press%2C-Audio-and-Video.

I hope that at some point we can just interface with the github wiki and pull/parse data from those pages in order to integrate it in the li3 website. That however is just an idea and would work only if those pages are kept structured.

@intel352

Sucks that the old domains have been lost (i.e. - lithify.me now goes to Lithium SEO), yet Google still associates lithify.me with Lithium framework.
The website still is in sore need of love.
Clicking on forum (aka sphere) takes you to https://blog.engineyard.com/ as the intended URL no longer exists.
Support > bin still links to Pastium which is pretty much dead, switch to Gist already.

But really the biggest flaws with Li3 have already been covered. Website is lacking when you compare to the likes of Yii, Symfony, Laravel, etc. Still not at v1.0 final (which is a shame, as this framework was launched around launch of 5.3, yet now PHP 5.5 is out, with 5.6 on the way). And community doesn't feel immediately accessible (meaning, easy to find).

@tmaiaroto
Member

Ugh...and lithium so isn't considered an issue by lithium technologies?? Guess we'll see. What a crock of poo poo. The whole domain thing is a great example of what's wrong with our entire industry and why it's such bs. Stuff like that makes me want to change careers to one where there aren't little kids with severe mental health issues running things.

Anyway, (rant aside) I agree about lack of guides, etc. Though I wouldn't worry so much about a "stable" tag. I mean we can put one on there really... but look at frameworks like Laravel for example. That is a wonderful example of why you don't slap "stable" on things for fun. The framework is on a 6 month release cycle (by its own choice), suffers from horrendous breaking changes and it's API is caught in the balance between core Laravel architecture decisions and Symfony2 API changes. This gets in the way ALL the time. It's one of the most unstable frameworks I've seen to be honest.

@fitzagard
Contributor

My thought, Li3 is so superior that most folks are too afraid to jump in. It's like a form of atychiphobia where the fear to use and contribute is unwarrented and unfortunate. I believe a bit of love to the Li3 website, setup guide, docs could address this fear. At the moment, folks (more-so beginner PHP devs) have to dig deep to find out why they should even pick it up. Its awesomeness is hidden. There, I said it!

I wish to re-iterate the sentiments mostly stated above:

  • Teach best practices of Li3 throughout the documentation
  • Boil to the top the “selling” features of Li3 for the laymen. When the PHP Dev tells his PM about it and PM subsequently googled Li3, the 10,000 foot view from the main page is “welcoming”.
  • It would be great to have a clean and searchable forum (besides IRC and stackoverflow)
@rmarscher
Contributor

Nice to see some life here in this thread. Let's get this project to 1.0, expand the docs, and redesign/reorganize the website. So then we can feel satisfied we completed this project and can all move on recreating it on node.js ;)

I've been using a version of lithium in production from somewhere around the 0.10 release with a few custom bug fixes for many apps over the last few years. I've been sort of waiting for that 1.0 tag to go about migrating... and just lazy. If it ain't broke...

I could see the use of traits helping with everything needing to extend from StaticObject and Object to add filter and dependency injection support. Making something Adaptable could also be a trait.

I've been using a trait to turn models into mocks by replacing a few methods and using a mock database connection. I think initially the reaction to traits was that we had a hard time getting people to 5.3, we shouldn't now require 5.4. I thought maybe people would be upgrading the minor php release numbers a little more regularly now. But w3techs shows 5.3 still has a lot more usage compared to 5.4 and 5.5. I mean... who doesn't want to upgrade to 5.5 just to not have to write array() anymore?

@davidpersson
Member

I've been silently working on a redesigned and restructured website and hopefully have something to look at in the upcoming 2 months :)

@intel352

Not so secret now eh? ;-)

On Wed, May 21, 2014 at 11:23 AM, David Persson notifications@github.comwrote:

I've been silently working on a redesigned and restructured website and
hopefully have something to look at in the upcoming 2 months :)


Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/issues/887#issuecomment-43769691
.

@intel352

Er, silent rather. Damnit fast response!

On Wed, May 21, 2014 at 11:23 AM, Jonathan Langevin jon@langevin.me wrote:

Not so secret now eh? ;-)

On Wed, May 21, 2014 at 11:23 AM, David Persson notifications@github.comwrote:

I've been silently working on a redesigned and restructured website and
hopefully have something to look at in the upcoming 2 months :)


Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/issues/887#issuecomment-43769691
.

@rapzo
Member
rapzo commented May 27, 2014

@davidpersson let me know if you need an extra hand. Would love to help. I just lack the commitment to do it alone.

@davidpersson
Member

@rapzo thanks for offering a helping hand :) I don't yet have a fix roadmap for the new site, thus I don't want to promise too much up front.

I'll be creating a repository containing my current local changes (these will form the basis for the new site) once I'm not busy with other stuff anymore.

Once I'm this far I'll determine what needs to be done. We can coordinate via the li3-core channel. Then get our hands dirty. I'll notify you once there's a repository available for everyone to see.

@rapzo
Member
rapzo commented May 29, 2014

Aye cool! Count me in.

On Thu, May 29, 2014 at 1:22 PM, David Persson notifications@github.com
wrote:

@rapzo https://github.com/rapzo thanks for offering a helping hand :) I
don't yet have a fix roadmap for the new site, thus I don't want to promise
too much up front. I'll be creating a repository containing my current
local changes (these will form the basis for the new site). Once I'm this
far I'll determine what needs to be done. We can coordinate via the
li3-core channel. Then get our hands dirty. I'll notify you once there's a
repository available for everyone to see.


Reply to this email directly or view it on GitHub
#887 (comment).

Rui Pedro Lima

@d1rk
Member
d1rk commented Jun 2, 2014

@davidpersson me, too.

@davidpersson
Member

aight :)

@davidpersson davidpersson added the website label Aug 3, 2014
@y-lohse
y-lohse commented Jul 1, 2015

I'm considering lithium for a project but after taking it on a test drive yesterday, I'm not really convinced. The promises and approach seems really good and I want to like it, but:

  • The composer installation is broken. Something about the framework distro not being flagged as stable.
  • The idea of distros is nice but there is no list available and in fact "framework" seems to be the only one, so meh…
  • After a manual installation, I start the example and get a deprecation notice regarding Mongo and MongoClient. Sure, it's easy to fix, but still.
  • I then noticed that the 1.0 has a beta flag and is untouched for over a year. Does not reflect well on stability or activity.
  • I switched to the 1.1 branch and get internal deprecation notices (something about String and Text I think)
  • I wanted to use a plugin, it did not autoload for whatever reason, and then I had to fix a bug in it (likely because it was meant for 1.0, not 1.1).

The things that work are elegant and work well, but overall and from the outset I'm not sure li3 is production grade yet.

@intel352
intel352 commented Jul 1, 2015

@y-lohse it's definitely not. Afaik, it's never hit a final stable release (as you noted, 1.0 is still beta). Additionally, I think it's important to have a thriving community around a project, to warrant it's usage, because then there's less chance it becomes abandonware. lithium has a small dedicated community, but pretty much only in IRC or similar. It's a real shame, as when lithium first hit the scene, it was extremely promising. Since then, Symfony 2 has iterated multiple times, and now with Laravel available & a large community surrounding it, I don't see how lithium can be justified right now, except to do something different, but not for everyday use.

@y-lohse
y-lohse commented Jul 1, 2015

Thanks for the clear answer! I agree, what a shame :(. The search goes on.

@tmaiaroto
Member

@y-lohse @intel352 I wouldn't say Lithium isn't "stable" - it just hasn't yet labeled itself as that "1.0" we all cling to (please do keep in mind that nothing is "stable" on the web). The Lithium team is very careful about these things (there's a roadmap somewhere) to avoid "maintenance hell."

Lithium is most certainly production grade and has been used in production for many years for many projects with very good results. I assure you, it is extremely capable.

In fact, I do agree with your findings @y-lohse and they are items of discussion and are in the process of being addressed. I would suggest trying the dev branch in the meantime (not 1.1 - unless something has changed and my understanding is dated).

Composer does indeed work with Lithium. Though I'm not a fan of it because it's slooooooooowwwwwww as all heck, but fortunately Lithium doesn't use its autoloader. So I can live with it for dependency management (which is also fairly slow, but recently got faster).

If you are looking for something a little more opinionated, I could definitely see where Lithium isn't cutting it. You'll likely need to make your own set of boilerplate code that you can use for your projects that's a bit more opinionated (I use https://github.com/tmaiaroto/blackprint - fair warning, work in progress, but might give you some ideas).

Definitely good to hear more feedback!

@ericcholis
Contributor

I agree with @tmaiaroto on this one, I've been using the dev branch in production for almost a year now, and the master branch for two years before that. Both branches on a site that gets 1.5 million+ pageviews per month.

Actually, very rarely have I come across instabilities that were entirely the fault of li3. Also, in the event of a bug, the project maintainers and community have fixed it rather quickly. I recommend looking through the issues and commit history to see what I'm talking about.

Lithium feels more like a solid foundation for your own project, rather than a large toolbox like Symfony. WIth that being said, Composer allows amazing flexibility to include many things that might not be included. Hell, you could even skip the built in ORM and use something like Doctrine or Propel if you felt that Lithium's wasn't cutting it.

As for the small community, it can't get larger on it's own. People need to use and contribute in order for it to grow. It seems that Laravel landed at the right time and was picked up by the community rather quickly.

@SayB
SayB commented Jul 1, 2015

Guys ... this has not helped me to sell the idea to my employers at all!
... I've got the same answer twice: "It's not production ready yet". The
only way I can see me using Li3 now is for my own projects.

On Wed, Jul 1, 2015 at 10:15 AM, Eric Cholis notifications@github.com
wrote:

I agree with @tmaiaroto https://github.com/tmaiaroto on this one, I've
been using the dev branch in production for almost a year now, and the
master branch for two years before that. Both branches on a site that gets
1.5 million+ pageviews per month.

Actually, very rarely have I come across instabilities that were entirely
the fault of li3. Also, in the event of a bug, the project maintainers and
small community have fixed it rather quickly. I recommend looking
through the issues and commit history to see what I'm talking about.

Lithium feels more like a solid foundation for your own project, rather
than a large toolbox like Symfony. WIth that being said, Composer allows
amazing flexibility to include many things that might not be included.
Hell, you could even skip the built in ORM and use something like Doctrine
or Propel if you felt that Lithium's wasn't cutting it.


Reply to this email directly or view it on GitHub
#887 (comment).

Regards,
Sohaib Muneer
Voice: 647-983-5903
http://blog.sohaibmuneer.com

@ericcholis
Contributor

edit: Realized that my comments might have been a bit standoffish

Sorry @SayB, perhaps some production metrics would be helpful. To reiterate:

I've been using the dev branch in production for almost a year now, and the master branch for two years before that. Both branches on a site that gets 1.5 million+ pageviews per month.

Production ready, in my opinion, is defined by the needs of the organization. In my case, when I started my project, I needed a strong PHP 5.4+ framework with baked-in support for MongoDB. What I got was a solid foundation that has been easily extensible. My needs have since shifted, but have always been met given the nature of the PHP community. Composer and it's packages filled any gaps that Lithium may have had.

As for stability and performance:

Last 3 months July 2014 to June 2015
Response Time 295 ms 276 ms
Uptime 100% 99.87%
Requests (millions) 6.8 8.1

Downtime has been attributed to bad user-code, network issues, or 3rd party service issues. With the advent of PHP 7, I'm hoping to see average response times below 200 ms.

You should, of course, use this information anecdotally and compare the available frameworks to decide what is best for the needs of your project and organization.

@jails
Contributor
jails commented Jul 1, 2015

@intel352, in nowaday's developement, I'm not sure there's still some "bug free" libraries around. So flagging a library as "stable release" doesn't make it more stable. If you are looking at Symfony issues or even Laravel, the li3 ones are for most of them enhancements and not bugs related.

Personnaly I'm not choosing a library according to the community around. If the code base of a library doesn't make a lot of sense, no matter the community is, I'll do my best to avoid using it. Sooner or later you will need to dig into the code base of the libraries you are using to deal with some core bugs. Moreover, if the library contains some bad architecture choices it will leads you right up the wall. So you can easily waste all your profits to deal with some "unsortable" mess. I know the community size reassures people. Indeed nobody want to be alone when something bad happen. But how something bad can happen if you are understanding the libraries you are using ? I know it's quite an investment, but wasting your time posting issues and beg for help is quite time consuming too and won't make you a better coder.

@y-lohse However it'll mostly depends on your need. If you need a lot of well defined features and are somehow compliant and not well experimented. Using a framework with a big community behind will help you to be productive in no time. But if you want to go rogue, you will waste the time you gained in the first part to finally get a messy application.

Personnaly I'm using li3 as a kind of toolbox and using some dedicated libraries for doing a job instead of following the "framework way" and get stuck as soon as I'm facing a custom use case. And nowaday with Angular, React and all other front end tools around, li3 could be splitted up even further.

@tmaiaroto
Member

@SayB Ask them why.

I've been in your shoes before and I completely understand and sympathize with you. There comes a time in every programmer's life where the training wheels come off and they realize that version numbers are not an indication of "stable" or "production ready" but rather numeric devices intended to signify changes and what you're working with. That web and software and computers aren't as reliable as we'd like to believe. Unfortunately this time never comes for "employers."

@davidpersson
Member

@y-lohse

The composer installation is broken. Something about the framework distro not being flagged as stable.

Initialization of projects through composer is something we will be supporting from 1.1 onwards. We've made the availability issue in the documentation a bit clearer by rewording the notice.

bildschirmfoto 2015-07-02 um 10 49 27

Installation of lithium (aka the core libraries) using composer is independent from that issue, this one already works for a long time.

The idea of distros is nice but there is no list available and in fact "framework" seems to be the only one, so meh…

The notion of distros is also something new, we're planning for at least one more distro in the future.

After a manual installation, I start the example and get a deprecation notice regarding Mongo and MongoClient. Sure, it's easy to fix, but still.

This might be because you've been using the master branch distro together with the future 1.1 lithium (which is currently in flux). Or some other combination. I'd suggest to try the 1.0 branch of the distro with the latest dev branch of lithium. The lithium dev branch has the mongo fixes.

I then noticed that the 1.0 has a beta flag and is untouched for over a year. Does not reflect well on stability or activity.

Have a look at the dev or the 1.1 branch or the issue tracker. We're continuously working on the project. However the master branch really needs a merge from dev, as dev holds lots of good stuff. We're planning for a new release once the last remaining bug on 1.0 has been fixed and some other changes we'd like to make before going 1.0 have been applied.

I switched to the 1.1 branch and get internal deprecation notices (something about String and Text I think)

As mentioned above that branch isn't stable yet.

I wanted to use a plugin, it did not autoload for whatever reason, and then I had to fix a bug in it (likely because it was meant for 1.0, not 1.1).

Which plugin did you try to use? Maybe I can help there.

@y-lohse
y-lohse commented Jul 3, 2015

It was this one but thanks, i fixed the issue :-). Our requirements are also shifting so choosing a framework is a little post-poned anyway.

I'm glad to see all the responses this generated and will definitely keep an eye out on lithium. It looks like the issue is more with communication and updating docs than with the codebase itself, which is less of a problem :p

@tmaiaroto
Member

I definitely agree. There is a bit of confusion and everyone is busy with things so it's hard to take the time to clarify. Have you seen this documentation repo? https://github.com/UnionOfRAD/manual

Is there anything specific you'd want to see? Tutorials? Designed manual/docs? Any specific issues or questions you had? (aside from the ones listed above - that maybe you eventually figured out on your own, but took some time and was annoying)

@y-lohse
y-lohse commented Jul 6, 2015

I saw the manual on the website, not the actual repo but I guess the content is the same. I didn't mind the way it was designed although a search feature would be helpful.

I think the onboarding would need some love. It's exactly as you said: i eventually figured out how to resolve the issues I had, but had I not experienced them at all I would have been absolutely sold. Of course that's easier said then done :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment