5 ms·

There;s some deep truth here, and I suspect it's about a fundamental difference between "writing a plain vanilla JavaScript application" and "I wanted to use th

There;s some deep truth here, and I suspect it's about a fundamental difference between "writing a plain vanilla JavaScript application" and "I wanted to use the same HTML to generate both a PDF (with Prince) and to make an interactive version of the questions." Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. At the same time, reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. (I can totally see why the framework-de-jour option gets chosen so often though - because no matter how written-in-stone the original specs saying "There wil be no functinality required beyond showing/hiding divs and css animations between them" are, we've all seen projects where a last minute critical/showstopper requirement for the web page to include something insane like a fully functional email client gets dropped in the FE dev's lap the Friday afternoon before launch Monday. Sure, the FE dev made the choice to use React, and while some (perhaps a lot?) of that is "resume driven development", at least some of the blame is on bad sales people and project managers as well...)

deleted 6y ago
[deleted]
triceratops 6y ago
> reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. Do people really do that? To me, that reflects bad frontend engineering practice. Even so for something like that, I'd use jQuery or something similar, because it's a much nicer API than the DOM.
- dgb23 6y ago
  How do you generate html in the first place? With React you have the same UI logic in one uniform framework. Whether you render statically, on request or in the client doesn’t split up your code. Everything plays together nicely. You get sensible editor support with linting and static analysis and more comprehensive error messages.
- adrianhel 6y ago
  Why bother with jQuery? I don't see the value add anymore.
  - tambourine_man 6y ago
    Read this whole thread. People are rewriting it over and over again because it’s out of fashion.
tonyedgecombe 6y ago
>Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. I'm pretty sure gmail started out without a framework.
- bigiain 6y ago
  > I'm pretty sure gmail started out without a framework. I'm pretty sure you're right. I'm also pretty sure it's not only one of the big reasons frameworks exists as they do today (because it's perhaps one of the earliest and probably the most famous example of a web app that 100% _needs_ a framework for all the reasons discussed everywhere in this thread), but that it's also the poster child case of why every ambitious/opinionated/inexperienced FE dev builds their own framework (Of _course_ I can't use jQuery/Angular/React/Fluttr! _My_ ToDo list app is _groundbreaking and special_ - just like gmail was in 2004, I'll need to write my own framework for this. Stand back! <flexes>") ;-)
- e12e 6y ago
  Isn't that where Angular comes from?

deleted 6y ago

[deleted]

triceratops 6y ago

> reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. Do people really do that? To me, that reflects bad frontend engineering practice. Even so for something like that, I'd use jQuery or something similar, because it's a much nicer API than the DOM.

dgb23 6y ago
How do you generate html in the first place? With React you have the same UI logic in one uniform framework. Whether you render statically, on request or in the client doesn’t split up your code. Everything plays together nicely. You get sensible editor support with linting and static analysis and more comprehensive error messages.
adrianhel 6y ago
Why bother with jQuery? I don't see the value add anymore.
- tambourine_man 6y ago
  Read this whole thread. People are rewriting it over and over again because it’s out of fashion.

tonyedgecombe 6y ago

>Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. I'm pretty sure gmail started out without a framework.

bigiain 6y ago
> I'm pretty sure gmail started out without a framework. I'm pretty sure you're right. I'm also pretty sure it's not only one of the big reasons frameworks exists as they do today (because it's perhaps one of the earliest and probably the most famous example of a web app that 100% _needs_ a framework for all the reasons discussed everywhere in this thread), but that it's also the poster child case of why every ambitious/opinionated/inexperienced FE dev builds their own framework (Of _course_ I can't use jQuery/Angular/React/Fluttr! _My_ ToDo list app is _groundbreaking and special_ - just like gmail was in 2004, I'll need to write my own framework for this. Stand back! <flexes>") ;-)
e12e 6y ago
Isn't that where Angular comes from?