JS-less user interface


(heinrich5991) #1

Has it been considered to show a more user-friendly UX to people without JS?
I’m mainly talking about the most basic features of a forum, such as registering, logging in and posting, all of which seem to be impossible as of now.


(Erick Guan) #2

All is possible, but we have to spend a lot of time to maintain this. Mentioned time, I mean maintainer.

Now we can enjoy the lightning speed of client side application. It would advance from time to time! I think in the near future, we would enjoy more animation, and which can result in more native and smooth look.


(Theron Boerner) #3

Uh… why can’t you use JS? This is 2014, the language has existed for 19 years, if you’re using a plugin like script safe to disable it then I think too bad, if you want a good experience nowadays you need JavaScript.

DOM Core <= Support isn’t a big problem.


(Robin Ward) #4

No, there’s no plans to make Discourse work without JS except in the most basic read only way that it does now.


(heinrich5991) #5

Would a pull request be accepted that adds the most basic write feature to the JS-less version?

In particular I’m thinking about

  • Registering
  • Logging in
  • Creating a topic
  • Replying to a topic

This interests me because in the past I had to resort to text-mode browser (there are such situations – e.g. when having a problem setting up a graphical user interface) and I was glad that the relevant forum was accessible for browsers without JS.

Another thing is that JS presents the biggest attack surface to modern browsers, so in certain contexts one wouldn’t want to enable JS in the browser for security, think e.g. whistleblowers (or I think the Tor user guide suggested against enabling JS).


(Robin Ward) #6

I have megadoubts about a PR to do that. It is outside of our current mission.

I’d suggest building it as a plugin instead.


(Michael Brown) #7

Or: rather than modifying Discourse, create another client. The Javascript client consumes the API - write a command-line client that can also consume the API and login/make posts/etc.

Bonus: this could potentially be incorporated into the launcher.


(heinrich5991) #8

The problem of a plugin is that one can’t access the forum if the admin doesn’t install that plugin.

The problem of creating another client is that one would have to reinvent all the platform-independence of the web again – I dare to say that the web almost universally accessible.


(Robin Ward) #9

Maybe Discourse isn’t the ideal forum software for you then. I’m not interested in putting a bunch of extra code into our software to support the infinitesimal amount of people who disable JS.


(Sam Saffron) #10

I am not following the problem here at all, you choose which plugins you want when you initially bootstrap your container.

A static site support thing should definitely be done as a plugin, no question about it. If we accept it into core we are going to be stuck supporting a reasonably large amount of extra code. That has a significant cost to the team.


(c-i-p-h-e-r-1) #11

Why not just write an HTML5 interface? That way, you could probably scrap all of the JS without needing to maintain two separate interfaces. And, as a bonus, the “infinitesimal” number of people who disable JS will still be happy.


(Theron Boerner) #12

There’s a good reason it’s using JS. HTML5 will be a terrible interface compared to this.


(Robin Ward) #13

Because we like Javascript, and like to do things in our interface that are impossible without JS.

If you want to make a HTML5 interface that’s better than our JS one, feel free to build it on top of our API and show us how it’s done!


(c-i-p-h-e-r-1) #14

Just because you like one technology doesn’t mean that other technologies don’t have advantages. Take the way that the Discourse UI is updated. From the responsiveness and sniffing the packets, it’s apparent that Discourse uses either an AJAXy or long-polling method to get updates for the UI. Why doesn’t Discourse use websockets? Almost all of your officially supported browsers support websockets. And there are examples out there of systems that prefer websockets, but fall back to another solution when the client can’t use websockets.

My point is, you may be getting certain advantages from using JS, but there are all sorts of limitations you are giving yourself by keeping such a narrow technological focus solely because you “like javascript”.

As for building a better UI for you in HTML5, maybe I could. I’m unsure. But I just don’t have the time between my job and my family.

Edit: And if you’re trying to figure out how this relates to the original topic, I bet that switching to websockets would reduce the amount of JS running client side.


(Jens Maier) #15

Would you care to elaborate?

In my book, websockets is a hack to tunnel a stream protocol through HTTP with a few extra bits to make it safe to expose it to potentially untrustworthy code. You still need to come up with a message format, protocol and object marshalling. The only client-side JS code this saves is the timer and bits and bobs that drive AJAX, but that stuff is encapsulated inside Ember anyways.

And anyways, in which way is this JS-less? Discourse’s entire presentation layer is assembled client-side, you either have to move all of that to the server or run some code in the user agent. And last I checked, HTML5 was still static markup, not a programming language.


(Sam Saffron) #16

and

Yes, every system you build has constraints, advantages and disadvantages. We are 100% fine for people to build a JS-less interface in a plugin, its just that lugging a big chunk of extra code in core has significant cost and is not something we can afford.

Because that is a different beast to what we have built, a very different beast. It would cost time, money, have an upkeep cost etc.


(Robin Ward) #17

I’m closing this topic now. If people want a JS-less Discourse they’re free to build it, but we certainly aren’t going to do it.