Hacker News Reader

Comment by 5350-uiop-1130 | Hacker News Reader

I miss the "immediate web". Being able to work on simple things without feeling like they are useless, pointless or perceptibly outdated.

Now it's install node, install git, install npm, install a gazillion packages, run localhost then hope everything works. Build command, clean command, eject commands, deploy command, pre processors, post processers, documentations full of so much jargon that i feel burnt out looking at it, hydration rehydration, pre-rendering, headless cms....on and on.

I find myself reverting to writing simple bash scripts, userscripts - they are more enduring, not built on a stack of fickle dependencies, fads and ever increasing complexity.

View on HN

If you build web pages without the whole JS frameworks and Node circus, they are pretty durable. Those helpers were invented because people started to build empires (complex applications) on sand (the web), so they are pretty useful for larger projects, but simple websites can still be easily built with plain HTML/CSS/JS.

yeah but there is no value, personally in building projects like that anymore, you can not use them in your portfolio or to progress your career - i was going to build a personal site, but realised it would probably act as more of a hindrance to me, because potential clients/employers would see that it was not using latest new js fad.

if it was up to me i would never touch those things, but that's what the market has become.

i even resisted learning typescript for so many years, because i loathe the idea of learning a language that needs to be converted to have correct syntax. same with jsx, i use it, but it feels horrible.

You think potential clients are digging in to the source code of your hypothetical personal website? You sound like you've identified a group of technologies as a personal enemy, and already don't use or want to use them. The most value you can deliver to a potential client when they visit your website, is in communicating concisely what you have and are capable of buiding for other people like them, not what you're capable of building for yourself as a vanity project

Interviewed and hired many developers. Not once was the tech stack of their personal website, if they had one, ever brought up or considered.

i just will assume most hiring gatekeepers will make superficial judgements about the appearance of your portfolio work and many developers will do the same about your code.

not everyone is willing to give the benefit of the doubt.

In most companies I worked for, there is no portfolio to show unless you want to violate the NDAs.

I poke around code that candidates have written. Simplicity is a virtue.

When doing consulting, many costumers only care they get a Website, not how it works underneath.

If the only reason you build websites is to get paid then you're part of the problem. Separate your personal and professional lives. Or do you not enjoy building on the web for fun?

> If the only reason you build websites is to get paid then you're part of the problem.

This is absurd. I write code for a living, I enjoy solving problems and that is part of my job.

I do not write code in my free time. I play video games, go hiking or go to the beach and maybe read a book with dragons in.

That doesn't make me a problem. My job is not my life. Honestly it shouldn't be, it is not healthy imo

You can code in your free time without your job being your life, as you put it. For example, your hobby project might have nothing to do with your day job and just be something you want to make or that gives you pleasure to tinker with. If you don't really enjoy doing it of if there are other things you'd rather do then you don't have to do it, obviously, but this idea that you can either never code outside work hours or have an unhealthy relationship with your job is a false dichotomy.

You're competing against people who do. "Should" it be that way? It's not the employer's fault some prefer to spend their free time programming too ;)

i've been doing this since 2007 as a full-time career. I think my interest peaked around the ajax/jquery era and has been in steady decline ever since. i'm just bitter about becoming a web dinosaur.

FOMO is a bad career advisor. It puts you in direct competition with all the other people anxiously doing only what they think everyone wants them to do. Sort of hard to distinguish yourself if you are doing exactly the same super trendy things everyone else is doing.

I would go so far as to say javascript hurts the web. If hacker news was written like facebook the user numbers wouldn't be the same. Endless transitions, spas, waiting for loading, glitches, popups with fades, all that is a waste of time - the user just wants to read text. I want clean loading, just simple clean html, fast rendering, nothing processed after i get the html rendered. What would be rad is a facebook.clean where you can just HN style rendering, clean tables, the browser keeps track of what you clicked, super fast interactions etc.

I’d say the opposite in my experience when I’ve been a hiring manager.

I prefer candidates who show that they understand their fundamentals, their primary domain and can show that they grow and adapt easily. The current hot technology is ephemeral and can be learned on the job by a competent engineer.

That said, my background is startups so I don’t know what larger companies expect.

My background is in larger companies. No one is going to care what framework your personal site is built on. If anything it might not even come up because there’s such an emphasis on Leetcode questions, but I seriously doubt it would hurt your chances.

It's OK to do a thing because you wish to, and not because it might advance your career one day.

People building for the fun of it with simple tools is what made the old school web that so many HN readers are nostalgic for.

These days it feels like everyone is constantly looking for an angle, feeling like nothing is worth doing if it can't be monetized and turned into content. Fuck's sake, people can't even go _fishing_ without strapping up with a GoPro and trying to sell their favorite tackle.

Be punk rock. Go do something for the joy of it. Go learn a language that no one will ever pay you to write. You have a day job to get paid. Why worry about it for what you do for fun?

> Be punk rock. Go do something for the joy of it. Go learn a language that no one will ever pay you to write. You have a day job to get paid. Why worry about it for what you do for fun?

you're right, i'm trying to get into that mindset. Being contrary for no other reason than absurdity.

Amazon and Google frontends work without Js. The same can be applied to other empires.

I strongly disagree that it has no value.

If I interviewed a developer and they showed me an impressive website/application that was built without a framework, I would probably be more impressed than if they showed me one that was built with one. An understanding of the basic building blocks of the platform is always helpful, just like I would consider knowledge of lower-level programming and different programming paradigms a huge plus, compared to someone who's only ever done web.

I would, of course, also be sure to ask them about why starting from Adam & Eve is only rarely appropriate in a business context, how it's important to write code that others can pick up and understand. I expect anyone but the most junior candidate to understand that no tech stack is perfect, and that it's all about trade-offs, and that the tech is a means to an end. We don't hire people to love a tech stack (most of them are pretty unlovable, to be frank), we hire them to, as quickly as possible, get good software in front of paying users.

If you come in and demonstrate that you can take a thorough understanding of HTML, Javascript and CSS up to something resembling a dynamic, modern, responsive web application, and if we can have an intelligent discussion about what the frameworks and infrastructure bring to the table, you're obviously miles ahead of someone whose knowledge stops at copy-pasting React snippets and googling the WebPack error.

The more I see the modern web, the more I appreciate PHP (LAMP stack or similar). On the client side, with IE6 more or less gone, most of it can be done with vanilla JS, no need for JQuery anymore.

If what you are doing is just another CRUD-based website, there is real need for more, PHP is designed to make that simple. I had a well deserved reputation for poor security, but they got better, and 90% of it is addressed by just using parameterized SQL queries.

You can still drag and drop a folder to the Netlify UI and it's published immediately. How you produce the static assets is up to you.

Of course, having to work with multiple devs on the same project adds lots of complexity to minimize risks and conflicts.

> having to work with multiple devs on the same project adds lots of complexity to minimize risks and conflicts.

That's when you link a GitHub repo to Netlify.

I miss view-source.

It used to be you could open up your dev tools and figure out how things were made. And you could learn all sorts of things about architecture and style and techniques this way.

Now its all buried in build processes and obfuscation techniques, as if your button handler is a tightly kept secret that's somehow protected by scrambling your variable names.

Although the other day I came across a complex app that was built in modern vanilla JS with native ES6 imports alongside regular old CSS. It was a work of art.

I got so tired repeating this and trying to convince others that just I created my own agency. Clients are happy, I’m happier, so I guess we are not totally crazy.

I remember the first time I heard the word "tree shaking" for CSS.

...I genuinely wondered what tree was involved. Took a Google search before I understood that it was industry jargon, which meant this: to reduce/minify code.

There are many similarly opaque things in the world of web-development.

Tree shaking doesn’t mean to minify the code but remove the CSS classes from the payload which are not being used anywhere. Proper term is dead code elimination (DCE).

To help clarify for the person you're replying to; minification could be considered to only mean: taking an interpreted language like JS, and essentially compressing the text of the code by doing transformations to it that don't change the semantic meaning of the code. Swapping out long variable/function names with short, computer-generated single(ish)-letter names. Removing whitespace.

Much of this was because real compression methods like zip simply weren't available during early decades of web development.

Obviously, if shrinking the code size is desirable, and you were building a library that did minification, you'd want to move on to also adding other, more dangerous changes that could change the meaning of the code, like removing unused CSS classes, doing DCE on javascript, etc, etc.

Since programming is a giant, decentralized soup of autodidacts, there's no "word of god" authority that can really say "this is the one true name of something". It's mostly just lingo that passes in and out of various communities, and a lot of times communities (as you're seeing in splintercell's comment) try to helpfully match themselves up and standardize so it doesn't degenerate into pure chaos.

Why is "dead code elimination" more proper than tree shaking? Is CSS even "code"?

Dead Code Elimination is the goal. Tree Shaking is just one technique to achieve that goal.

Tree shaking is not a web-development thing. Wikipedia says the term originally came from Lisp https://en.wikipedia.org/wiki/Tree_shaking

Every industry has things that have names that you might need to learn.

Imagine you have a root (let's say your index webpage). Then you can build a tree of what is used by what. So if you have a CSS classname that is used by C (C being an HTML element, component, whatever) and C is used by B, but B is not used by A (the root) then it's shaken (removed) and "falls" because it's not connected to the root.

Basically remove everything not connected to the root.

If you're telling a story about how you learned something, it implies that you have learned it.

Don't forget containerization: instead of just downloading sources, build them and run you need to think all the time outside the core problem.

I likte to think about the the term development UX in contrast of end-user/mass UXs.

You can choose not to use most of that stuff. I recently moved some stuff over to esbuild and that's been pretty helpful for that. Jest is a big and heavy thing but I've found it's the test framework that gives the least headaches without really needing to be configured. And of course deploying can be a one-line "run esbuild with the output going here". Or even check in the artifacts!

You lose the nice stuff like livereload but you can hack in something to that effect if you want to.

The immediate is how I code in private Web projects to this day, at work is another matter.

If I had a vote on the matter, it would still be fully SSR with a little bit of vanilaJS when need.

For frontend stuff, moving away from the JavaScript ecosystem to C# with blazor has really improved my motivation.

At the expense of unrealistic download size.

> not built on a stack of fickle dependencies, fads and ever increasing complexity.

Every dependency is a benefit and a liability. It's been interesting to watch this ecosystem grow over the past decade as we collectively explore how much liability we're willing to accept.

This was why I created https://webcode.run the elimination of all tooling and a fast development loop even for backend

I hate all that nonsense, so I don't use it.

Reply on news.ycombinator.com