TL;DR
As a rule of thumb (there are always edge cases and exceptions), user stories should represent a potentially-shippable unit of work related to the Sprint Goal. Unless you can ship the front end and back end capabilities independently, it doesn't make sense to split a story based on who will be doing the work.
Split Tasks on "What," Not "Who"
In Scrum, it doesn't make sense to split anything from a Product or Sprint Backlog based on who will do the work as opposed to what the work is. While there's an arguable point of view that fully-decomposed tasks can be deliberately aligned with individuals or target individual skills, tasks should really still represent increments of work in a user story's development rather than individual assignments, and as such the tasks should belong to the Development Team as a whole. That definitely argues against decomposing user stories into personal tasks, but that is something I'd leave to the Development Team to hash out as the workflow evolves.
Example
As a user,
I want to be able to login
so I can access the web site using my saved preferences.
This story has implicit front end, back end, and persistence requirements. From the user's perspective, delivering sub-components of the feature won't really advance the flag, so splitting this into model, view, and controller stories doesn't really make a lot of sense. Of course, there will be model, view, and controller tasks required to get this story done, but whether or not you really need to split those intertwined tasks down along those lines depends more on how the Development Team works together than anything else.
If the team members are very I-shaped, rather than T-shaped, you could conceivably split the tasks that fine, but then you're faced with an integration problem when everyone brings their tiny piece of work back together to meet the Definition of Done for the story. As an experienced agilist, I'd argue that the better thing to do is to let the Development Team self-organize around the story. Perhaps the Javascript, PostgreSQL, Ruby, and Cucumber developers will all mob program this feature together. Then again, maybe they'll split the work into tasks, parcel them out between themselves, and then come back together to integrate the work. Let the Development Team work it out for themselves, and then evaluate the outcomes of the process during Sprint Retrospectives.
To Decompose or Not
Scrum doesn't take a position on how to divide tasks, or how granular they need to be. It also doesn't really require decomposition of user stories into tasks on the Sprint Backlog, although doing so can be useful as an information radiator for complex or long-running stories.
While Scrum doesn't take a position, the principles behind the Agile Manifesto do. The 10th principle is to maximize work not done. That means formal, upfront decomposition (which is also work!) for its own sake is often an anti-pattern. The Development Team owns the Sprint Backlog, and should therefore decompose user stories just enough to coordinate and communicate within the team.
If decomposition is helpful, then do it; if it creates more overhead than basic face-to-face collaboration without a tangible benefit, then don't do it. It's really that simple!
