[cgiapp] Dancer, URIs, and Web Apps

[Bill Stephenson]

On Mar 5, 2010, at 9:23 PM, Mark Stosberg wrote:
>
> Let's look at one:
>
> /cgi-bin/user.cgi/edit?user_id=23
>
> That URL has a lot of junk in it tht is about implementation details
> that essentially says "blah blah blah" to the user. This clean version
> communicates the essential:
>
> /user/23/edit
>
> Users may not complain because they aren't aware there there's any 
> other
> way to do it. But presented with the old and new side by side, I think
> easy to agree which style is more pleasant to use.
>
> With some support from your framework, clean URIs are easy to create 
> and
> process.


I agree that it is "Prettier", but not that it provides any utility for 
the user at all. Web "Application" users shouldn't have to "Use" URIs. 
They are not presented in desktop apps, and provide no real valuable or 
even useable feedback to the users.

As a programmer, I see little difference in readability in the above 
examples and writing the code to accomodate every view in an app seems 
like putting pinstripes on a hot rod. It's pretty, but serves no real 
purpose and won't make your car go faster.


>
>> If hiding URLs from users is a design goal it also seems like it is
>> easily solved by using AJAX to update content.
>
> With that method you would also have be careful to not break the back
> button, which means making sure the URL gets updated, which is just
> trading one kind of clean URL design for another.

Back buttons are a scourge for web app programmers. If I could easily 
disable it I would, and web apps that take advantage of client side 
features can do that.

>
>> Personally, I think the CGI Application Framework project goals might
>> do well to include how the framework can integrate tighter with the
>> client side features available now and those coming in HTML5. This
>> would obviously require making the inclusion of javascript in output
>> something that is easier to do.
>>
>> HTML::Prototype is a good example of what I mean. Helper tags for
>> JavaScript are needed to really take advantage of all the upcoming
>> potential for web app developers. The client side data storage 
>> features
>> in HTML5 go a long way past cookies. Among other things, this will add
>> some offline feature capabilities to our repertoire.
>
> I think using Perl to generate JavaScript was a bad idea. It creates
> more complexity, but you still need to know and use JavaScript. Perhaps
> if it eliminated the need to worry about JavaScript completely I would
> see it as valuable, but it does not.

With solid JS libraries like Prototype that provide very useful client 
side features it only makes sense to me that working to provide tighter 
integration between them and the server side of web apps is not only 
worthwhile, it's inevitable. Those (developers and frameworks) that 
take advantage of the client side feature set will build better apps, 
those that don't will be left behind. There's no getting around that 
now. This course is set.

In so many ways the Prototype libraries are the mirror image of CGI-App 
on the client side. CGI-App doesn't elimanate the need to worry about 
perl on the server side either, but it goes a long way towards solving 
common needs and problems that web app developers all run into, as does 
Prototype.

>
> It's not clear to me what else a framework like our should be doing to
> integrate with the client side. I see that as primarily being a concern
> for templates.  Someone could perhaps ships some sample templates for
> website developers with a web framework, I suppose.

It's not entirely clear to me either. I think it needs some real 
pondering. From where I stand, it seems that for the most part these 
two lines of development haven't looked too hard at ways to converge, 
but it is the logical next step.

I don't know. It's not clear to me. I do know that eventually I'll have 
to give a lot more thought about implementing these features.

I'd like to see a client side perl engine that we can send perl code 
to, instead of JS. That would make life really easy for me, but 
apparently, just me ;)

>
>> It won't be long before we can't ignore these mobile devices. Google
>> boldly stated this week that "In three years desktops will be
>> irrelevant". That's because everyone will be using web apps. Apple is
>> certainly moving that direction with the MacBook Air, iPhone/iTouch,
>> and now the iPad, and of course there are "Netbooks".
>
> It's not at all clear me that a future of tethered devices like the
> "iDevices" is one we should be looking forward to and enabling:
>
> http://www.slate.com/id/2223214/pagenum/all/

To be fair, all web apps are "Tethered" too. I see the problem, but 
creating web apps is what we do.

Kindest Regards,

--
Bill Stephenson