[noptic]

This is a discussion about a javascript framework. Meteor relys on javascript on the client and the server so how should it work with noscript?

If you want to use a javascript tool you´ll have to add an exception for this tool.

[bigiain]

(A somewhat late response, since something I saw this morning reminded me of this discussion)

Compare the above screenshots with this one:

https://dl.dropboxusercontent.com/u/7633426/BundleHunt.png

it's "broken" in similar ways, showing markup like ${{product_price}}, but clearly includes enough static-content and context to allow be to choose whether I want to click my "allow scripts" button.

If somebody sent me a link to Shingle Central with no explanation, I'm highly likely to go "whatever" and move on t the next work-distraction-link…

[Grue3]

There's no reason why server-side javascript cannot generate static HTML.

[ryan-allen]

There is when the client doesn't want to pay for the extra work for the 0.1% of tinfoil hat-wearing people who turn off JavaScript.

"You need to spend an extra 30,000 to get this to work for the 3 crypto-anarchist wannabes who live in your state".

I don't think the client is going to want to pay for that kind of interop.

EDIT: I don't mean to be snarky but you absolutely HAVE to make these kinds of trade offs when working for people. And you have to absolutely discuss them with clients.

When a client asks for 'hey I want it fast like facebook and some of those cool animations I see wasitcalled haych-tee-em-ell five or something right? also it has to work on iphones because my wife has one', there is a hell of a lot of discussion there about tradeoffs. If the project you are building for them is speculative then even more so shit ain't gonna work for some people because they just aren't going to want to spend the money.

The last small job I did, I got a late requirement of "this actually has to work in IE7, 8 and 9", and stupid me, not hammering this down contractually the interop from the get go it ended up taking up nearly 20% of the budget in the end to get this working retroactively, and this was a small project.

[marrs]

It shouldn't be extra work. It's actually less work because it encourages you to play to the browser's strengths and to separate your concerns. It keeps rendering speed high, it makes it easy to debug issues because you can switch off JS to see if the problem is with the underlying HTML/CSS. If one JS component fails it doesn't take down the rest of the site, and so on.

Your website should work in IE7. It's a legitimate browser with real users. This doesn't mean it needs to behave exactly the same way as IE10, but a visitor to my site using lynx should get some level of use out of it.

Again, this helps you massively in the long run because the browser scene changes all the time. If you work hard to make your site work across the browsers you know about, it's more likely to work on the browsers you don't know about, or the ones that haven't been invented yet. (It took the iPhone to take Safari from a browser that nobody cared about to the browser everyone cared about pretty much over night.)

[ryan-allen]

This depends entirely on what the customer is asking for, and how they're asking for it to be done, and whether or not they even care about fancy tricks or plain websites/web apps.

Non trivial example: client wants drag and drop uploads. What browsers support this functionality? Oh we can't do that in browser X Y and Z. Is that a problem? Oh, it turns out it is because manager A promised this to the CEO and she runs IE7 due to corporate IT policies. Crap. OK trade-off time, what should we do? Drag and drop for chrome that my boss runs or just stick to old school uploads? Use some plugin from jquery.com? OK let's do that. Now we have apparent 'automatic fallback' via the plugin but... boss wants it to display the image for confirmation in newer browsers, shit... Does the plugin support this? Yes? No? Let's say no now you're looking for another off the shelf or a roll your own.

Now you can say what you want about 'it should just work bler bler it's easy' but if you extract this attitude out to all areas of a software project you end up with the inmates running the asylum pretty much overnight. Like it or not, but the team or individual you are working with all have varied skill sets and you have to make work with what you have. The trick isn't 'just make it work with javascript off', it's 'deliverer something in the timeframe and on budget with the resources available' and those are different every time you embark on something.

[Grue3]

I think you're ripping off your client if such basic functionality as displaying a static page on a website is "extra work" for you.

[ryan-allen]

Basic functionality? You don't have a clue as to what my skill set is and what I offer and you accuse me of ripping off my clients?

Screw you buddy.