7 ms·
I agree. This is the progressive enhancement I've talked about earlier. Present a long, full form for JS-less users, and present it all nice-ified for those wi
by chrisdotcode 12y ago
I agree. This is the progressive enhancement I've talked about earlier.
Present a long, full form for JS-less users, and present it all nice-ified for those with, and send it off for server processing when you're done.
- ac2u 12y agoI think you're simplifying too much in order to make a point. And I've no doubt your point is valid in a lot of cases. However, this idea of a template rendered on the server and then the same template on the client is often fraught with difficulties the more interactive your application gets. It gets more complicated when you want to 'componetize' your javascript. A couple of years ago to do that I would have brought in something like backbone. "I know!" I thought, "I'll switch my templating to mustache, which has a parser in both ruby and javascript. Then I'll have ruby render the page with mustache using a ruby hash. Subsquent AJAX updates then pull down JSON in the same shape and I'll have Backbone use that same mustache template to render it! That way I can send the HTML down from the server pre-rendered for speed and SEO and then progressively enhance!" All great in theory, but then I had to build awareness into my components so that they could be instantiated without a pre-existing representation built by the server or attached to a pre-rendered version made in Ruby. (You don't want to only make a component that NEEDs a real DOM to be tested do you?) So while I agree your advice is great for forms, I've found real world cases of highly interactive applications where it reaches its limits. And the proper progressive enhancement we need is only coming now thanks to efforts like this and isomorphic react applications.