3 ms·

I think there's a divide here -- "websites" you and I and the rest of HN visit, and "web applications" which are non-trivial interfaces to complex data. If you'

by ng12 10y ago

I think there's a divide here -- "websites" you and I and the rest of HN visit, and "web applications" which are non-trivial interfaces to complex data. If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong.

sotojuan 10y ago
> If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong. Yet this is what everyone does and what romaniv means. We have good tools for applications that people use for static content. Here's my reasoning: As someone looking for a Web Dev job, your static site built with Handlebars or server-rendered HTML won't impress anyone. Build it with React/Redux/Immutable and suddenly you get more interviews or at least more hits. This has happened to me. Therefore, when those people finally get employed they'll just keep building with the tools that got them the job and never think if they really need them. If you switched a complex React app to a server-rendered Node/Rails/Django one, how much more less work would you have to do?
- ng12 10y ago
  I think "javascript fatigue" is just a bad term. It's like sayings I have "hammer fatigue" because I've been whacking at screws all day.
dozzie 10y ago
> and "web applications" which are non-trivial interfaces to complex data I'm yet to see these non-trivial interfaces to data that justify megabytes of JavaScript in actual production use. There are several cases when it makes sense (e-mail client (but not that much, and can be just fine without any JS whatsoever), text processor or spreadsheet, chat), but those are rare.
- ng12 10y ago
  I write business applications for a living, and those tend to have lots of asynchronously loading data, dynamic UIs, and fancy little widgets like charts or graphs. Just because you never use them doesn't mean they don't exist.
  - dozzie 10y ago
    You do realize that those "fancy little widgets like charts or graphs" don't need JavaScript? We had them for dozen years before the "everything needs JavaScript" fad. OK, let's put charts and graphs aside. What do these business applications of yours do that need JavaScript and can't be equally well done traditionally, on the server side?
    - ng12 10y ago
      I'd love to know how you'd build an interactive chart that live-updates with new data and has pan/zoom functionality without Javascript. Or how you'd asynchronously provide updates to a stream of events (e.g. Facebook) from the server-side.

by ng12 10y ago

sotojuan 10y ago

> If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong. Yet this is what everyone does and what romaniv means. We have good tools for applications that people use for static content. Here's my reasoning: As someone looking for a Web Dev job, your static site built with Handlebars or server-rendered HTML won't impress anyone. Build it with React/Redux/Immutable and suddenly you get more interviews or at least more hits. This has happened to me. Therefore, when those people finally get employed they'll just keep building with the tools that got them the job and never think if they really need them. If you switched a complex React app to a server-rendered Node/Rails/Django one, how much more less work would you have to do?

ng12 10y ago
I think "javascript fatigue" is just a bad term. It's like sayings I have "hammer fatigue" because I've been whacking at screws all day.

dozzie 10y ago

> and "web applications" which are non-trivial interfaces to complex data I'm yet to see these non-trivial interfaces to data that justify megabytes of JavaScript in actual production use. There are several cases when it makes sense (e-mail client (but not that much, and can be just fine without any JS whatsoever), text processor or spreadsheet, chat), but those are rare.

ng12 10y ago
I write business applications for a living, and those tend to have lots of asynchronously loading data, dynamic UIs, and fancy little widgets like charts or graphs. Just because you never use them doesn't mean they don't exist.
- dozzie 10y ago
  You do realize that those "fancy little widgets like charts or graphs" don't need JavaScript? We had them for dozen years before the "everything needs JavaScript" fad. OK, let's put charts and graphs aside. What do these business applications of yours do that need JavaScript and can't be equally well done traditionally, on the server side?
  - ng12 10y ago
    I'd love to know how you'd build an interactive chart that live-updates with new data and has pan/zoom functionality without Javascript. Or how you'd asynchronously provide updates to a stream of events (e.g. Facebook) from the server-side.