3 ms·

As I’ve gained more experience I feel like this advice is just “edgy” and no real engineer would willingly pick a solution that might not scale if things pick u

by tnomey 2y ago

As I’ve gained more experience I feel like this advice is just “edgy” and no real engineer would willingly pick a solution that might not scale if things pick up. HTML and JQuery starts nice but add enough complexity and tell me you didn’t just hand roll your own framework. Now you’ll need documentation in order to onboard anyone if you are lucky enough to be in a position to expand. The shiny new framework can create a static site and a true web app and is likely well documented with examples. The tradeoff is a subset of users have longer load times.

throw_m239339 2y ago
Some people are really selling complex solutions around React though, for instance. The lib itself isn't that complicated, but there are JEE levels of frameworks built on top of React now and the people selling that can't even fathom the irony in all this... It's almost easier to learn JEE and Glassfish than stuff such as Next.js...
mablopoule 2y ago
While not a wrong response in itself, the onboarding cost argument tend to be a bit exaggerated most of the time, because unless you plan on hiring people for a week at most, you're usually better served by avoiding sources of complexity. The argument is to avoid going all-in on Redux by default if you're doing a React project, not telling you to hand-roll your own Redux. If you're doing a mostly-static site with a few bells and whistles, then HTML and plain old JS will probably do.
unclebucknasty 2y ago
>but add enough complexity... I don't know that we spend enough time questioning whether that complexity is necessary. Because, yes, if we want to transmogrify Web standards largely intended for a static document model into a full-blown application platform then there will definitely be complexity involved. Especially true if we do so while keeping those Web idioms fully surfaced. But, how often do we really need SPAs versus traditonal Web apps that feature judicious use of dynamic behavior? I doubt that the complexity chasm is frequently worth it. But, if it is, then we need to commit to standards/frameworks that push down the complexity by abstracting away the underlying Web idioms that create it.

by tnomey 2y ago

throw_m239339 2y ago

Some people are really selling complex solutions around React though, for instance. The lib itself isn't that complicated, but there are JEE levels of frameworks built on top of React now and the people selling that can't even fathom the irony in all this... It's almost easier to learn JEE and Glassfish than stuff such as Next.js...

mablopoule 2y ago

While not a wrong response in itself, the onboarding cost argument tend to be a bit exaggerated most of the time, because unless you plan on hiring people for a week at most, you're usually better served by avoiding sources of complexity. The argument is to avoid going all-in on Redux by default if you're doing a React project, not telling you to hand-roll your own Redux. If you're doing a mostly-static site with a few bells and whistles, then HTML and plain old JS will probably do.

unclebucknasty 2y ago

>but add enough complexity... I don't know that we spend enough time questioning whether that complexity is necessary. Because, yes, if we want to transmogrify Web standards largely intended for a static document model into a full-blown application platform then there will definitely be complexity involved. Especially true if we do so while keeping those Web idioms fully surfaced. But, how often do we really need SPAs versus traditonal Web apps that feature judicious use of dynamic behavior? I doubt that the complexity chasm is frequently worth it. But, if it is, then we need to commit to standards/frameworks that push down the complexity by abstracting away the underlying Web idioms that create it.