5 ms·

Is the distinction between web sites and web apps really valid, though? No matter how dynamic your site is, you still have certain responsibilities to your user

Is the distinction between web sites and web apps really valid, though? No matter how dynamic your site is, you still have certain responsibilities to your users, including giving them the best user experience you can, but also things like accessibility, sane SEO, bookmarkable resources, and, in the long run, maintainability. Is a highly dynamic site really a "get out of jail free card" for best practices?

skrebbel 12y ago
> Is a highly dynamic site really a "get out of jail free card" for best practices? No, of course not. React proposes to replace one "best practice" by a different one. In React, the best practice is to divide your application up in a deep hierarchy of components, each of which adds one single little layer of abstraction over the other. Then, put all the logic and presentation that's relevant for that little piece of abstraction together inside that little component. This way, you have very good separation of concerns - all "Button" stuff is together in the Button component, all AreYouSureDialog stuff is together in the AreYouSureDialog component (which in turn uses Button components), and so on. Because components can only interact with each other via props and refs, you also have very fine-grained control over the interface: it's difficult for the programmer of a parent component to influence the behavior of the child component any further than by the interfaces that the child component explicitly exposes for that (= props, and public methods for use via refs). How is all that a "get out of jail free card"? I've found that this design principle works very well with teams, even with junior team members. I've seen people who had never gotten further than building 10000-line CSS files with all kinds of horrible hacks let loose in a React project. After we explained the component principle and made an example component to easily copy&paste, they independently and without further encouragement started making React components for each little possibly-reusable part of the application. Buttons, frames, dialogs, cards, lists, you name it. React really makes it easy to make well-structured code and difficult to make things a mess. I don't see how and of this impacts any of the responsibilities you mention (good UX, accessibility, etc) so I can't respond to that part of your comment.
- timepiece 12y ago
  it's difficult for the programmer of a parent component to influence the behavior of the child component You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. Yeah sometimes undesired consequences occur on elements but it's easy to remedy the situation if you know what are you doing but by moving all the presentation info to your logic layer in development, and then littering the structure/content layer i.e. HTML via style attribute in run time, this is unacceptables and can't be seen as progress for the industry in any way.
  - rpedela 12y ago
    > You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. This presentation explains what problems React inline CSS solves. https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js EDIT: I gave wrong presentation link initially.
    - timepiece 12y ago
      This presentation explains what problems React inline CSS solves Could you please summarize in a few sentences what are these probs this approach deem to solve? Because I have seen demos and talks from React people and I was appalled at their neglect of best practices and bending the rules just to push their product and technologies on the community
      - woah 12y ago
        I'm curious, which demos and talks are you referring to?
        timepiece 12y ago
dagw 12y ago
Accessibility, SEO and bookmarkable resources aren't always a requirement. The GMail app (as opposed to the login page) for example doesn't need SEO. If you're targeting a known specific audience then you don't necessarily have to focus on accessibility. Bookmarkable resourecs doesn't always make sense either, for example if you're making a web based image editor (although I suppose you could create bookmarks into each images editing history or something if you're doing non-destructive editing) . Maintainability is of course important, but I've yet to see a convincing argument that one approach gives a priori better maintainability.
- bphogan 12y ago
  As a low vision computer user that supports disabled people on the web, and whose father spent 30 years working with disabled people, I can tell you for a fact that for some people, accessibility should be a requirement all the time. Especially as more things go toward the web. The disabled is a club anyone here can join, at any time.
  - bronson 12y ago
    Using the GP's example, it would take a huge amount of effort to make an online image editor accessible to the blind. I'm not sure that would be time well spent. All the GP is saying is that the trade-offs will depend on your audience.
oe 12y ago
Building and application doesn't automatically mean discarding accessibility, SEO or sane URLs. Modern JS-frameworks like React handle them quite easily.
rimantas 12y ago
Yes, it is valid. To quote Tantek: > if it’s not curlable, it’s not on the web. http://tantek.com/2015/069/t1/js-dr-javascript-required-dead http://tantek.com/2015/069/t1/js-dr-javascript-required-dead

skrebbel 12y ago

> Is a highly dynamic site really a "get out of jail free card" for best practices? No, of course not. React proposes to replace one "best practice" by a different one. In React, the best practice is to divide your application up in a deep hierarchy of components, each of which adds one single little layer of abstraction over the other. Then, put all the logic and presentation that's relevant for that little piece of abstraction together inside that little component. This way, you have very good separation of concerns - all "Button" stuff is together in the Button component, all AreYouSureDialog stuff is together in the AreYouSureDialog component (which in turn uses Button components), and so on. Because components can only interact with each other via props and refs, you also have very fine-grained control over the interface: it's difficult for the programmer of a parent component to influence the behavior of the child component any further than by the interfaces that the child component explicitly exposes for that (= props, and public methods for use via refs). How is all that a "get out of jail free card"? I've found that this design principle works very well with teams, even with junior team members. I've seen people who had never gotten further than building 10000-line CSS files with all kinds of horrible hacks let loose in a React project. After we explained the component principle and made an example component to easily copy&paste, they independently and without further encouragement started making React components for each little possibly-reusable part of the application. Buttons, frames, dialogs, cards, lists, you name it. React really makes it easy to make well-structured code and difficult to make things a mess. I don't see how and of this impacts any of the responsibilities you mention (good UX, accessibility, etc) so I can't respond to that part of your comment.

timepiece 12y ago
it's difficult for the programmer of a parent component to influence the behavior of the child component You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. Yeah sometimes undesired consequences occur on elements but it's easy to remedy the situation if you know what are you doing but by moving all the presentation info to your logic layer in development, and then littering the structure/content layer i.e. HTML via style attribute in run time, this is unacceptables and can't be seen as progress for the industry in any way.
- rpedela 12y ago
  > You seem to focus only on the few drawbacks of CSS inheritance and to ignore its biggest advantages like you don't have to write declaration for every and each element on the page and rely instead on inheritance for props to cascade properly. This presentation explains what problems React inline CSS solves. https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js EDIT: I gave wrong presentation link initially.
  - timepiece 12y ago
    This presentation explains what problems React inline CSS solves Could you please summarize in a few sentences what are these probs this approach deem to solve? Because I have seen demos and talks from React people and I was appalled at their neglect of best practices and bending the rules just to push their product and technologies on the community
    - woah 12y ago
      I'm curious, which demos and talks are you referring to?
      - timepiece 12y ago

dagw 12y ago

Accessibility, SEO and bookmarkable resources aren't always a requirement. The GMail app (as opposed to the login page) for example doesn't need SEO. If you're targeting a known specific audience then you don't necessarily have to focus on accessibility. Bookmarkable resourecs doesn't always make sense either, for example if you're making a web based image editor (although I suppose you could create bookmarks into each images editing history or something if you're doing non-destructive editing) . Maintainability is of course important, but I've yet to see a convincing argument that one approach gives a priori better maintainability.

bphogan 12y ago
As a low vision computer user that supports disabled people on the web, and whose father spent 30 years working with disabled people, I can tell you for a fact that for some people, accessibility should be a requirement all the time. Especially as more things go toward the web. The disabled is a club anyone here can join, at any time.
- bronson 12y ago
  Using the GP's example, it would take a huge amount of effort to make an online image editor accessible to the blind. I'm not sure that would be time well spent. All the GP is saying is that the trade-offs will depend on your audience.

oe 12y ago

Building and application doesn't automatically mean discarding accessibility, SEO or sane URLs. Modern JS-frameworks like React handle them quite easily.

rimantas 12y ago

Yes, it is valid. To quote Tantek: > if it’s not curlable, it’s not on the web. http://tantek.com/2015/069/t1/js-dr-javascript-required-dead http://tantek.com/2015/069/t1/js-dr-javascript-required-dead