I have worked on the .NET side of things but I am looking at new open-source based web frameworks for a new project.
I looked at LIFT-web, Play, Ruby on Rails etc. LIFT seems very promising for out of the box security and performance. But it claims to have a new approach "view first" instead of MVC. This sounds very similar to the ASP.net web forms paradigm, which was great for drag and drop development but had challenges in terms of testability and having control on what actually
I am wondering whether testing and having full visibility and control on the runtime behavior of LIFT will be difficult. I will appreciate any feedback from people who have used LIFT, better still if they have used both.
Thanks!
I can see why you think they might be similar, but in practice it's not really the case... not for larger applications anyway. If you're building a trivial application in a similar style to web forms, then you'll see similar issues. Lift snippets are in some respects similar to web forms user controls, but the latter are typically abused with munging all manner or content, request, state and so forth together which can indeed make things difficult to test. It's also possible to do that with Lift, as the framework won't stop you. However, idiomatically I wouldn't do that, as I try to ensure my snippets (user controls if you like) are referentially transparent NodeSeq => NodeSeq (xml to xml) functions. Snippets have an exceedingly close relationship with rendering content, and thats all. In addition, you may be interested to look more closely at the site map feature (many people overlook it), as there are some interesting ways in which that can be employed as a mini-controller w/r/t to the incoming request.
So, to try and qualify somewhat, you could indeed make ugly, untestable code with Lift - many people do - but if you keep your business logic properly separated out from the web tier and employ some developer discipline it's a manageable issue. In the main, the benefits largely outweigh the cons - especially in light of no other Scala web frameworks implementing the kinds of security or comet features Lift has.
The bottom line is that if you're building a CRUD application, then its highly likely Lift isn't for you. However, if you're building a rich, ajax or comet app, then its certainly going to be worth a look.
Hope that helps.
PS: You might be interested in checking out "Lift in Action"; it covers some of these topics - http://www.manning.com/perrett/
Related
After speaking with developers, I have questions, "What framework do you use with your app?" and "What web technologies are you using on the front end?".
Therefore, in order to answer the exact question they are asking, what is the difference between "frameworks" and "technologies" in this context? How would I answer these two questions differently or do they both have the same answer?
For example, I thought that in a MEAN stack application, the "technologies" I am using are mongoDB, expressJS, angularJS, and nodeJS. What would be the "framework".
Frameworks are a subset of technologies. All computer languages are technologies. All frameworks are written in computer languages to solve specific problems. The MEAN stack consists of many technologies. NodeJS is a web application framework, that allows JavaScript to run on the server. Express is used to create APIs. Angular is typically used on the client side to provide the front end experience. MongoDB is a technology but not a framework, its a piece of software that allows an application to persist data.
Using your example of the MEAN stack, one could argue that a framework such as AngularJS is a subset of a given technology stack. I often think of a framework as a set of tools for ...... you know what, I think an analogy might better express my thoughts on this.
an analogy
construction = development?
Think of a general contractor (you know, the person(s) you call to come fix things around your house/work). So development is a lot like handy-man/construction work. They fix things, we fix things. They make you a new house or kitchen counter, we make applications... yada yada yada
components
Now think about the separate components in making a house:
plumbing
electric
framing
dry wall
roofing
finish work
I'd equate those to the separate things we use in development to serve our end goal:
database
services
client UI
the tools
Just like a plumber has special tools for his job, I view a framework like AngularJS as just another tool to serve the specialty of Client-side UI work. Bootstrap is a styling framework/tool just like a paint-roller is to finish work. The CSS or the Javascript are the nails and screws, but you can't build just a house with nails and screws, you need tools and methodologies to assemble your parts.
I dunno if that is the best analogy, but it's the one I've used for ages in explaining to laypersons what it is I do for my work and it seems to convey the point fairly well.
in closing...
... I think you can get away with the line of thinking that technology encompasses any frameworks you use. And by mentioning a framework (that they are familiar with) you are implying the technology.
I am choosing a Scala web framework. Among frameworks I am considering are Play, Scalatra and Lift. In the project I am preparing for, security is important. However, web security is a blurry subject for me, and I would like my framework to handle it to a reasonable extent. I seem to be drawn to Play.
I am not asking what is the most secure framework (according to ads – Lift), but, rather, do Scala frameworks handle security for me, and how do they compare in that respect? I don't want to solely rely on my knowledge to make the web-app secure.
I'd vote for Liftweb http://seventhings.liftweb.net/security
The major difference to other frameworks (and especially to java's, like Spring) is what one may call "default behavior". For example, while coding, you can forget to "escape", some html attribute. In a bad framework you'll get errors with corrupt html and security holes. In a good framework you'll have double-escape or an error.
A full list of examples can actually be read in link. What personally I love Lift for is it's statefulness, Scala bindings to HTML like
"#myHtmlNode li div [onclick]" #> ajaxInvoke(...scala code here...)
In the code above, you'll be 100% sure that no one will have access to the contents of ajaxInvoke except for those users you sent the page yourself. And separation of the logic and the view is a relief, of course.
To answer my own question, I have to learn this stuff, no one is going to do it for me. There's OWASP cheatsheets; and also OWASP Enterprise Security API or ESAPI. ESAPI looks promising, though I haven't used it yet.
What kind of applications are the sweet spot for Scala's lift web framework.
My requirements:
Ease of development and maintainability
Ready for production purposes. i.e. good active online community, regular patches and updates for security and performance fixes etc.
Framework should survive a few years. I don't want to write a app in a framework for which no updates/patches are available after 1 year.
Has good UI templating engines
Interoperation with Java (Scala satisfies this arleady. Just mentioning here for completeness sake)
Good component oriented development.
Time required to develop should be proportion to the complexity of web application.
Should not be totally configuration based. I hate it when code gets automatically generated for me and does all sorts of magic under the hood. That is a debugging nightmare.
Amount of Lift knowledge required to develop a webapp should be proportional to the complexity of the web application. i.e I should't have to spend 10+ hours learning Lift just to develop a simple TODO application. (I have knowledge of Databases, Scala)
Does Lift satisfy these requirements?
Well, you could cruise through the Lift getting started guide in which you build an Ajax To Do app ;-)
Lift has been around for 3 1/2 years. The Google Group has nearly 2,000 people on it. There are 40 committers, of whom, 10+ make commits each month. We close between 40 and 80 tickets per month, do monthly milestone releases. Companies like FourSquare, Xerox, and Novell have hardcore apps built on Lift.
IMHO, Lift meet those requirements. Not so sure about #4, though, on the other hand, it has a good collection of back ends to interact with other services.
I think it mostly hinges on complexity. Lift does things its own way, which you may get easily, or you may not. I'd take a day to write that TODO application -- and be sure to make use of the liftweb group, as there just aren't many Lifters on Stack Overflow -- and see how that goes. I think you'll be able to form an opinion on it -- just a day.
On sweet spots: http://seventhings.liftweb.net/
i think you should post this in the lift mailing list too:
http://groups.google.com/group/liftweb
After reading seventhings.liftweb.net and skimming the first two chapters of Lift in Action, Lift's sweet spot looks to be, complex HTML page-based applications with advanced client-side functionality (like Facebook and Twitter).
Compare to single-page ajax "webapp" applications (like a calendar, or mostly anything built with ExtJS) that provide advanced client-side functionality with pure javascript and ajax middle tier services but the programming model is javascript, html is abstracted away. Compare also to traditional HTML "website" based applications like a wiki or blog -- think twitter bootstrap + jquery -- that don't need advanced client-side functionality.
single-page webapps and page-based websites i think would be made more complex than necessary with Lift unless you had an experienced & disciplined team. This probably correlates with product maturity and team size - facebook and twitter are extremely large applications with hundreds of interacting teams and strong engineering leadership.
a small team of people still exploring and forming opinions on how various apps should be structured is likely, i think, to be mislead by Lift into more complex solutions when perhaps all they needed was straightforward HTML templates and simple ajax endpoints.
I realize that this may be subjective but I truly need an answer to this and I can't seem to find anything close enough to it in the rest of the Forum. I have read some folks say that the framework (any MVC framework) can obscure too many things while others say that it can promote good practices. I realize that frameworks are great for a certain level of programmer but what about individuals starting out? Should one just focus on the language or learn them together?
I think web development is way more than anyone grasps when they first start getting into it! Read this and know that it is all optional...but required to be really good at what you do.
I suggest that you spend time learning your language first. I would suggest learning C# simply because it is vastly more marketable and it is usually directly supported in most of MS products. By learning C# - programming in ASP.NET, console apps, servers, services, desktop apps, etc. will all be within your reach. You can program for most of the MS products as well as on many Linux type platforms.
Once you have this down then you can move to programming for the web as programming for the web has some intricacies that most other environments don't have. Concepts such as sessions, caching, state management, cross site scripting, styling, client side vs server side programming, browser support, how HTTP works, get vs post, how a form works, cookies, etc. are all at the top of the list of things to learn separately not to mention learning the ASP.NET base frameworks and namespaces.
Once you have the programming language down and then the concepts of web programming I suggest that you pause and learn database design. Don't worry about performance just yet...try to first learn good design. Performance will come next. A good start for you is Access (blasphemy I know). It is easy for a beginner to work with. And it translates into a more robust platform such as SQL Server easily. Learn at the very least some SQL...but I suggest that you learn as much as your stomach can handle. I heard someone say that SQL is like the assembly language of the database. The number one thing that slows an application to a halt is piss poor database design and poor queries. Once you have this knowledge - stuff it away in the back of your mind and take a look at a good ORM. NHybernate is probably best at the moment but is more complex that the basic learner needs. For that reason I currently suggest getting LINQ to SQL up and running as it is SUPER EASY to work with. Then look at Entity Framework (although I still think it sucks...and you should wait till EF 2.0...ERRRRR...now 4.0 released with .net 4.0). Then NHybernate.
Now is the time to start to understand the infrastructure that is required by web development. You may bump your head against this as you learn some of the web programming stuff. But you need to understand the basics of DNS, IIS, load balancers, sticky routing, round robin, clustering, fault tolerance, server hardware setup, web farms, cache farms (MemCached Win32, Velocity), SMTP, MSMQ, database mail queuing, etc. Many people may say you don't need this. That there will be some knowledgeable network admin to help you out here. However they generally know things that impact them...not you. The more you know here the more valuable you will be to the company that hires you.
Now you can get into the details of best practices and design patterns. Learn about the basics such as repository pattern, factory pattern, facade pattern, model view presenter pattern, model view controller pattern, observer pattern, and various other things. Follow Martin Fowler and others for suggestions here. Take a look at concepts such as inversion of control, dependency injection, SOLID principle, DRY, FIT, test driven design, and domain driven design, etc. Learn as much as you can here before moving to the next step.
NOW you can think about frameworks! Start by creating a basic application with ASP Classic (comes with IIS for free!). This will give you a flavor of a no frills web development environment. Take a look at ASP.NET web forms (briefly) to see how MS attempted to make things easier by hiding all the complex stuff (which you now know how to manage on your own from your readings of the above materials!!!). Now you no longer need ASP.NET Web Forms. Move immediately to ASP.NET MVC. The MVC framwork gives you all the power you need to create a good easily manageable web application. If you build something really big no framework for pure web development may be able to deal with what you need. However MVC is way more extensible for such UBER custom scenarios.
Now that you have made it through the journey to ASP.NET MVC you can take a look at things such as Microsofts Enterprise Application Blocks (such as they use at MySpace). Take a look at Elmah error logging (a must have). Look at how to build a custom SiteMapProvider for your MVC site. If you need to get into searching stuff understand Lucene.NET.
And if you made it this far...you are ready to figure out the rest on your own as it comes up! Have fun. There is a lot of room in this space for a person with some understanding of all of the above concepts.
You'll be using SOME sort of framework. The question is, what level do you want to learn at?
You'll probably not care to learn about asynchronous I/O and mutlithreaded vs. select/poll styles of web servers.
So then, your language of choice is going to provide a layer atop this, the languages preferred "web interface" API. For Java it's Servlets, the lowest level you'd typically code at for server side web applications.
You should find what this "lower level" layer is in your language and learn the API at least. You should know basic HTTP like status codes, cookies, redirects, POST vs GET, URL encoding, and possibly what some of the more important headers do.
You'll then come to appreciate what these higher level frameworks bring to the table, and be better able to evaluate what is the appropriate level of abstraction for your needs/project.
Web development requires a certain degree of organization, since it relies so much on separation of concerns. The browser, for example, is designed to display data and interact with the user. It is not designed to lookup data from a database, or perform analysis. Consequently, a web development framework can help provide services that are needed to make the browser experience a practical one.
The nice thing about employing a platform is that it will provide core components essential to the making of any web application that you won't (and shouldn't) have to think about, such as user membership, for example. Many of the design decisions and deep thinking about how to implement these services has already been done for you, freeing you to focus on what you actually want you application to do.
Of the available frameworks, I find that frameworks that implement the MVC (model-view-controller) pattern are very practical. They clearly organize different functions of web development, while giving you full control over the markup presented to the browser.
All that said, you will need some fundamental skills to fully realize web development, such as HTML, CSS, and a core programming language for the actual underlying program, whether you use a platform or not.
I don't think I agree with the Andrew. I don't think learning C is a pre requisite for web development. In fact, learning something like Javascript, Action-script or PHP is often easier due in large part to the vast numbers of sites and tutorials available, and are enough to expose you to the fundamentals of pretty much every programing language. Variable, Conditions, Loops and OOP. I just think learning C# introduces a lot of learning that isn't really relevant to web development such as pointers and memory management.
As for wether you should learn a framework first? Definitely not. Never ever. You need to be able to stand on your own two feet first and be comfortable with HTML/CSS, Server Side Scripting (PHP/ASP/Python/Ruby whatever) and love it or loathe it, but you're going to have to have a decent understanding of Flash and Action-script.
The order in which you learn these is entirely up to you. But my learning plan would go like this...
Start with HTML. It takes about half an hour to get the basics (it's made up of tags with attributes, end of lesson 1) and it's good to get it out of the way first.
Then start leaning CSS. You'll get the basics again, very quickly. But CSS is a minefield so expect to spend the rest of your life figuring it out.
Next up Action-script. Most people wouldn't agree with me, but bear with me. HTML and CSS aren't programming languages. Action-script is. And learning a programing language for the first time is difficult and tedious. The advantage Action-script has over most other languages is that the results are very visual. It's enjoyable to work with and you can sit back and take pride in your accomplishments at regular intervals. This isn't possible with server-side scripting languages or Javascript and there's a whole host of stuff you need to learn to get server side scripting up and running. You can't build space invaders in with PHP for example.
I've changed my thinking here. I would encourage beginners to ignore ActionScript and focus on Javascript. I still believe that being able to see stuff on screen quickly is a good motivator, but I would encourage people to look at canvas tag tutorials and frameworks. Javascript has come a long way since 2009, and is now the lingua franca of programming, so it's incredibly useful. My initial point about HTML and CSS not being programming languages still stands.
Then, you can start with your server side language. At the same time, you're going to have to figure out the database stuff. I recommend PHP and MySQL because it's free.
Again, I've changed my thinking here. I would encourage beginners to use Javascript on the backend (Node.js), and split their database learning between relational databases and noSql solutions such as Mongo.
Then.... learn your framework. Or better yet, roll your own. That's what I've been doing and it's supercharged my learning.
If you're getting into web development, You HAVE to know how those building blocks work. You don't have to be an expert in all the areas, but you should try to become an expert in at least one of them. If you start learning a framework before you get the fundamentals you'll be in a sticky middle ground where you don't understand why things don't work which will infuriate you, and anyone who has to work with you.
you should learn how to use framework because it would be helpfull for u in the future also it is easier to learn.
MVC will help you a lot .. trust me ... i was developing web project not using mvc and it is like mess ... (in the past there are no well know mvc and i never heard about it)
Short version: yes, and then some.
FWIW : This more generic answer may be of use to someone out there.
What: Frameworks take out tedium of using boiler-plate code again and again. They hide complexity and design issues under wizards and conventions. They also use special libraries, design patterns etc. in ways that are far from obvious to a beginner.
So using a framework is good for getting things done without knowing exactly how - like using an ATM without knowing the internals. You just add your code bits in certain places and things 'just work'.
HTML > CSS > Ruby > SQL > Rails/Javascript framework > Libraries would make for a good learning track. Rest you learn as you go along by being curious, hanging out on forums or as extended learning as need arises.
HOW: The problem starts the minute you step outside simple text-book examples (i.e. when you try to get it to do something even a bit different).
Decoding cryptic error messages when it seems like you've done everything right but things still don't work. Searching on error strings in forums may help out. Or just re-starting from scratch.
Reading up articles and books, videos, trial-and-error, hard-work, search-engines, stackoverflow/forums, local gurus, design articles, using libraries, source-code browsing are a good way to climb the learning curve gently and on a requirement basis.
Working-against-the-framework is the number one problem for beginners. Understanding what the framework expects is key to avoiding white-hair in this phase. Having enough insight to manually do what the framework automates may help reduce this second-guessing effort.
WHY: For more advanced debugging/design, it's good to know what the framework is doing under the hood esp. when things don't work as you planned. Initially you can take the help of local-gurus or forum gurus who've already done the hard work. Later as you go deeper you can take on more of that role. For example there's a "rebuilding rails" book which looks under the hood of Ruby on Rails.
Note: Some of the tips are oriented towards Ruby/Rails but you can easily substitute your favourite language/framework instead.
By day, I am a front-end web developer but in my off time I dabble with other languages such as C, Objective-C, Python, etc. When I first got into web development the idea of web applications was just getting started.
Since then two amazing frameworks have appeared, SproutIt's SproutCore and 280 North's Cappuccino (+Objective-J). SproutCore is being used by Apple for it's MobileMe application and 280 North released 280 Slides. Both of these applications are amazing and they are a testament to what is possible on the web. So the momentum is shifting. Web applications starting to look and act like desktop applications.
So my question is this: should web based applications follow web standards, separation of markup (content), presentation (design), and behavior (functionality) or no?
I am not sure about SproutCore since I have not look at the source code, but I know that if you go to 280slides.com and turn off the JavaScript everything basically disappears. You are left with some meaningless words.
Let me clarify, I understand that web based applications such as 280 Slides is meant to have JavaScript on and not meant to be functional without it but in my day job my main focus is writing clean markup, separating content, presentation, and behavior so that our site and applications can be used by as many people as possible.
It seems like the other people who have answered so far have no idea what you're talking about.
Like me, you've had it pounded into your head to make your web applications as accessible as possible. That is, they should work without scripting and without stylesheets. JavaScript and CSS should only be used to enhance the experience. They should not be required.
SproutCore and Cappuccino are frameworks for front-end development that require the user to have both JavaScript and CSS enabled. Your question is around how we reconcile this with the dogma of the day.
Unfortunately, I don't have a clear-cut answer. I like the fact that SproutCore and Cappuccino (and probably others) are testing the limits of what's possible within a web browser. I also believe firmly that information and services provided on the web should be available to as many people as possible, given the limitations of the technology.
How you approach your solutions needs to be based on a deep knowledge of your user-base. If you're working on an iPhone app, you don't need to worry about traditional web accessibility because the experience is intensely visual. If you're building a web application for a general audience, these new frameworks are probably a poor choice (if you value the widest possible access to your information and services).
Over time, screen reader software is likely to get better at interpreting JavaScript-heavy interfaces, so perhaps this issue will fade. Thing is, something else is likely to "sprout" up in its place.
Javascript is a Web standard — certainly more so than, say, Flash, which was previously (and still often is) used for rich Web applications. In this regard, SproutCore and Cappuccino are giant improvements in my book.
The question here really seems to be how important accessibility is. And that is largely a personal decision based, as Andrew said, on knowing your users. For some apps, accessibility really doesn't make that much sense — 280 Slides is a good example of this. It's a graphic design app that's largely about visual behaviors. It doesn't make very much sense for it to degrade to plaintext. (At least, a text-based app meant to accomplish what 280 Slides does would be really be a completely different thing.)
Yes. It will be difficult at first, but once the codebase matures you will be thankful you followed those rigorous standards.
Edit: An added benefit will be portability to many web-based platform via CSS profiles and whatnot.
The MVC model can be applied just as easily to desktop applications as it can to web based applications. I don't see much reason to distinguish between the two, especially since the line is more blurred in the case of web applications.
I don't know about these particular frameworks, but a lot of web frameworks these days are structured around the MVC model, such as ASP MVC, CakePHP, Ruby on Rails, etc.
Separate as much as you can and it will pay out in the end. When things get complicated and hairy :)
I think they should. Following that type of MVC design allows for changes to be more easily implemented, provides good separation of concern, and is generally easier to understand for newcomers to a project.