As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am starting a new Symfony project that will be very important to my company. My experience is only with Symfony 1.4. and I have 3 months to complete the project.
The project should be around for years and will grow to have many features. I know that many people are already using Symfony 2 in production, but do you think it's a bad idea to go with 1.4?
Every situation is different. I don't see any problem with 1.4, but some people are suggesting I use Symfony 2 because eventually we will need to upgrade and do a lot of rewriting of code.
Plus, there is Doctrine 2. I would be using 1.2.4. Again, I know that Doctrine 2 is really great, but am I going off a cliff by sticking with 1.2.4? It seems to do everything we need.
Thanks for any insight.
Why you should use Symfony 2.0:
Faster. Many Symfony components have seen performance improvements and it also now supports edge side includes.
Fixes weaker design. Symfony 1.x is great, but some components had flaws, like logging (now outsourced) and tasks (more flexible). Forms in 1.x were powerful, but had some flaws; forms in 2.0 are better.
It's the future. Symfony 1.x will expire before the lifetime of your project. You already said you will be rewriting it. It makes no sense to wait.
Cleaner, easier code. Namespaces, more decoupling, generally even more beautiful than Symfony 1.x was.
Doctrine 2.0. Way faster, way easier to use.
The only possible reason to go with 1.x is time concerns. However, if this project is that important, it makes more sense to increase the time limit (if it is unfeasible), then to do it in 1.x and waste all that time rewriting it later.
Well, Symfony 2.0 should really be your bet if you had more time to get the project done. Symfony 2.0 developers are still struggling to learn the right way to use all those nice standards and best practices.
The community using SF 1.4 is already mature and has solved every single problem that all the common (and others not common) scenarios could present.
All those arguments about speed do not apply to 90% (or more?) of projects built on SF. Unless you need a high performance webapp (serving more than 500-1000 requests/minute), you gonna be fine using SF 1.4. If you need to serve more than that you can always using one more server to the scene. An optimized SF 1.4 app can perform pretty good.
I'm trying to say that all the talk about performance is not a problem for most apps. People do not think about it when raising the speed flag.
SF 1.4 is a well structured framework. It really speed things up during development. SF 2.0 is a community under development. People are still developing solutions and plugins for the most common problems.
I'm still using SF 1.4 for all my new projects. Mainly because I got a lot done on it that get my projects done really fast. All my customers don't need a high performance webapp, however I have my own projects that need to be fast and after optimization they really are.
I've struggled with this since 1.0. Ok great i finished my 1dot 0 project wicked fire it up...no wait there is now 1.1...ok upgrade go through all the upgrade troubles... ok cool NOW it's ready to go but no wait 1.2 is out now...FFS... ok upgraded everything to 1.2 struggled through learning this new forms class and plugin issues cuz sfGuard needs a new version blah blah blah... ok now we are ready to go fire it up but no wait...they've release 1.3 AND 1.4 on the same day WTH. Ok how bad is this upgrade going to be??? phpmailer good swiftmailer bad. or is it the other way around this time. Oh FFS what is this symfony2 all about now.....
I'm sure i'm not the only one that has gone through that (or similar scenario)
what matters is what YOU know and what YOU are good at. Symfony 2 i'm sure is great awesome best ever blah blah blah. But if it takes you three months to get up to speed and work all the bugs out that WILL come up. Then you're better to go with 1.4 and build on what you know.
I'm sticking with 1.4 because i have a large code base that i've built up that works just fine. As you can see by the varied opinions though the debate could rage on for a while.
That's my two cents anyway.
I'm still doing my projects in Symfony 1.4, but outlining a strategy for yourself on how to make those changes towards 2.0 would be a good idea. Also, it sounds like there is some frustration with Doctrine, and Propel development seems to have been awakened. There may be a switch in many preferences towards Propel in the future.
Short term:
If you know that sf1.4 allows you to finish the project in the time you have doing all the stuff requested by the customer go with that.
Pro: you know it, no costs for you on technology
Cons: end of support November 2012, Lime for testing (or plugin for PHPUnit), using an "old" solution
Long term:
As you said the project should be around for years so I think that many developers will work on it. Sf2 is much more decoupled and uses PHPUnit for testing. Allows you to use ESI and performs very good with HTTP standards (no application cache).
Pro: brand new tool, very active project, a couple of steps above sf1.4, as web will evolve also Sf2 will embrace that changes and support development
Cons: you don't know it but you can hire someone to help you (GTD and learning a new framework)
Getting things done is more important than using the latest and greatest and although symfony 2 appears to be a better version all round, symfony 1.4 is still a great product, has a greater pool of knowledgeable developers and therefore if you do hit any stumbling blogs, you are much more likely to find a solution in a much shorter time.
For your purposes symfony 1.4 is good enough and will give you a greater appreciation of symfony if and when you decide to move over to symfony 2.
There are enough similarities between the versions to be able to gain useful knowledge through using symfony 1.4 and it means that for now, you get the best of both worlds -- useful experience for later on and getting things done.
Go with Symfony 2.
I'm doing the switch from 1.4 to 2 right now because of the advanced ACL features of Symfony 2.
It will save you a lot of time in the end.
I would go with symfony 2. You have all the feature improvements (faster, doctrine 2, etc etc etc), but that is not why I would go for it.
Symfony 2 has had thorough security testing, which is vital for any real project. Add tot hat the fact that long term support won't cover your projects lifetime, and it really is neccessary to build it in 2.
I just started my first project in SF2, after working for a few years in sf 1.x. There are a lot of changes, but it didn't take too long to adapt.
Related
I know that Symfony2 has been released, but is it production ready, or are they still finding and fixing so many bugs as to make it impractical?
How is performance in a production environment? Are there current benchmarks anywhere?
I'm looking to build an n-tier web site and am deciding on whether learning sf2 will be time well spent compared to just sticking with sf1.4.
What gaps are there in symfony2 - from what it seems there's no official admin generator. Is anything else missing?
I have released a Symfony 2 based project that was featured in a major newspaper and did well. I'd deem it as production ready. I also did some load tests with jMeter and the man from the hosting company was impressed by the performance.
The only thing lacking IMO is the amount of tutorial and special articles that you have for Symfony 1. Nevertheless, I'll use Symfony 2 for all my future projects.
One slight problem at the moment could be the hosting companies: You absolutely need PHP 5.3 (most companies still offer 5.2 only) and a caching mechanism (APC or memcached) for maximum Doctrine 2 performance.
Symfony2 is definitely production ready. The developers are just fixing minor bugs since the stable release. I know Fabien Potencier published some benchmark tests a while ago, but I can't find them. Maybe you'll have better luck. Anyway, I believe it's faster than any other framwork out there.
You're right when you say there isn't an official admin generator, but you can use SonataAdminBundle, which is absolutely awesome (but a little hard to get to work properly).
See here regarding the admin generator - apparently there is one :)
symfony2 propel crud generator
I have a website written in Symfony 1.4. It was my first symfony website and the learning curve was a bit steep for me. It is a fairly complicated website, and I don't want to 'fix it' if its not broken.
Having said that, since sf 1.4 is now legacy code, I will eventually want to port the site to sf 2.0. as a matter of fact, I am relaunching the site early next year, and I want to know if I might just as well bite the bullet and "port" the site from 1.4 to 2.0 in one go.
So, I need to know answers to the following:
How much of what I already know from 1.4 is applicable to 2.0?
Are there any jobeet or askeet type tutorials out there that show how to build an entire app using the sf framework?
Am I mad, thinking of porting a big website in effectively just over a month (working only part time?) - i.e. is the "big bang" approach the wisest/only approach?
I don't want to 'fix it' if its not broken.
Don't!
Am I mad, thinking of porting a big website in effectively just over a month (working only part time?)
Yes, you are! :)
Symfony2 and symfony 1.4 are wildy different. We're not talking about some updates to symfony 1.x, we're talking about a brand new framework from the ground up. It's really like asking "How hard would it be to switch from symfony 1.4 to Zend Framework/Kohana/Yii/CakePHP/etc...".
I moved a project (in its very early stages) from symfony 1.4 to Symfony2 and found that except for my familiarity of the MVC pattern, not much (if anything) else was transferable from symfony 1.4 to 2. We're talking about new directory structures, new classes, Doctrine 2, the (awesome) Dependency Injection Container, and more.
Symfony2 has its own learning curve, and even though the architecture is better than symfony 1.4, you will be spending a good amount of time going through trial and error and reading the docs.
Symfony2 is great, and I recommend learning it, but do so at a manageable pace. There's a number of tutorials online - check them out and go through the official Symfony2 docs and cookbook when you're ready.
#Arms response is fantastic. Even though the answer has been accepted, I thought I'd add a few of my thoughts to the discussion.
I started work on the development of a personal project about a year ago. I chose symfony 1.4 because Symfony 2 wasn't in a stable phase and I was already an expert in symfony 1.4.
After working for a year in my spare time (I work a full time job) and this is what I have (and it's still growing, about 60% done):
70,000 lines of php code (Doctrine queries, actions, templates)
10,000 lines of custom javascript code
3000 lines of YAML
My schema.yml file for example is 872 lines which consists of 62 table definitions.
My routing file is 500 lines.
Moving a schema definition of that size over to Doctrine2 entities would be a mammoth task. It would take me a very long time. If I were to rewrite what I've done now to Symfony2. It would probably take me a year.
Transitioning over my current authentication system (sfDoctrineGuard) over to a symfony2 implementation would also big a big task. All my command line tasks, doctrine queries, templates would have to change.
In fact, everything would have to change. The only thing that would stay the same is the database username and password.
If I had the resources and time I would consider moving over to Symfony2. One of the biggest advantages I'd get is the performance gain and the better architecture that Symfony2 offers.
I work with symfony2 at the moment in my full time job and I like it a lot but there are still certain things which I'm not sure how to achieve in symfony2 which I know how to do in symfony 1.
For the moment, moving over to Symfony2 for my project is a definite NO. I'd like to but as I have said I don't have the time or resources to and plus the application is working very well indeed. Everything has been re-factured and I've been careful with the development to make sure I'm not repeating code.
Also, maintenance of Symfony 1.4 is due to end in about a year.
If it works well then don't change it. Only change it when you have the resources available and you're knowledgeable in Symfony2 to make sure you don't give yourself any headaches.
Best of luck.
Symfony 1.4 is not legacy code. It is still fully supported by the Symfony team and has a 3 year support promise which ends at the end of November 2012.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Suppose you spent the last six months on a legacy system project, large corp obsolete web platform, integrating alien data structures.
Now you are finally off and you can go with a brand new startup project in Ruby.
The application will be built from scratch and is up to you to decide which gem you are going to use.
The question can be extended to the various aspects of building a brand new web application, but for semplicity, just suppose you need an authentication system.
Now, the last time you put in place that in Rails, was "authlogic" and it was so cool compared whith "authentication_fu", but while you where "in the cave" you just heard about several other way to authenticate, something like clearance, device, omniauth, warden, sorcery, twitter-auth, open_id_authentication and may others.
Even worst, suppose you can "just imagine" Ruby community is not sleeping and in six months, she was blowing up new ideas and paradigms about "authentication pattern" but you didn't find the time to be updated.
You just want to go outside there, having a look at what's going on, finding all the new gem arising and deciding what fill better your next project.
How do you do it ?
Thanks in advance
Luca G. Soave
UPDATE Sep 18 10:36
Ruby toolbox compares gems in the same category by the metrics described - by Andrew Grimm
UPDATE Sep 17 02:09
Several people tried to clarify the process to discover and choose the right Ruby gem for "the next brand new Ruby project". I'd like to summarize what I learned from everyone by listing what in my comprension are the main steps :
About the process of deciding between gems in the same field:
try a few of them yourself - by semperos
give them each a test drive, make sure there is heavy activity on github, watching last
commits - by ealdent
choose the the Loosely Coupled Gems vs Monolitic Frameworks, giving priority to agile and fast implementation and continuous refactoring - by Craig Stuntz
getting expert of a gem/domain field, in order to be able to decide between gems - by james_schorr
don’t choose “WOW-things and Cool Fresh releases” for your production client projects, but test it daily on minor and private testing projets - by mikhailov
About the process to discover & choose the right gem, the last one by jeremiahd, is a deep, clear and very useful description of the process :
search around for what seem like the most commonly installed libraries that cover my use case
take a look at their documentation, to see how complete and readable it seems
look at the activity in their community : updates - mailing lists - wiki -
IRC - commits - mood
look at their code : test suites - clean code - documents - useful comments -
use their code
quality of the community and code
do it as a learning process, get a better programmer and give back to your community
END UPDATE Sep 17 02:09
Feel free to add more, ... share your point of view.
What I do (when this problem rears it's head in any language) is I search around for what seem like the most commonly installed libraries that cover my use case. I then take a look at their documentation, to see how complete and readable it seems.
Next I look at the activity in their community -- are projects actively updated? Are there easily accessible mailing lists / a wiki/ IRC? How active are they? What's the general tone?
Next I look at their code. Are there test suites? Are they test suites that help me understand the library? Is the code clean? Documented? Commented usefully? Does it look like a ridiculous mess, or like it's had thought put into it at every point?
Next I use their code in a simplified, but similar, manner to how I actually need to use it. Did I run into any major stumbling blocks?
Screw flipping a coin and sticking with it. Sooner or later, whatever lib you're using isn't going to serve your needs, and you'll want to modify it's behavior. When that time comes, the quality of the community and the quality of the code are what make libraries stand out from one another.
This is, of course, a bit fuzzy. And it can be a challenging thing to do, but you'll be a better programmer for it, and assuming you do it enough, you'll probably be contributing back upstream to the libraries you use at some point, which is pretty awesome.
Pick one and run with it. The important point is not what you choose right now, but how hard it will be to change your mind six months down the road. In short, your efforts should not go into making one, permanent decision which will bind you for the lifetime of the project, but on isolating the dependencies on the authorization system to a single (as much as possible) small and easily swapped bit of code.
In my opinion, you should try a few of them yourself.
It seems that Devise has become somewhat of a de facto choice, with mechanisms to support a variety of authentication styles. That might be a nice place to start, but you should obviously try to make it do what you want, and if it doesn't work, try others of the gems you mention.
Rails does not have a "default" authentication mechanism pre-built because authentication tends to be specific to each project. Try several out, see which one fits your needs and programming style best.
I mostly agree with Craig Stuntz, you should just pick one and run with it (and build your app so that it can be swapped out, if possible).
I will suggest, however, that doing that means you give them each a test drive. Perhaps you don't do that in your main project, but really, until you actually use the thing, you will never know just how messed up it is. And no matter how much love the community is throwing at a gem today, you can be sure there are serious issues with it.
For relatively new gems, you also need to make sure there is heavy activity on github or whatever, so that the gem isn't going to stagnate any time soon. If I don't see a commit in the past few weeks, it makes me really uneasy about using a gem that isn't already mature.
I spent a lot of time looking at authentication gems and landed on Devise. It's been great. All of the above tips are great.
I wrote a blog post on this very question - How to pick the right Ruby Gem?
http://www.railstutors.com/blog/how-to-pick-the-right-ruby-gem
The main idea - First check if really need a gem to do what you want; Then some consideration on how to evaluate a Ruby gem. I also happened to use an Authentication as use case so you may find that interesting.
It is my daily choice, what is the way we go tomorrow to satisfy our clients needs. How to be on the edge and keep users happy with stable and reliable system?
First off, we do not accept WOW-things and Cool Fresh releases. We will use new things in 0.5 year, as a tesing period. Yes, we still on Rails 2.3.10. Upgrade to Rails 3 will be next month for us. We have codebase with Core covered by tests, Rspec do great job for us, there is about 94 tests.
But, we try modern gems during daily development and do small projects to see how they work. It's easy and free, take the time only. Railscasts satisfy interest in cool stuff too, it's important to see each of them.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I've to start my master thesis project and I've to choose a technology to work with. I've used Rails and ASP MVC, in two projects, but never used Django, only some play with it. But I've some experience with python and really like the admin interface.
The objective of my master thesis is a creation of portal to a public hospital.
I have several years of experience with .NET and C#, but the other alternatives are appealing too.
In terms of philosophy, all three are open-source, and ASP MVC works in Mono.
What are your opinion?
UPDATE 1: By your opinion, I mean share your experiences(good and bad), advantages, disadvantages with this frameworks.
UPDATE 2: Btw the portal will be used by the patients or potential patients...
Thanks
IMO the only reason to consider .net is if the hospital deploys on windows. Deploying anything else on windows is a pain, and deploying .net on any other platform is a pain. (IMO)
Beyond that, I think the best thing to do was get a rough idea of what you want the portal to do, then look at library support.
After that, its just really what language do you prefer.
UPDATE:
As for my experiences on each: I have 4 years of webforms experience, and played around with MVC. Pluses are that it is mind rendingly fast, and the deploy experience is pretty damn simple. Tooling is decent too, especially the SQL Server frontend, never seen another db tool as good. Down side is that it just doesn't do as much for you as django or rails, in fact, it doesn't really come close. Also, you are going to have to type 3-4x as much due to the language, although some people think the tools make up for the verbosity.
For rails, I have about 8 months professional experience with it. Plus side is there is a plugin for almost everything, and the framework is pretty packed with things that make your life easier. Personally, ruby is also my favorite imperative language, its the kind of thing where you achieve multiple levels of enlightenment as your knowledge of the platform deepens. Down side is that we are in the middle of a transitional period right now in both rails and ruby, so documentation, recommendations, and library support is probably going to be up in the air for the next 8 months or so.
Finally, I am really not an expert on python or django, but I have played around with both. The language is very similar to ruby (meant for productivity over perf, dynamic, very elegant design), but differs quite strongly in philosophy. Pythonistas believe there should be one (and only one) clear and concise way to do things. Rubyists (like perl monks) believe that there should be many nuanced ways of doing something, and that elegant code is like elegant language; expressiveness is paramount.
I would say rails has an edge over django at the moment, due to more eyeballs over a greater period of time. That wont last forever though, django is wildly popular and in a few years I am sure support for both frameworks will be roughly equal. It really comes down to a philosophy thing with these two platforms. If you look at a library that pushes the language in some strange directions that take awhile to grok, but once you do you realize is quite an elegant way to do things, chances are you are a ruby guy. If you look at something like that and say "Ok, so thats clever, but they really should have done it the way that everyone else does it, cause non standard use of syntax really sticks in my craw", chances are you are a python guy.
I think that is totally up to you. In this case, everyone else opinion seems useless.
According what you say, there is no technology limitation and you are totally free to chose anything you want. It's impossible to find an objective criteria.
It would depend if you're more interested on improving your ASP NET / C# skills and giving MVC a try or if you want to learn something totally new.
Any of those options is correct, it depends on your taste which one to pick.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been using Grails for the past few months and I really like it, specially GORM. However, I am getting interested into Scala's Lift. Therefore, I would like to know your opinion about which kind of web apps are better suited for which of those two frameworks or it is just a matter of taste, which framework to use?
Finally, which of those frameworks do you think will be more used in the future?
I have the feeling that Grails is far from reaching a critical mass and it still remains very obscure (in the past few months I had the opportunity to work with middle size companies and IT startups working mostly with the JVM stack and only one person knew and used Grails) and I am not even sure if it can become the "RoR" of the Java world (Indeed reports a drop of growth in the last few months even if other frameworks have a positive growing rate). And I love Groovy, it is really easy to learn but I have noticed how slow it can be for some tasks.
On the other hand, Scala seems to be more popular (Tiobe Index) and the fact that Twitter is using it now gave it even more presence in the blogosphere with lots of lovers and haters making buzz. It is famous for being fast and scalable. However, the language seems somewhat hard to understand and learn for lots of developers (so maybe it will never gain mainstream status). Lift is little known and I have read some reports that it is better suited for small apps (less than 20 domain classes).
By seeing the number of books published Groovy-Grails dominate right now, but many publishers have Scala books on the works, so I think this advantage will not last long.
Finally, we have the problem that both languages and frameworks still have poor IDE support (it is getting better by the day but far away from what Java shops expect to be productive).
I do not want to start a flame wars, but I would be very interested to hear other users' opinions.
The accepted answer here takes a really ignorant view on Groovy - it is a modern, dynamic language (dynamic vs. static is a huge debate in and of itself, and not particularly relevant here). This is by design, and therefore not a disadvantage, just a difference. It has a lot of modern language features that Java does not have such as closures, native regexp, polymorphic iteration, some optional static typing (matter of debate, but also look at groovy++), native syntax for lists and maps, etc.- you can see a comparison here http://groovy.codehaus.org/Differences+from+Java
To address the actual question of Grails vs. Lift, I'd say Grails hands-down. It has the SpringSource behind it, and just look at the plugins page http://www.grails.org/plugin/category/all - I can't even find what plugins or equivalent are available for Lift. Grails is also on top of the latest cloud-friendly technologies, with features like native RabbitMQ messaging support, and turnkey GORM support for MongoDB and Redis.
Grails is a nice idea(but only "stolen" from rails) but the fact that the groovy guys are not interested in getting proper Eclipse support is hindering it's success a lot. I've even seen Eclipse questions not being answered at all on the grails lists.
I agree with Tim that Netbeans 6.7 finally delivers the first half way usable Open Source IDE support for groovy/grails - and eventually, SpringIDE will also feature better groovy/grails support.
The reason many Java folks love Java is the static typing, which enables tools to help you a lot with many things. This is lost with a language as groovy.
Yes, I could write every really important piece of Code in Java and still use Grails - but then, why should I, just to save a bunch of lines of glue code, do that instead of learning to use a Java framework highly effectively?
To come to an end: I did not yet look at scala, but built some simple apps with grails - and I tend to go back to java, even reimplementing every app that needs further development in a plain Java framework - I think wicket and Seam.
I'll also look at Scala/Lift, I heard many good things about it!
BTW: I'd compare communities and look at mailing lists - how many peope are there, do they get good answers on their important questions?
Grails seems to have a non-answered rate from nearly 50%, which I feel is bad.
Grails support in netbeans 6.7 is really good, as well as the idea intellij support in Maia.
Eclipse is still pretty sucky.
I looked at lift, but was concerned about the resources available now; this will change in the future, but my projects can't wait.
I would like to specifically answer the question "for which kind of applications". The main difference between the philosophies of Grails and Lift seems to be that Grails enforces MVC whereas Lift seems to be more liberal i.e. it doesn't enforce MVC but provides enough avenues to use MVC if you want to.
Also Lift seems to be excellent for 'Single-Page Applications', especially if you need to implement a server-push functionality using technology like Comet (which obviously doesn't imply it's not good for other types of applications). On the other hand, Grails seems to be better for the 'Enterprisy' applications, especially if you are already familiar with Spring and Hibernate but want your app to be much more concise (using Convention over Configuration) than what a non-Grails app would be using these technologies.
References:
Simply Lift, chapter 13
Single-Page Application
Disclaimer:
I have just started exploring Lift and built some simple apps using Grails.
With all the performance improvements and advancements of Grails2.0, with great support provided by IntelliJ 11 for the framework, an ability to plugin pretty much any advanced web technology into your grails app., and yes - VMware weight behind it - I really don't see how Lift could be an advantage or a good choice. Just think of using two different languages in the same application, need for double expertise in the team, etc.
The original question has been posted like 2+ years ago and I think time showed on which side is the choice of the dev community ;)