IMHO: Websites that don't have "realtime" content should always stick with traditional HTML. I'm a Webdeveloper myself and i don't like the JavaScript Frontend trend.
Many Devs use Frontend JS in places where it's absolutely not needed. If you're building an App that updates in realtime, shows informations while it's created, i'm fine with Frontend JS, but it's an overkill for most content pages.
Sure, it depends on your implementation details, but as i said, it's just my opinion.
I mostly agree, but at the same time, the rise of native apps has raised the bar of what people expect in terms of UX. Take Hacker News and Reddit, primarily content based sites and a good fit for the classic server rendered HTML approach. Still a lot of people prefer using native apps to access that content. You can only get so far by adding some CSS to make the site responsive, but you won't be anywhere near the UX that native gives you without JS.
If we want the nice UX without relying too heavily on Javascript, there's a lot that has to change on the HTML/CSS side of things. And I don't see that happening at all.
And let's not forget that you a) don't get accessibility for free just by rendering on the server and b) almost all screen readers today support Javascript.
I agree! But you have to make a differnce between "enhancing the UX with JS" and "the whole App is written in JS".
I think it's perfectly fine to enhance stuff with JS, as long as important content is visible without it.
Some people go head over heels the JS route (since this seems the way people do it today) and build things that can be build way cheaper (measured in hours) with traditional HTML. Since the outcome is the same (static content) it's just not necessary.
Note: I'm focusing on static content here. Pages that mainly show text and images (Blogs, Newssites et al). (Web)Apps are another topic that present good reasons to use Frontend JS.
It depends... if your content is mostly static, or mostly dynamic it really depends...
Sometimes doing it all in react/angular is easier than bolting on jquery extension after extension... bloating everything up. Also, if you're using more modern techniques, you're going through a build/minify step anyways which makes it even easier still to be more JS based than static.
But you can still progressively enhance with JS to achieve that nice UI, and often it will be more usable because it's built on a solid RESTful foundation that is close to browser behaviour and therefore user expectation.
My experience with JS only apps is that they're often less usable, more brittle, and often don't work at all in IE
Progressive enhancement work well for simple stuff. Like progressively enhancing a form post, or a "like" button which just sends an Ajax request. But as the complexity grows, progressive enhancement doesn't really scale and you end up with two separate versions of your site/app.
I agree that Javascript only apps are often less usable, because the devs making them aren't testing enough on different browsers and devices. But the trend of the "Javascript only" approach is certainly driven by more than just frontend devs that want to use shiny new things (even if that is a factor as well).
It often is. Most web apps are business applications, doing CRUD - form filling, and if you were around before AJAX, you'll know that we were building these back then just fine. I'm not saying we can't do better now, but that PE will get you to a better experience than graceful degredation.
Sometimes you need additional functionality, maybe a realtime graph of share prices that has to be JS. So progressively enhance just that component, or gracefully degrade if you have to (e.g. put a sign up saying "switch on JS to get this specific functionality") but don't use it as an excuse to turn everyone away. It might be that you will reach people who can live without the stock ticker.
Sometimes you just can't do without JS. I wrote a desktop publishing app on the browser once. Obviously I wrote it in JS - users were forced to use a modern standards compliant browser (this was an internal app) - but if I'm doing an ecommerce site, or really any public site, I'm always challenging the devs who want to "build it in angular" to reconsider that option before ploughing ahead.
Actually it's very well suited to it (well, in theory at least - haven't tried it yet). You can render the same html on the server as on the client, using node.js, so you can build a page on the server and then let the JS enabled client take over after the initial page load, or let the server do the work for the non-JS enabled browser.
That just sounds like a passive-aggressive arbitrary rule change. For about 99% of the world the curability, or not, of the web doesn't matter at all.
We already have a perfectly good web and includes things that are not curable, even if we exclude javascript (trivial example: you can't, meaningfully, curl a live sport event).
What do you mean, can't curl a live sport event? Do you mean you can't save it to disk (PVR), or if it's not audio/video, it's not useful to curl it and parse it for stats? If it is video, and you don't consider curl-as-pvr a valid use-case of curl'ing -- how about presenting the text-overlay as a text/html/rss-feed? Mix it at the client for those that want video, or show it as an RSS stream for text w/images?
Not to mention that when we demand to have a functional js-parser and dom-tree just to get at the content, things like text-to-speech and many other things (including building a search-engine!) becomes much harder. For very little (I'd say no) gain.
Many Devs use Frontend JS in places where it's absolutely not needed. If you're building an App that updates in realtime, shows informations while it's created, i'm fine with Frontend JS, but it's an overkill for most content pages.
Sure, it depends on your implementation details, but as i said, it's just my opinion.