Hacker News Reader

Comment by papertokyo | Hacker News Reader

Frank is right, of course. Staying up to date with the tooling, best practices, and user expectations of the web requires an unreasonable amount of attention if making websites is only a small part of your service offering.

One reason I prefer frontend libraries like Vue and Svelte is they feel closer to the grain of the web (HTMLesque templates with JS and CSS sprinkled in), and provide a reasonable level of abstraction and magic. The learning curve and paradox of choice is also much easier to navigate than React especially for solo devs who aren't working on a huge app with a team.

View on HN

Let’s not just pick on frontend. Has anyone seen what it takes to run something on AWS? Devops is nearing similar levels of insanity, and often for applications that won’t even have 50 users (seriously, all these companies that advertise for AWS experience for a tool that is going to be fucking internal with less than 50 users).

It all builds up in me to be honest. You get the frontend complicated, then the deploy/infra gets complicated for the needless cloud dependency, and then the backend people don’t want to get left out of the party so they manage to rewrite their shitty php app in Go.

It’s like a shitty third world country. Not only do the roads suck, but there’s no water or electricity half the time, and you need to bribe everyone to get something. Instead of it becoming a wasteland, the population somehow still increases (more people actually entering tech). Now you really can’t change anything because there’s too many people.

How the wicked live.

> Has anyone seen what it takes to run something on AWS?

I've given up every time I've tried it on personal projects. It's just a complete poorly document mess indeed.

At work we host our stuff on AWS but we have an ops team that deals with all the garbage. All I care about are APIs, endpoints and that one thing can talk to another.

Yeah, so much for the fantasy of cloud platforms eliminating the need for ops staff. The guy who used to setup and manage your Linux VPSs just switched jobs to manage your AWS infra and charges extra for it.

Finally a voice of reason. The front end isnt the only thing that has become complicated. How many services are running on k8s? Now how many of them actually need it?

The list goes on. The front end isnt that complicated relative to back end, there is just one ecosystem vs 10 for the back end.

I recently got asked to consult for a project. I warned not to go with AWS that the tools they were wanting to put online were not well suited to AWS.

Then I got sent a 15 page deployment document outlining the AWS infrastructure they had gone with. They paid megabucks and got a rube goldberg machine. To run a zend based PHP site developed 15 years ago that has never had any significant maintenance.

And this is exactly why any of my hobby projects that involve JS are done with plain JS, with as few libraries as possible. I might pull in specific libraries, but I don't want to pull in a giant framework that will be outdated the next time I decide to work on that particular project.

> ... are done with plain JS, with as few libraries as possible ...

I was having the same opinion and practice. However, I'm kind regret it as well.

Even if you done everything with plain JS, eventually, one day some idea will float into your head such as "Hey... I want to automatically compress the script file/snip", "Hey I wonder if I can polyfill all my script", "Automatically bundle assets?", "Compress assets images?" etc.

Then, you start to learn Webpack/Gulp/Grunt (if the last two are still alive), and commit your entire soul to it few minutes later.

I think the reason for the messy front-end tech is, the Web itself is messy. You have to consider a lots of things, networking, file management, cache management, cookie, user-side storage, security etc. Some eyes saw the problem and then built a framework to address it, then others discovered some other issues in the framework ... the circle of life.

I guess we'll eventually settle down on something when people finally figure out what they want from the Web technology, or when the Web is "dead" (no dramatic changes anymore, like what happened to Desktop Applications today).

I have lots of tiny hobby projects. I never want to do any of those things you mentioned. Just a simple page, with the minimum amount of javascript to make it work.

> Hey... I want to automatically compress the script file

The trick is to write so little JS that its bandwidth usage does not even register. I'm recently going as far as to include licensing headers and extensive comments in my website JS, see e.g. <https://xyrillian.de/res/chapter-marks.js>.

I can't find a link at the moment, but there was an article on Hacker News a few years ago defending the use of plain text web pages with minimal styling. The page loaded amazingly fast, rendered well on both desktop and mobile, and had fast interactions with the page. The author had also included the full text of Moby Dick, more content than is ever served in a typical webpage. It was a fun and cheeky demonstration that it isn't the content of a webpage that results in poor performance, but all the frameworks, ad targeting, and client-side compiling of a webpage.

(Side rant: I refuse to use the term "client-side rendering", because dang it, "rendering" makes an image. "Client-side rendering" as web developers use the term doesn't actually render anything, but instead compiles the page down to HTML, which is then rendered by the browser.)

I'd put that as a difference between hobby projects and work projects. For work projects, there is some amount of time that can be allocated to continual development. The project itself has value, and needs to stay up to date, and so sure, it may use the framework of the day.

For a hobby project, if I personally don't have fun with it, then nothing gets done on it. If I decide after a few years that I want to pick a project up again in order to add a new feature, the last thing I want is to find out that framework X needs to be replaced with framework Y, and so the two weekends I had expected becomes two months of weekends to rewrite the whole thing.

I must say it's a valid point. After all it's a hobby project, having fun is the first priority :D

However, one could also say "Well, it's a hobby project, so I'll just slap this framework on to save my time..." or "What? I have to manually deploy this hobby thing every time I made a change? I'll just put it on a CI and let Webpack pack the thing for me"...

My method is this: I will start the project with all new tech/frameworks/lib/"display: grid", then I publish the project, if it turns out to be a success, I'll maintain it (including upgrade the framework, bug fix etc); if it's not, I'll just put it aside and start another one. This way, I can touch/learn many new stuffs that might later benefit me in my day job without any risk.

So, I believe it eventually boils down to personal preference (based on objective information on hand, of course) :D

Makes sense. For me, I like to get hobby projects for my own personal use. The "publishing" involves pushing it to github, then doing absolutely nothing additional with it. But because I use it on my own, I may want to add more features to it later.

For frameworks, I'm sure they save time once you are familiar with them, but that also requires evaluating which frameworks to use and how to go about using them. That ends up taking a lot more time than throwing something together with plain JS.

That definitely makes sense, especially if you're using the hobby projects to learn about frameworks that you'll later use elsewhere. I tend to do the same thing on the compiled side, trying out different libraries and languages. (For example, picking up Rust for last December's Advent of Code challenges, then porting some of my other projects over to make some performance comparisons.)

Part of this is also that my dayjob has very little interaction with JS. If/when I use JS in my dayjob, I'm usually picking something minimal so that it can be used/expanded on by others without framework-specific JS knowledge. My goal is to make sure that I leave behind a codebase that can be read/understood by as many people as possible, which may mean picking a software stack that has a bit worse usability, in exchange for ease of finding developers.

Another thing I find weird is how bloated static typical site generator tools are. The delivery medium of static HTML is timeless. But the odds that a static site generator with dozens of dependencies will still work N years from now? Grim.

just write html by hand. With html5, implicit and auto-closing tags, it's really not more difficult than markdown. Then your "generator" is simply the cat program, that appends a common header and footer.

They all started off lean and mean. Then after adding feature after feature they become bloated. Then the next lean-and-mean static HTMl generator becomes vogue.

Bashblog[1] is pretty lean, and doesn't use any dependencies.

[1] https://github.com/cfenollosa/bashblog

One of the reasons I like Hugo: it's a single executable that will basically work forever. There's no need to update to a newer version if the one you have meets your needs.

'Typically' meaning...? Jekyll? Gatsby?

I have a couple of older static sites (one using Jekyll/Octopress, one using Middleman), and if I ever do a bundle update something is guaranteed to break. Not sure if that's the "bloat" the parent comment is talking about though.

I've been using Perl Template::Toolkit since around 2001 and it's even better since version 3 was released. Worth a try. You don't even need to know Perl to make use of it.

Yes. I was on Jekyll 2 years ago, I don’t think I’ll be able to compile it in two years. It’s already on an old version of Ruby if I remember, if not Bundle or Gulp or... and it’s just a simple website.

I've had this exact issue with my Middleman sites.

That is why I've changed to Hugo (from Hexo & Gatsby). It does exactly what is supposed to, it doesn't import any dependencies and it is quite fast. Besides, no runtime is required.

I thought about plain HTML, but writing blog articles with it is a bit of a pain. Hugo was quite the right balance.

agreed, but for me the appeal of static site generation is that the input is typically just markdown and some templates so even if a particular generator ceases to be supported it should be trivial to drop in a replacement in whatever the currently fashionable language is.

A micro-library like https://redom.js.org/ does make things easier though. I have also given up on mega-frameworks - just too many things to keep in mind as I get older.

Here's my "femto-library" for creating DOM dynamically from JS:

    function ce(tag, attrs={}, children=[]){
     var el=document.createElement(tag);
     for(var attrName in attrs){
      el[attrName]=attrs[attrName];
     }
     for(var child of children){
      el.appendChild(child);
     }
     return el;
    };

Easier through ignorance seems like cheating IMO. you're basically saying yes things are harder but I just ignore them. How would a newbie decide what's safe to skip?

While agree with your conclusion, I don't agree with your argument to reach it. Any software development sits on such a tall and wobbly stack of dependencies that no one human can even understand every layer, let alone build it. For most projects, I don't hand-solder together transistors into the logic layer, write my own bootstrapping compiler out of hex assembly instructions, or directly interface with graphics drivers to display the program's output. That doesn't make these be bad programs or bad projects, just because they are focused on only one part of the program space.

My concern isn't in "ignorance" or "cheating", but in spending time to learn a technology or framework that may quickly become obsolete.

This should be industry standard practice.

Reply on news.ycombinator.com