4 ms·

What do you think HTML is for? If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not

by osdiab 6y ago

What do you think HTML is for? If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React. If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer. Re state, for me the “bad thing” about global state is usually the same “bad thing” about jQuery-based apps - that anything can mess with anything. But all the solutions you mentioned, and especially the Context API, force components to declare their dependencies and update shared state in restricted ways, which makes that “bad thing” much less bad. If you don’t like shared state at all, feel free to not use any of those, and pass around state throughout the app - but don’t complain to me when synchronizing state throughout your web app becomes a problem, or that boilerplate becomes a drag, because those are the problems these solve.

ivan_gammel 6y ago
Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on building semantic web on HTML, while RAD tools should have been standardizing APIs and UIs across platforms on different, probably similarly looking standards (I’d prefer seeing there some DSL with C-like syntax). Unfortunately we have to deal with what we have - jquery, React, Angular etc, the tools that have not invented anything that we haven’t seen yet, but which pretend to be a silver bullet for solving complexity which should not exist in the first place.
- osdiab 6y ago
  On that I agree, I do wish there was a better cross-platform application UI platform. But it doesn’t exist, so as such beggars can’t be choosers.
- baddox 6y ago
  It would be a strange choice to not use the best tool for the job because one of the acronyms that’s related to that tool stands for something that for historical reasons doesn’t precisely describe the job.
  - ivan_gammel 6y ago
    Agree. My point is that it's the best available AND the worst among those which could be standardized.
- villuv 6y ago
  Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 95. What happened, guys?
  - emerongi 6y ago
    Browsers also don't provide the necessary tools to actually build interactive UIs without reaching for external libraries. If you want to allow the user to select date or time in a decent user-friendly way... you just have to pull some JS thing in. Dropdowns/select boxes still only provide the most basic capability; multiselect sucks, need to pull in another JS thing. The list can go on. Even if your application is 90% non-interactive, the remaining 10% could end up introducing a lot of complexity only because browsers haven't advanced on that front at all in the past decade. And that 10% could easily outweigh the 90% when it comes to the architecture of your application - you get frustrated with the jumblefuck of JS littered randomly around to support X feature on Y page and so you just grab React and build a more manageable thing with it. The standards committees for the Web have seriously dropped the ball.
tannhaeuser 6y ago
> using the web as an application delivery platform that works cross platform Therein lies the problem, understandable as it is. If you're using React (or any other modern UI/MVw/whatever for that matter), you're still describing your app as mutating a grossly inappropriate scene graph of divs and spans held together with CSS tricks when your conceptual model is probably more adequately represented in terms of panels, fields, and canvases. On top of that, you pick about the weakest language out there, and over the course of decades, morph it into becoming more like a real programming language with runtime type info, accidental async patterns, decorators, compilation pipelines and whatnot, giving up the two benefits that JavaScript has, namely ubiquity and running OOTB on browsers by simple page reloading.

by osdiab 6y ago

ivan_gammel 6y ago

Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on building semantic web on HTML, while RAD tools should have been standardizing APIs and UIs across platforms on different, probably similarly looking standards (I’d prefer seeing there some DSL with C-like syntax). Unfortunately we have to deal with what we have - jquery, React, Angular etc, the tools that have not invented anything that we haven’t seen yet, but which pretend to be a silver bullet for solving complexity which should not exist in the first place.

osdiab 6y ago
On that I agree, I do wish there was a better cross-platform application UI platform. But it doesn’t exist, so as such beggars can’t be choosers.
baddox 6y ago
It would be a strange choice to not use the best tool for the job because one of the acronyms that’s related to that tool stands for something that for historical reasons doesn’t precisely describe the job.
- ivan_gammel 6y ago
  Agree. My point is that it's the best available AND the worst among those which could be standardized.
villuv 6y ago
Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 95. What happened, guys?
- emerongi 6y ago
  Browsers also don't provide the necessary tools to actually build interactive UIs without reaching for external libraries. If you want to allow the user to select date or time in a decent user-friendly way... you just have to pull some JS thing in. Dropdowns/select boxes still only provide the most basic capability; multiselect sucks, need to pull in another JS thing. The list can go on. Even if your application is 90% non-interactive, the remaining 10% could end up introducing a lot of complexity only because browsers haven't advanced on that front at all in the past decade. And that 10% could easily outweigh the 90% when it comes to the architecture of your application - you get frustrated with the jumblefuck of JS littered randomly around to support X feature on Y page and so you just grab React and build a more manageable thing with it. The standards committees for the Web have seriously dropped the ball.

tannhaeuser 6y ago

> using the web as an application delivery platform that works cross platform Therein lies the problem, understandable as it is. If you're using React (or any other modern UI/MVw/whatever for that matter), you're still describing your app as mutating a grossly inappropriate scene graph of divs and spans held together with CSS tricks when your conceptual model is probably more adequately represented in terms of panels, fields, and canvases. On top of that, you pick about the weakest language out there, and over the course of decades, morph it into becoming more like a real programming language with runtime type info, accidental async patterns, decorators, compilation pipelines and whatnot, giving up the two benefits that JavaScript has, namely ubiquity and running OOTB on browsers by simple page reloading.