4 ms·
>"web development itself is inherently complicated" The functionality of 99% of all websites I see these days can be replicated with simple DB calls, string co
by romaniv 10y ago
>"web development itself is inherently complicated"
The functionality of 99% of all websites I see these days can be replicated with simple DB calls, string concatenation and a handful of straightforward progressive enhancement libraries on the client side. Some developers simply choose complexity.
The fundamentally complex aspects of web development aren't solved by the stuff people are fatigued by anyway.
- herge 10y ago> can be replicated with simple DB calls, string concatenation [...] You must not have seen the flame fest about PHP on the rest of HackerNews!
- ng12 10y agoI 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 agoI 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 agoI 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 agoYou 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 agoI'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.
- clifanatic 10y ago> Some developers simply choose complexity Or have it chosen for them. I've been on dozens of "tool evaluation committees" in my life time and the only option that's never on the table is "no tool at all". It seems to me to be almost a no-brainer that if you can develop a functioning application using Javascript without using jQuery, or Angular, or React, or ext-js, or Dojo, or GWT, or whatever the hell else flash-in-the-pan "technology" we're going to be kicking off a never-ending migrating away from next week, you should. I find myself in a very tiny minority.