UnionOfRAD / lithium

li₃ is the fast, flexible and most RAD development framework for PHP
http://li3.me
BSD 3-Clause "New" or "Revised" License
1.22k stars 237 forks source link

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

Closed jails closed 6 years ago

jails commented 11 years ago

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 commented 11 years ago

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

fduarte commented 11 years ago

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.

bayleedev commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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!

Just some ideas

nervetattoo commented 11 years ago

Great initiative :)

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 commented 11 years ago

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)

bayleedev commented 11 years ago

@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 commented 11 years ago

@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 commented 11 years ago

@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 commented 11 years ago

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

i would like to see

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

brandonwestcott commented 11 years ago

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 commented 11 years ago

Concur with most of these sentiments:

My own frustrations:

Ciaro commented 11 years ago

... 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 commented 11 years ago

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 commented 11 years ago

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?

Ciaro commented 11 years ago

@nateabele https://github.com/UnionOfRAD/lithium/issues/618#issuecomment-8104595

SayB commented 11 years ago

@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 commented 11 years ago

@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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

@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 commented 10 years ago

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!

bayleedev commented 10 years ago

@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.

mariuswilms commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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:

rmarscher commented 10 years ago

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?

mariuswilms commented 10 years ago

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

intel352 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

mariuswilms commented 10 years ago

@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 commented 10 years ago

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 https://github.com/UnionOfRAD/lithium/issues/887#issuecomment-44525944.

Rui Pedro Lima

d1rk commented 10 years ago

@davidpersson me, too.

mariuswilms commented 10 years ago

aight :)

y-lohse commented 9 years ago

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 things that work are elegant and work well, but overall and from the outset I'm not sure li3 is production grade yet.

intel352 commented 9 years ago

@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 commented 9 years ago

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

tmaiaroto commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/UnionOfRAD/lithium/issues/887#issuecomment-117690821.

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

ericcholis commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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."