Hacker News Reader

Comment by Daishiman | Hacker News Reader

The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc.

I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fastest experience at the cost of having to zoom in every once in a while, but the price is worth it.

View on HN

My org just bought a professional bootstrap template. It takes 3 build tools and 1500 node packages just to build the SASS into a CSS bundle. It boggles my mind that this is normal in the front end world.

only 1500? you got lucky!

gatsbyjs (React framework) has so many dependencies it breaks GitHub's dependency graph

https://github.com/gatsbyjs/gatsby/network/dependencies

This is absolutely absurd. This is ammunition for others to not take the Node.js community seriously.

I ripped out one dependency, and it dropped build times in a recent project by an entire minute! Turns out that one dependency had 100's of megs in transitive dependencies...

I handwrite all my CSS directly in the browser and the only "dependency" I use is a reset.css. The zooming issues some of those old themes have can all be solved with a modern css grid template (one for smartphone, one for desktop). Needless to say sites like these can be blazing fast.

I only use js for small things like maybe hiding some header when scrolling down (no jquery, handwritten vanilla js with maybe 20 linws of code), but even that would not be strictly needed.

And even CSS resets are getting close to zero these days.

That is true and very fortunate, I noticed how this is getting less and less of an issue over the passt years.

I take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability

There's maybe two of those questions that you actually have to care about as an architect. Nobody's forcing you to chase fashions except you.

Frontend folks have an excuse. They cannot avoid using JavaScript, since they're limited by what browsers support.

Backend developers chose to write mountains of yaml

I am a proponent of server-side, use Apache Tapestry for most production apps and have only one yaml file in all the projects.

I recall a couple of years ago when Kubernetes was all the rage and jesus christ the amount of YAML was unbelievable.

I have done nothing but backend for a decade. Docker's been around for the past 6 years and still going strong.

Database? Postgres, always. You have to bend it so far until it breaks it's not even funny. If you need something else, you'll now.

Backend lang? Python. Framework? Django. Need data munging? NumPy/SciPy/Pandas/PySpark. Need a really high speed component? C will do, Rust if you feel fancy.

OS? Ubuntu, or Debian. They'll do well. Again, you need to have really, really good reasons to use anything else.

Of course there's alternatives! But there is absolutely no reason to move away from this stack. For some reason frontend developers seem to be either on a constant treadmill of moving technologies, or being stuck with subpar old tech with clear deficiencies.

So React has been around longer than Docker? Good to know that frontend is on a slower treadmill than backend, which according to this thread has moved on to alpine or htmx or something else.

React is for sure a relatively stable part of frontend, but the ecosystem around it seems to be building mountains of complexity on top of React.

React's ideas of best practices and library ecosystem have sure changed way more.

I dunno man, my "backend architecture" is a bunch of Rails servers (some web servers, some queue servers, but they run on the same codebase with different entrypoints), a PostgreSQL server, and a Redis server.

I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'.

But at the same time, if you wanted to get away from that and have replies inline, that doesn't require very much Javascript at all! It can just be incrementally added to the page you already have with little fanfare.

> I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'.

OTOH, making a reply button that drops-down a textarea with "save"/"cancel" buttons requires about 30 lines of Javascript.

And yet, almost all "modern" sites that have only this functionality has megabytes of dependencies.

Maybe both extremes are bad, and Javascript is like adding salt to food - too little and you'll be able to eat it, but won't enjoy it. Too much and you won't even be able to eat it.

Reply on news.ycombinator.com