Hacker News Reader

Comment by seanp2k2 | Hacker News Reader

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself.

Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages.

I remember a time when people here would cite http://youmightnotneedjquery.com/ a lot. Modern browser APIs can do more than ever. I wonder if there’s a more recently-updated equivalent about how one might not need node tooling at all to build a static site.

View on HN

I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.

have a link?

I even do similar for a microblog: https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).

My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available.

While at work, it has been mostly Java JEE/ASP.NET since they exist.

When I play around with WebGL, it is all JavaScript modules and script tags, nothing else.

No babel, no webpack, no npm, nothing, just browser standard capabilities.

Fully agree with your point of view.

The irritating thing is that this is often possible even with modern JS. I shipped a rather complex app (though still essentially CRUD that's used internally) this winter that is Vue 3 based. It's just the Vue library itself plus the app logic, directly included using script tags. No other libraries for Vue, no build steps and so on.

It just feels great that I could just immediately start fixing things on any computer should an issue pop up next year or so, without worrying about dependencies or some build step being broken etc.

Yeah, I really share the sentiment.

I guess younger generations get taught the cargo cult ways of SPAs, and aren't able to realise how much simpler it can be done, specially be letting the browser do the work, instead of replicating it on a dynamic language.

Just from what I've heard about Deno - isn't this exactly what they are aiming for? Bring Node/JS back closer to the browsers and make use of ES modules etc?

This plus a CMS. Writing is a separate activity for me. I also like that it handles tags, metadata and pagination for me. Templating and thumbnail generation is also nice.

Problems start when you need to change the HTML structure, the CSS file name, or having a paginated list of your blog. If you do publish a lot, you'll need some sort of CMS.

These frameworks/libraries are trying to replace WordPress, because WordPress is also a mess to work with.

> you'll need some sort of CMS.

You will not need a CMS unless you publish multiple articles per day (and even then...). That's far beyond anything the preceding posts were talking about, so it's not really relevant.

or unless you build a site for somebody for whom editing Markdown files is too much

I'm also making my blog in plain html/css/js with the goal of making it as minimal as possible - in fact the JS wouldn't exist if it wasn't for the fact that it includes some running code examples about demoscene stuff.

Except for my procrastination, it's a real pleasure to write this way, no frameworks, no libraries, no build systems with 10k dependencies, no preprocessors for content - just write plain HTML and be done with it, it's always forward compatible, you always have all HTML features and don't have to worry about some preprocessors capability... If I ever have a genuine need for some kind of build process, it will be a self contained script, I'm fed up with the fatigue of the churn of the web tooling world - i'll stuck to a script that will still run in 10 years.

I did make one choice to alleviate the tediousness of writing tags: 'white-space: pre-wrap', which allows you to avoid html tags for basic stuff like paragraphs. Also using fixed width font and ch units since it's mostly a coding blog so this fits well and allows ascii diagrams without extra work... authoring feels like mostly writing an old skool text file with some nice HTML/CSS upgrades.

There is an ebb and flow in the JS ecosystem.

First we get a framework. That framework is missing some key functionality or features so we get plugins and eventually a meta-framework standardising the new behaviour and maybe introducing a slightly new paradigm. That meta framework gets unwieldy and we get a ground up rewrite (new framework) that trims the fat and uses the new evolved features as first class concepts.

This is exhausting only because of external and internal pressures to "keep up". I don't see anything inherently wrong with the evolution of ideas and concepts being explored in breadth and depth. Writing and publishing a new JS framework has a very low barrier which is a huge positive that I rarely see extolled compared to complaining that the ecosystem needs to constrain itself.

Svelte has everything I need to build websites and apps. The performance, bundle size, and DX combo is unparalleled. All vanilla JS libs are plug-and-play. Building production-ready apps is incredibly fast, and done with less code than any other framework.

Svelte's compiler-first approach really fixes all of my problems with the JS ecosystem. Compile-to-JS langs aren't new, but learning a whole new language has non-0 overhead. HTML, CSS, and JS/TS in a .svelte file is awesome, and the syntactic sugar makes the ugly parts of JS (like state management and reactivity) extremely trivial to implement.

The first class support for Vanilla JS & Typscript is brilliant. Vite and ESBuild are incredibly fast and hassle free. The water has never felt nicer for me as a web dev!

I like Svelte a lot but haven't dived in deep yet. I'm currently waiting for SvelteKit to reach 1.0. What does your general setup look like for something relatively large and complex?

I use Routify for everything- the ecosystem of tools from it's creator Jake already takes care of everything Sveltekit aims to solve.

I have Starter Templates with everything set up the way I usually like it if you want to check them out-

SvelteKit starter template: https://github.com/FractalHQ/frackit

Routify starter template: https://github.com/FractalHQ/fractify

In your argument, you could replace HTML/CSS with Assembler and JS/React/whatever with C and everything that came after.

The productivity gained from these Tools is worth it, even if some use cases could be solved without it.

That's not really fair. A lot of static sites simply don't need JS at all but they're built with it because it's deemed "best practice". My latest website, for example, has zero Javascript in it.

So much content is published in Github READMEs (typically markdown) and while Github itself will have Javascript elements, it does demonstrate that you don't need Javascript heavy sites to publish content.

I honestly think half the time the front end best practices are based around what's more intellectually interesting for developers rather than what is genuinely a better website.

You can use NextJS to build a fully static website with no JavaScript at the initial loading. There are tons of libraries (I think around 300Mb) to compile your site, but if you do optimizations right, the final website should be as lightweight as you expect it to be.

What you get? Routing, instant refresh, image optimization, and code optimization (your CSS could be smaller if you minify it).

Hmm, I think 300mb is a lot...

Completly unrelated, a page editor that writes pages in a WYSIWYG using only HTML and CSS, Dreamweaver style, can't be compared with using Assembly.

> The productivity gained from these Tools

You don't gain productivity using 500 libraries pulled off NPM unless it's write once read never.

I remember a few years back, just before You Might Not Need jQuery became a site, any mention of not needing jQuery would immediately be met with some analogy to writing assembly.

The comparison was foolish then and just as foolish now.

Spoken like someone that has never actually created an webapp with significant scope. Reading your comments in this thread is a good reminder how strongly the clueless argue about things they don't understand.

I once created a language parser that supported over 40 languages and was used by over thousand other projects. It was interesting when I discovered it being used at my company. It wouldn't exist if I were crying about how hard life is without tools to do my job for me.

Thanks for confirming that you have no clue about frontend development and it's up- and downsides while running around with a big mouth claiming competence.

You really are an extreme case of the dunning kruger effect in action.

The application I mentioned is written in JavaScript and runs in both the browser and with node.

I don't think you know what Dunning Kruger is. I have never claimed to be anything great. I only mentioned I wrote an application and other people used (continue to use) it.

Or maybe you have to little self awareness that you haven't even realized how heavily it applies.

And I am surprised that I have to point it out again: that you once wrote something which people used in java script says nothing whatsoever about your experience in frontend development.

In fact, it kinda confirms that you don't have any.

You sound like a grouchy old man that got left behind and loudly complains about it.

Imperative UI sucks. There is a very good reason everyone is using declarative UI frameworks these days

And not just because they’re declarative. I’m currently working in an ecosystem of ~decade old JS projects. The imperative DOM stuff is of course a hassle, but the data flow is (predictably) all over the place. It takes a lot more discipline to keep data flow reasonable in an imperative UI. Modern declarative frameworks are generally opinionated about data flow (sometimes that’s their only opinion!).

Because they are afraid of the DOM and yell at each other about code style?

This is common, but it’s still very junior thinking.

The best way to minimize tech debt is to supply the most direct solution to a given problem and refactor along the way to bring similar solutions together into a single delivery. Decoration in the code is not that.

I am very familiar with the DOM and have no problem using the DOM apis. You seem to have no experience writing complex Web apps, and seem to give little thought to maintainability. I'd never hire you.

Complexity is bad. I prefer to write simple web apps. Less is more.

> I'd never hire you.

You probably couldn’t afford me.

I’m all for not having dependency hell and a million frameworks. I just want some UI controls like sortables lists, tables and not have to type everything out.

If I'm writing frontend code alone, I do it by hand. In a team, these heavy tools become important to keep some sort of cohesion. Even then, I'm not entirely sure.

Nonetheless I had a good cycle the other day when I had to pull 400 MB of Javascript to build a single static page.

I advocate for frameworks in almost all team projects, the tools act as a set of idioms and best-practices your team should know and use.

I don’t do a lot of front end dev. Just some personal projects here and there and I usually just slap Bootstrap on it to make things look reasonable. I had to do a bit for work and man, when I started actually reading the docs I was surprised to find things like form validation [1] out of the box! There were a few others that I forget now, but I was pleasantly surprised at how much I _didn’t_ have to do. I wound up needing no extra JavaScript.

[1] https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_i...

> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server

I think that's exactly what 'computer literacy' should enable laypersons to do.

And we as a profession should be teaching that and developing assistive tools (like htmltidy) rather than intrusive ones (like hugo or worse wordpress. Both or nice and helpful but intrusive nevertheless). Kids should learn this in grade 6 or so. Be it in school or elsewhere. Before they post pictures on inhumane and ignorant advertising platforms they should know that they can do otherwise.

The moment you don’t use the maximum number of tools possible or write any line of code that doesn’t call some framework method people will harass you about NIH. I see it nearly everyday online and used to see it at least monthly in the real world at work.

If you can fix that problem all this excess tooling stupidity will largely fix itself.

NIH?

https://en.wikipedia.org/wiki/Not_invented_here

I think part of the issues is that the line between enterprise tooling and smaller site tooling has disappeared.

Even people building personal blogs will be inclined to use enterprise tooling, and take on all of the overhead of tool-chains and configuration.

> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages

Sure. Then try to write a highly complex e-commerce frontend app with this approach and tell me how does it work out.

If notepad + HTML is enough tooling for your web development, you are not a potential user of such a framework.

Good news then, you can just ignore it!

The exakt same thing happens in the backend. Kubernetes, docker, procfiles, apt, yum, various frameworks and languages...

Not everyone is building single page static html sites.

I think the weird weighting goes in the other direction though, more people are over-encumbered with tools they didn't need.

Reply on news.ycombinator.com