Skip to main content

Your Server-Side Form Library

If it isn't already obvious from my previous posts, I've been spending a lot of time on the client side of things with JavaScript and the Dojo toolkit.
I had a chance last weekend to show off a little bit of Dojo and once I got past the lightweight technique for bootstrapping it from the server, my demonstration suddenly got a lot less glamorous.

I think part of it got lost amidst what resembled gruelling swing form code.  I was lucky in that I already had some completed forms to show off, so it was possible to show the kind of experiences you can deliver when you use a good client-side framework.

There was however a takeaway for me which after a lot of thinking, I think I've managed to figure out...

It's Holding you Back!

Your server side form library is killing your UX, coupling your model to the view and tying down your options client-side.

I've worked with forms in Symfony 1.4 extensively and have become quite adept at bending them to whatever need may arise.  I've played with the form library in Symfony 2.0 and am also familiar with what Rails has to offer.
Anyone who has spent time working with the forms of their server framework has probably puzzled over the best approach to a number of problems.  Each time, spending most of the time making sure that all the gears line up.

Why not take that time and spend it instead on making better forms featuring a superior UX and decoupled, unobtrusive architecture?

It's not all bad

Server side form libraries do offer useful features in the way of data binding and validation.  These are abstractions that I think any framework should focus on perfecting as they help ensure that you're committing good data.
Where things start going wrong is when you become reliant on generating your forms and then depending on progressive enhancement to make it pop.  The issue being that you've lost control of your implementation:
  • Your markup is decided for you unless you pour hours into writing a renderer.
  • The form will likely have to be included as part of a full page render.
  • Your front end is now fully coupled with the server.
Really, at the end of the day, the best job you should want to do server-side is make sure bad data doesn't get in.  So when it comes to designing client-side interactions, why not target the client first and the server second instead of the other way around?

After all, the internet is always getting better - do you really want to have to worry about whether your server framework supports every new technology that comes around?

My Original Problem

People who like using server side form libraries tend to turn their nose up at something like Dojo because it's alluring to be able to write a model and have everything thereafter generated.  The problem however is that this architecture has everything pointing the wrong way.

Generating forms server side can also have implications when it comes time to iterate after getting your first round of client feedback.  How many times have you had a client look at a form and want it to be more?  If you've ever designed a form beyond a simple RFI, you know full well that there is going to be extra work!

Solution

This is an opinion that I've been slowly working my way towards, but I'm more and more convinced that time spent on server side forms can be - for a comparable investment of time - put to better use creating exclusively client side forms with the likes of Dojo, GWT or YUI.

As someone who has spent time mastering Symfony 1.4's forms inside & out, I think it's entirely conceivable that you can get better results doing things this way.  Factor in the time spent wiring together (and troubleshooting/maintaining!) progressive enhancements, and I'm sure you'll at the very least break even.
Labels:

Comments

Post a Comment

Popular posts from this blog

Laravel Project Architecture: The Missing Guide

At my job, we've been doing a lot of learning and development using Taylor Otwell 's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided. If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects. Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary. While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially consider...
5 comments
Read more

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of. Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: Coding Project structure Software architecture Building Delivery Community Licensing After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis .  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget. In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as ...
1 comment
Read more

Laravel is Good, Facades Aren't

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...
1 comment
Read more