What is CakePHP and what are its top alternatives?
Top Alternatives to CakePHP
It is a web application framework with expressive, elegant syntax. It attempts to take the pain out of development by easing common tasks used in the majority of web projects, such as authentication, routing, sessions, and caching. ...
CodeIgniter is a proven, agile & open PHP web application framework with a small footprint. It is powering the next generation of web apps. ...
The core software is built by hundreds of community volunteers, and when you’re ready for more there are thousands of plugins and themes available to transform your site into almost anything you can imagine. Over 60 million people have chosen WordPress to power the place on the web they call “home” — we’d love you to join the family. ...
Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. ...
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...
Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. ...
It is written with speed and flexibility in mind. It allows developers to build better and easy to maintain websites with PHP.. ...
Yii comes with: MVC, DAO/ActiveRecord, I18N/L10N, caching, authentication and role-based access control, scaffolding, testing, etc. It can reduce your development time significantly. ...
CakePHP alternatives & related posts
- Clean architecture500
- Growing community359
- Composer friendly336
- Open source312
- The only framework to consider for php293
- Quickly develop189
- Dependency injection155
- Application architecture142
- Embraces good community packages129
- Write less, do more57
- Restful routing50
- Orm (eloquent)46
- Artisan scaffolding and migrations43
- Database migrations & seeds42
- Great documentation33
- Awsome, Powerfull, Fast and Rapid25
- Promotes elegant coding25
- Build Apps faster, easier and better24
- JSON friendly22
- Most easy for me21
- Eloquent ORM20
- Easy to learn, scalability20
- Modern PHP19
- Blade Template18
- Clean Documentation11
- Convention over Configuration10
- Based on SOLID10
- Easy to attach Middleware9
- Easy to use8
- Laravel + Cassandra = Killer Framework8
- Get going quickly straight out of the box. BYOKDM8
- Easy Request Validatin8
- Less dependencies7
- Simplistic , easy and faster7
- Its just wow7
- Friendly API6
- Its beautiful to code in5
- Super easy and powerful5
- Great customer support5
- Fast and Clarify framework4
- The only "cons" is wrong! No static method just Facades4
- Active Record4
- Laravel Mix3
- Easy views handling and great ORM3
- Minimum system requirements3
- Intuitive usage2
- Laravel Spark2
- Laravel Passport2
- Laravel Nova2
- Laravel casher2
- Laravel Horizon and Telescope2
- Laravel Forge and Envoy2
- Ease of use2
- Cashier with Braintree and Stripe2
- Rapid development1
- Too many dependency26
- Slower than the other two19
- A lot of static method calls for convenience15
- Too many include13
- Does not work well for file uploads in Shared Hosting4
- Too underrated3
- Not fast with MongoDB2
- Difficult to learn1
- Not using SOLID principles1
related Laravel posts
Back at the start of 2017, we decided to create a web-based tool for the SEO OnPage analysis of our clients' websites. We had over 2.000 websites to analyze, so we had to perform thousands of requests to get every single page from those websites, process the information and save the big amounts of data somewhere.
Very soon we realized that the initial chosen script language and database, PHP, Laravel and MySQL, was not going to be able to cope efficiently with such a task.
By that time, we were doing some experiments for other projects with a language we had recently get to know, Go , so we decided to get a try and code the crawler using it. It was fantastic, we could process much more data with way less CPU power and in less time. By using the concurrency abilites that the language has to offers, we could also do more Http requests in less time.
Unfortunately, I have no comparison numbers to show about the performance differences between Go and PHP since the difference was so clear from the beginning and that we didn't feel the need to do further comparison tests nor document it. We just switched fully to Go.
There was still a problem: despite the big amount of Data we were generating, MySQL was performing very well, but as we were adding more and more features to the software and with those features more and more different type of data to save, it was a nightmare for the database architects to structure everything correctly on the database, so it was clear what we had to do next: switch to a NoSQL database. So we switched to MongoDB, and it was also fantastic: we were expending almost zero time in thinking how to structure the Database and the performance also seemed to be better, but again, I have no comparison numbers to show due to the lack of time.
As of now, we don't only use the tool intern but we also opened it for everyone to use for free: https://tool-seo.com
I use Laravel because it's the most advances PHP framework out there, easy to maintain, easy to upgrade and most of all : easy to get a handle on, and to follow every new technology ! PhpStorm is our main software to code, as of simplicity and full range of tools for a modern application.
Google Analytics Analytics of course for a tailored analytics, Bulma as an innovative CSS framework, coupled with our Sass (Scss) pre-processor.
To deploy, we set up Buddy to easily send the updates on our nginx / Ubuntu server, where it will connect to our GitHub Git private repository, pull and do all the operations needed with Deployer .
CloudFlare ensure the rapidity of distribution of our content, and Let's Encrypt the https certificate that is more than necessary when we'll want to sell some products with our Stripe api calls.
Asana is here to let us list all the functionalities, possibilities and ideas we want to implement.
- Easy setup74
- Open source67
- Well documented59
- Community support34
- Easy to learn21
- Language Suppert7
- Easy, fast and full functional5
- I think it is best. we can make all types of project4
- Works on Every PHP Server like shared hostings3
- Open source, Easy to setup3
- Super Lightweight, Super Easy to Learn2
- Beginner friendly framework2
- No ORM5
- No CLI1
related CodeIgniter posts
I have used PHP to do end to end developments , using Laravel CodeIgniter frameworks.
I have learned Python. I also developed an online Result management system in CodeIgniter for my school but now want to migrate to Django as the system is expanding. Is it a good idea?
- Easy to manage357
- Plugins & themes348
- Non-tech colleagues can update website content258
- Really powerful244
- Rapid website development143
- Best documentation75
- Product feature set42
- Custom/internal social network33
- Open source12
- Great for all types of websites6
- Huge install and user base5
- Most websites make use of it4
- Open Source Community4
- Perfect example of user collaboration4
- It's simple and easy to use by any novice4
- I like it like I like a kick in the groin3
- API-based CMS3
- Easy To use2
- <a href="https://secure.wphackedhel">Easy Beginner</a>1
- Hard to keep up-to-date if you customize things11
- Plugins are of mixed quality10
- Not best backend UI8
- Complex Organization1
- Great Security1
related WordPress posts
I've heard that I have the ability to write well, at times. When it flows, it flows. I decided to start blogging in 2013 on Blogger. I started a company and joined BizPark with the Microsoft Azure allotment. I created a WordPress blog and did a migration at some point. A lot happened in the time after that migration but I stopped coding and changed cities during tumultuous times that taught me many lessons concerning mental health and productivity. I eventually graduated from BizSpark and outgrew the credit allotment. That killed the WordPress blog.
I blogged about writing again on the existing Blogger blog but it didn't feel right. I looked at a few options where I wouldn't have to worry about hosting cost indefinitely and Jekyll stood out with GitHub Pages. The Importer was fairly straightforward for the existing blog posts.
Todo * Set up redirects for all posts on blogger. The URI format is different so a complete redirect wouldn't work. Although, there may be something in Jekyll that could manage the redirects. I did notice the old URLs were stored in the front matter. I'm working on a command-line Ruby gem for the current plan. * I did find some of the lost WordPress posts on archive.org that I downloaded with the waybackmachinedownloader. I think I might write an importer for that. * I still have a few Disqus comment threads to map
Back in the days, we started looking for a date on different matrimonial websites as there were no Dating Applications. We used to create different profiles. It all changed in 2012 when Tinder, an Online Dating application came into India Market.
Tinder allowed us to communicate with our potential soul mates. That too without paying any extra money. I too got 4-6 matches in 6 years. It changed the life of many Millennials. Tinder created a revolution of its own. P.S. - I still don't have a date :(
Posting my first article. Please have a look and do give feedback.
Communication InAppChat Dating Matrimonial #messaging
- Rapid development845
- Great gems647
- Great community603
- Convention over configuration478
- Great for web349
- Beautiful code344
- Open source311
- Great libraries270
- Active record260
- Easy to learn87
- Easy Database Migrations85
- Makes you happy77
- Great routing62
- Has everything you need to get the job done53
- Great Data Modeling41
- MVC - Easy to start on38
- Easy setup35
- Great caching26
- Ultra rapid development time25
- It's super easy22
- Great Resources17
- Easy to build mockups that work16
- Less Boilerplate14
- API Development7
- Developer Friendly7
- Great documentation6
- Easy REST API creation5
- Haml and sass4
- Easy to learn, use, improvise and update4
- Great language4
- Jet packs come standard2
- Easy and fast2
- It works2
- It's intuitive1
- Easy Testing1
- Convention over configuration1
- Too much "magic" (hidden behavior)20
- Poor raw performance13
- Asset system is too primitive and outdated11
- Bloat in models6
- Heavy use of mixins6
- Very Very slow3
related Rails posts
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.
Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!
#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit
- Large community937
- Open source800
- Easy deployment754
- Great frameworks480
- The best glue on the web384
- Continual improvements230
- Good old web180
- Web foundation141
- Community packages130
- Tool support123
- Used by wordpress31
- Excellent documentation30
- Used by Facebook25
- Because of Symfony23
- Dynamic Language16
- Awesome Language and easy to implement14
- Fast development12
- Cheap hosting11
- Very powerful web language11
- Flexibility, syntax, extensibility9
- Because of Laravel9
- Easy to learn7
- Short development lead times7
- Worst popularity quality ratio7
- Fastestest Time to Version 1.0 Deployments7
- Readable Code7
- Easiest deployment6
- Faster then ever6
- Most of the web uses it5
- Open source and large community4
- I have no choice :(4
- Easy to learn, a big community, lot of frameworks3
- Is like one zip of air3
- Has the best ecommerce(Magento,Prestashop,Opencart,etc)3
- Cheap to own3
- Simple, flexible yet Scalable3
- Easy to use and learn3
- Hard not to use2
- Large community, easy setup, easy deployment, framework2
- Safe the planet2
- Walk away2
- Great flexibility. From fast prototyping to large apps2
- Used by STOMT2
- Great developer experience2
- Open source and great framework2
- Fault tolerance2
- Interpreted at the run time2
- So easy to learn, good practices are hard to find19
- Inconsistent API16
- Fragmented community8
- Not secure5
- No routing system2
- Hard to debug1
related PHP posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
- Rapid development602
- Open source446
- Great community387
- Easy to learn337
- Beautiful code201
- Great packages179
- Great libraries167
- Comes with auth and crud admin panel52
- Great documentation48
- Great for web46
- Great orm31
- Great for api27
- All included21
- Web Apps17
- Used by top startups14
- Easy setup11
- Convention over configuration8
- Allows for very rapid development with great libraries5
- The Django community5
- Its elegant and practical3
- Great MVC and templating engine3
- Easy to use2
- Easy to develop end to end AI Models2
- Easy Structure , useful inbuilt library2
- Fast prototyping2
- Full stack2
- Batteries included2
- Great peformance1
- Many libraries1
- Zero code burden to change databases1
- Have not found anything that it can't do1
- Very quick to get something up and running1
- Just the right level of abstraction1
- Python community1
- Full-Text Search1
- King of backend world1
- Underpowered templating24
- Underpowered ORM19
- Autoreload restarts whole server18
- URL dispatcher ignores HTTP method15
- Internal subcomponents coupling10
- Not nodejs7
- Configuration hell4
- Not as clean and nice documentation like Laravel3
- Bloated admin panel included2
- Not typed2
- Overwhelming folder structure2
- InEffective Multithreading1
related Django posts
Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.
Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.
For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.
However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.
All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.
- Open source168
- Dependency injection122
- Modular architecture62
- Smart programming42
- LTS releases11
- Easy to Learn6
- Good practices guideline5
- Decoupled framework components5
- Service container4
- Too many dependency9
- Lot of config files7
- Feature creep2
related Symfony posts
I really love Django because it is really fast to create a web application from scratch and it has a lot a facilities like the ORM or the Admin module ! The Python language is really easy to read and powerful, that's why I prefer Django over Symfony.
I use Django at work to make tools for the technicians but I also use it for me to build my personal website which I host on PythonAnywhere, and with a domain name bought on Namecheap.
We needed our e-commerce platform (built using WooCommerce) to be able to keep products in sync with our #pim (provided by #akeneo) which is built in Symfony . We hooked into the kernel.event_listener to send RabbitMQ messages to a WordPress API endpoint that triggers the updated product to rebuild with fresh data.
- Open source38
- Code generator30
- Active record27
- Full featured24
- High performance19
- Rapid development18
- Not bloated9
- Long Term Support6
- Stable Release6
- View Helpers5
- Modular architecture4
- Easy setup, easy develop3
- Unnatural love of arrays1
- Too Opinionated1
- Promotes bad practice1
- Promotes spagetti code1
related Yii posts
Of all PHP frameworks, my best and only choice is Yii . Think of this: you have a MySQL database, it contains several tables. Now you want to setup a PHP-MVC site, firstly, you must create Models, Yii have a very handy tool called Gii, you can easily create model with Gii just by one click, Gii will read your database table columns and create PHP models automatically for you. Now you need Controller, still with Gii, it will automatically create all 4 php files for you with Insert/Delete/Update/Select even with Search function.
Well, now the most modern way is to have a RESTful API, that's even easier with Yii, you even don't need to care about all the columns, just 4 lines of code you can expose your database table as RESTful API with all GET/POST/PUT/DELETE support, even you change your database table columns, you don't need to change any PHP code.
For security, Yii have embedded authentication and RBAC support. For multi language, Yii have embedded i18n support, all with out-of-box. Just play with it, I bet you will love it.