3 ms·

I did not find this very convincing. I suspect it has to do with the author being very comfortable with site-generation tools, and not super comfortable with Ja

I did not find this very convincing. I suspect it has to do with the author being very comfortable with site-generation tools, and not super comfortable with JavaScript. They don't mention any frameworks (React, Vue etc) so I suspect the JavaScript they write is doing things "the hard way" from scratch. > My first impulse was to have a list of posts you can filter with JavaScript. > But the more I built it, the more complicated it got. Each “list” of posts needed a slightly different set of data. And each one had a different sort order. What I thought was going to be “stick a bunch of <li>s in the DOM, and show hide some based on the current filter” turned into lots of data-x attributes, per-list sorting logic, etc. I realized quickly this wasn’t a trivial, progressively-enhanced feature. I didn’t want to write a bunch of client-side JavaScript for what would take me seconds to write on “the server” (my static site generator). This is pretty trivial to implement in any framework. Generally speaking, I find most of the "You don't need Javascript and frontend frameworks, just write static HTML!" posts reflect the skillsets of their authors. Me, I never really did any site-generation or server-side rendering stuff, so writing everything in VueJS + JavaScript is the easy way.

endemic 2y ago
It’s rough for the old timers because as consumers of the web, we’re forced to use SPAs that have objectively worse UX. And sites are built that way now “because it’s how everyone does it.”
- AgentME 2y ago
  React doesn't necessarily mean SPAs. It has great support for server-side rendering and that was a big part of why React became more popular than other client-side JS frameworks of the time.
- Matumio 2y ago
  The sad thing is, there is no real obstacle to building a fast SPA. It's certainly not harder than to do it all "the old way". But you have to pay attention to performance. If you just implement as many features as you can in as little time as possible, then the outcome will be something like Confluence, I guess, where you wait several seconds to load a documentation page you wanted to just read, not even edit.
ricardobeat 2y ago
> doing things "the hard way" from scratch In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible idea for a team. For a bunch of tabs in your blog? Probably worth the trade. That said, the problems he describes would occur with React/Vue as well since they are a result of mixing a statically generated site with client-side rendering logic. It would not, in fact, be trivial without changing the server. > Me, I never really did any site-generation or server-side rendering stuff > I find [...] reflect the skillsets of their authors now I'm unsure if this is satire...
- bob1029 2y ago
  > Terrible idea for a team. I disagree, but I am 100% with you on the imperative for structure and order in the codebase. A typical angle - and it used to be very good - is that vanilla JS doesn't offer a good way to organize common code or impose some sort of structure. I find this to be at the heart of "wont work with a team" arguments. This is no longer the case and hasn't been for some time now (~10 years): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
- stevage 2y ago
  >In the current landscape doing things "the hard way" in plain JS is often simpler than with React. I'm not sure what "simpler" means to you. It is extremely simple to create and deploy a framework based app; `npm create vue` give it a name, answer a few questions or accept the defaults. I find programming in such an environment very "simple", because the framework is hiding a lot of complexity. > You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. All I can say is: if you have a codebase that has those issues, then the alternative implementation without a framework would be much more difficult to manage. It's true that Webpack can be very complex to configure, but out of the box configuration gets you pretty far.

endemic 2y ago

It’s rough for the old timers because as consumers of the web, we’re forced to use SPAs that have objectively worse UX. And sites are built that way now “because it’s how everyone does it.”

AgentME 2y ago
React doesn't necessarily mean SPAs. It has great support for server-side rendering and that was a big part of why React became more popular than other client-side JS frameworks of the time.
Matumio 2y ago
The sad thing is, there is no real obstacle to building a fast SPA. It's certainly not harder than to do it all "the old way". But you have to pay attention to performance. If you just implement as many features as you can in as little time as possible, then the outcome will be something like Confluence, I guess, where you wait several seconds to load a documentation page you wanted to just read, not even edit.

ricardobeat 2y ago

> doing things "the hard way" from scratch In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible idea for a team. For a bunch of tabs in your blog? Probably worth the trade. That said, the problems he describes would occur with React/Vue as well since they are a result of mixing a statically generated site with client-side rendering logic. It would not, in fact, be trivial without changing the server. > Me, I never really did any site-generation or server-side rendering stuff > I find [...] reflect the skillsets of their authors now I'm unsure if this is satire...

bob1029 2y ago
> Terrible idea for a team. I disagree, but I am 100% with you on the imperative for structure and order in the codebase. A typical angle - and it used to be very good - is that vanilla JS doesn't offer a good way to organize common code or impose some sort of structure. I find this to be at the heart of "wont work with a team" arguments. This is no longer the case and hasn't been for some time now (~10 years): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
stevage 2y ago
>In the current landscape doing things "the hard way" in plain JS is often simpler than with React. I'm not sure what "simpler" means to you. It is extremely simple to create and deploy a framework based app; `npm create vue` give it a name, answer a few questions or accept the defaults. I find programming in such an environment very "simple", because the framework is hiding a lot of complexity. > You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. All I can say is: if you have a codebase that has those issues, then the alternative implementation without a framework would be much more difficult to manage. It's true that Webpack can be very complex to configure, but out of the box configuration gets you pretty far.