dtekcth / dfotose

DFotos hemsida
BSD 3-Clause "New" or "Revised" License
0 stars 3 forks source link

HTML instead of JS #18

Closed SimonAlling closed 6 years ago

SimonAlling commented 6 years ago

JS may of course be used for augmenting the site with dynamic features, but it should not be necessary like today. It is preferable, for several reasons, if as much as possible is pure HTML and CSS.

cpluss commented 6 years ago

I've been giving this some thoughts the last weeks. I deemed it more productive to just go with what I know from the beginning in order to create nice MVP and then rewrite parts of it later into something more sustainable over several years (this being one of them).

Two viable options are:

It's probably a good idea to start with seperate the backend and the frontend into two different entities, and then work on them individual entities.

SimonAlling commented 6 years ago

We should aim for the basic web design principle of separating content, layout and functionality. As a user, when I visit the site, I expect an HTML document filled with content, be it galleries, images or a single image; a document which does not rely on anything more complex than HTML and CSS.

This is probably most easily obtained if the front-end is redesigned without any JS whatsoever. (It would probably be even better to start with building the markup even without CSS in mind.) Then we can add some extra goodies such as lazy-loading with JS, of course.

cpluss commented 6 years ago

Basic web design was a viable development method years ago, and the web has evolved since then. If you'd like to get rid of Javascript frontend I suggest you create a branch and begin to work :) However, the current trend in web development - and has been for several years now - is to use javascript to render the frontend in a more efficient way than to use hand-crafted html & css, especially when manipulating the DOM.

Redesigning the frontend without javascript is not currently possible, as we need to lazy-load images of big galleries - otherwise we'll simultaneously ask the clients browser to load several hundred images, and most likely crash the browser application.

The site is currently written in javascript (react more like) in order to serve a frontend. I would not regard the initial design choice as an issue, but it adds some limitations such as a need for javascript support (which drops support for old browsers that need polyfills). Any modern browser (except maybe IE/edge) have full support for rendering using javascript.

The reason I initially picked React was that it was something I was familiar with, as well as that it is easy to learn and wrap your head around - maintaining it is not hard. Same goes for picking NodeJS for the backend.

Why do you think we should aim for ''basic web design'' when todays technologies offer a much better and scalable alternative?

SimonAlling commented 6 years ago

I absolutely understand where you're coming from. However, I don't agree on the impossibility of a frontend without JS; server-side pagination (is that the correct term?) has existed for many years, so lazy-loading should by no means be a requirement. (Take a look at SweClockers.com for an example of a site which works very well without JS.)

I also don't agree that "today's technologies" (i.e. a JS frontend, if I'm following you here) are strictly better than "basic web design" in every case. For sites which are not real-time interactive web apps, such as DFoto, I think one should always try to stick to static, semantic HTML as far as possible, and then use JS to augment the site, while keeping basic compatibility without JS. In addition to wider compatibility, my experience is that these sites simply work better on a UX level, especially on slower devices and connections. I can't comment on scalability though.

Having said that, I'm still very impressed with the site as it is today, and I'm not by any means trying to depict a rewrite as being easily performed or necessary. I'm just sharing my opinion.

cpluss commented 6 years ago

This is clearly not an issue. Closing.