Hacker News Reader

Comment by micampe | Hacker News Reader

Not everyone has the resources that Twitter and Facebook have to mantain what essentially are two version of their website.

My position is that if you disable Javascript you get what you get (both you and I will be happy to know that I don't do web development anymore).

View on HN

If you use progressive enhancement, you don't really need two versions. You have the base version, and you layer javascript and css on top of it. Granted, it might be a bit more work than just rushing out a javascript-dependent version, but it's definitely not twice the work. And you then have a much better structured, more solid base to work on - in the long-run, I'd be surprised if it weren't less work to do things the progressive way.

Yes, that's the ideal. Try and do it. Remember to test all the different progressively enhanced paths that only a tiny minority of your users is using.

Do you also take that attitude to your code? I.e. "it's alright, that code path only executes one time out of fifty, doesn't matter that it crashes the program".

That is not what I meant. I meant: “that code path only executes one time out of fifty (thousand), but you have to test it exactly like the core code that runs thousands of times more, so maybe you can drop the feauture since it's used by a handful of users”.

(I have my doubts one in fifty people disable Javascript)

Well now you're talking about an analogy that's 3 orders of magnitude away from what we're actually dealing with, so it doesn't really hold up. BTW, we're not really talking about 'testing' here, either - you don't actually need to test plain HTML beyond the most cursory of glances.

We are talking about people disabling JavaScript in their browser. One in several thousands is still a large over estimation.

[Citation needed]

What a thoughtful and insightful remark. If you don't believe that statement to be in the right ballpark you are out of touch with the world outside HN.

I find that "progressive enhancement", while perhaps a bit more work, results in a more robust and maintainable webapp. The fact that results in pages that work without JS is almost a side-effect and barely needs to be tested.

The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire.

By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page.

There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app.

Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.

You could always just build one version that is capable of rendering either server-side or client-side. React.js and other similar frameworks (that do diff-based updates) work well with this, or at least better than frameworks where the state changes are discretely coded.

The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails

In my experience, when discussing development problems, there are two types of people: those that say “well, you could just […]” and those that tried to do it and learned from experience how many unexpected problems you are going to have, how much work it's going to be, how much more testing you need, etc.

Fair. I haven't tried rendering server-side with React. I'm sure it's as much a maintenance nightmare as much as any major feature.

But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function.

On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality.

So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.

For eight-ish years, 2002-2010, I made websites that worked with or without Javascript, precisely because I didn't want to make two websites. I would have had to, because a lot of blind people used to use readers that didn't always handle Javascript well, and the sites I made were required to be accessible.

Admittedly, they did not look as good as sites do today.

Reply on news.ycombinator.com