251–260 of 263 posts
Earlier quoted context omitted.
Using as a button? Enjoy your form submission when it's inside a form element. HTML is the most frustrating thing in the universe.
does not do anything, even inside a .
Earlier quoted context omitted.
That could work -- if the JSON is intended for public consumption, and if it is documented as so. The problem, I'd argue, with JSON is that it does not intentionally facilitate semantic annotations, unlike HTML(5). I'd argue that a properly marked-up HTML5 representation of a piece of data is more useful than a bespoke JSON structure with crude naming liable to change without notice. The benefit I get with an HTML re…
You are building up a strawman against JSON without acknowledging that every problem you outline applies just as much, if not more, to HTML. Is the HTML of any popular website publicly documented? Is there any guarantee that an XPath to a particular value won't change? Is there any guarantee the data I need is marked up with semantically accurate class names? No. HTML is intended for public consumption—by a human, at…
That's an interesting definition of "public JSON API" you are using.
* Where is the public documentation for this endpoint?
* Given an ember app, how do you arrive at that URL? (Previously you mentioned watching network requests from a browser to discover the URL endpoint, I think that's particularly unsuitable way of discovering a public JSON API)
* Where's the schema definition of that JSON blob?
That's as much a public JSON API as "curl http://en.wikipedia.org/wiki/Louis_Boullogne" is a public HTML API. And at least with the wikipedia one, there is some defined structure and implied meaning to the data coming back (i.e. standardised HTML elements).
"A versioned JSON API that is guaranteed not to change."
How is that guarantee enforced? What prevents a developer from changing the nature or structure of the response at that URL?
Earlier quoted context omitted.
Idn, I'm not impressed with the initial load time. If that site was served as a static page that was recompiled when a new article was added, it would be significantly faster. But at the same time, subsequent loads would probably be a little slower. Which one is more worth it?
You can do both! Prerender the front page server side, then switch to super-fast PJAX once the JavaScript is loaded. This nifty technique is called... wait for it... "progressive enhancement". Airbnb's recently released Rendr library ( https://github.com/airbnb/rendr ) is a great attempt to make this easy for complex web apps to do.
Oh, and I get to test two code paths, and all of the wonderful ways they might interact!
Earlier quoted context omitted.
Search-engine optimization is a large part. The fact that the JS frequently results in lower usability is biggest on my list. I've encountered Blogger themes which are so fucking piss-poor I literally cannot read them, even with JS enabled. If the primary goal of your site is content, stick with vanilla HTML. You're vastly better off for it.
> Search-engine optimization is a large part. It doesn't look like it is too difficult to add search indexing support. http://eviltrout.com/2013/06/19/adding-support-for-search-en...
Earlier quoted context omitted.
And who cares about people using NoScript, no one should. They are in the vast minority, not worth the trouble accommodating for them.
And they know they're using NoScript. If the website doesn't work, they can decide if they want to enable or not. It's their burden, not mine. Unless, of course, my client wants a 100% working no-script webapp/site. Then I'll happily charge for the extra time building it.
What annoys me is the tendency of Javascript guys to rebuild every damn application there is as a webapp, and rave about it like it's the best thing ever. Javascript has become their hammer, and the whole world looks like it needs a good pounding.
Just because you can doesn't mean you should.
Earlier quoted context omitted.
You can do both! Prerender the front page server side, then switch to super-fast PJAX once the JavaScript is loaded. This nifty technique is called... wait for it... "progressive enhancement". Airbnb's recently released Rendr library ( https://github.com/airbnb/rendr ) is a great attempt to make this easy for complex web apps to do.
Oh wow! I get to write two code paths! I'm so excited to do double the work for a small subset of users! Oh, and I get to test two code paths, and all of the wonderful ways they might interact!
Earlier quoted context omitted.
And they know they're using NoScript. If the website doesn't work, they can decide if they want to enable or not. It's their burden, not mine. Unless, of course, my client wants a 100% working no-script webapp/site. Then I'll happily charge for the extra time building it.
You may want to use a pseudonym for work where you cut corners and failed to do work you're actually prepared to do properly. I browse without javascript enabled to judge the quality of the tools I'm considering; I wouldn't hire anyone with a portfolio full of broken non-semantic documents.
If it takes more time, the final product costs more. The client should be aware of that and make the decision. Why should he/she always pay for something that will only be useful for a very small % of his/hers clients?
Earlier quoted context omitted.
> It is doing the baseline correct thing. You don't get to define what the baseline correct thing is for a business, profit does that. Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.
>You don't get to define what the baseline correct thing is for a business, profit does that That's what I am using. >Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact. I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.
I simply don't believe you. It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone. There is no arguing this, it's more work to support 2 modes of interaction than it is to support only 1. You may find it a comfortable workflow for you, to start with vanilla HTML and then progressively enhance it, but regardless of how much you like the style, it is more effort and does have more long term maintenance costs to forever support 2 modes of interaction. No one who isn't completely full of shit would argue that progressive enhancement is less work.
Earlier quoted context omitted.
>You don't get to define what the baseline correct thing is for a business, profit does that That's what I am using. >Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact. I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.
> I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain. I simply don't believe you. It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone. There is no arguing this, it's more work to support 2 modes of interaction than it is to sup…