Hacker News Reader

Comment by axiosgunnar | Hacker News Reader

Everybody get prepared for the predictable onslaught of Hackernews purists who are all about to faint after reading that CSS has become the next prey of the devil - Javascript.

Nevermind that humanity has experienced a quantum leap in productivity and e-commerce that has given generations of entrepreneurs wealth and every consumer on the planet unprecedented quality of life thanks to the Web, and that Web being made possible precisely because the developer-friendly, move fast and break things route that Javascript has taken from day one.

But because there is a new Javascript framework coming out every day (I'm surprised competition is seen in a negative light, on HN out of all places), because it's easy to learn (and we all like to gatekeep a bit, don't we?) and because it's not a "real" language (since you cannot shoot yourself in the foot with a use-after-free), Javascript has become the prime target of ivory tower grumbling.

View on HN

"Please don't sneer, including at the rest of the community."

https://news.ycombinator.com/newsguidelines.html

I think I agree with most things except easy to learn... Every time I want to get back into programming, the complexity of javascriot frameworks, the infinite variety of ephemeral choices, bounces me right out.

Of all programming languages now and past, javascript as it is used today (as opposed plain language) would not be my first choice for "easy to learn". I feel there's huge effective gatekeeping with it but that's just an outsiders perspective :-/

I choose to ignore the frameworks for that very reason. This line of thought makes me far less employable but then why would I want to work a job I hate only to drown in weak unnecessary abstractions and all the defects and poor scale that come from that?

I agree that frameworks might be a challenge. I would consider learning full-blown frameworks (e.g. React) pretty much like learning a new language, especially since JSX is a new syntax (albeit it's pretty much HTML).

Regarding React, I consider the "hooks" coding style to be INCREDIBLY ergonomic and have been wondering sometimes if React-like "hooks" could be used elsewhere, esp in other programming languages. Or does that only make sense with UIs?

I think React hooks would fit nicely anywhere you need incremental computation, and a compiler is the first thing that comes to mind. They’re made for efficiently updating the output (DOM) in response to small changes in the input (sum of past user actions). If you can format your problem like that, based on a component structure, a similar API might be a good fit.

Hooks are class-declaration except your properties and methods are read FIFO in declaration order, rather than by a lookup table. Unless you really like the FIFO part of it, OO languages all have that already.

But what I meant that I liked about hooks is the "automatic rerender" in React, the reason this feature is called "hooks". I'm not sure simply declaring a method on a class would be the same?

If you operate under the same restrictions as React (single-threaded, you must call a setter method to modify properties rather than accessing them directly, code outside your class is responsible for deciding whether to call its "render" method) then yes, it's the same. Change any of those and it gets harder in basically the same way it would for Hooks if any of those changed.

> Hooks are class-declaration except your properties and methods are read FIFO in declaration order, rather than by a lookup table.

React Hooks are equivalent to React class components all of whose state management is done through setState, but with the difference you describe. Personally, I find hooks more natural than classes whose state management is done exclusively through setState, but that’s obviously a big YMMV.

> I think I agree with most things except easy to learn... Every time I want to get back into programming, the complexity of javascriot frameworks, the infinite variety of ephemeral choices, bounces me right out.

The Javascript ecosystem is dismal. It's very disparate and there's a million ways to do one simple task, compounding that is that things that sound like simple tasks, like rendering a page, are actually not.

If you want a place to start, where the ecosystem is fairly beginner friendly and consolidated, checkout Vue and Nuxt.js. I recently explored every possible frontend for Go that I could find: desktop, web, or otherwise. The fact is that HTML, JS, and CSS still produce the best experience for the end user. Vue and Nuxt made it really easy to produce a hybrid Server Side Rendered and Client Side Rendered (aka Universal) app with still a significant amount of effort, but with that effort directly improving my UI rather than my build environment or configuration.

I think this is true when you just constantly reach for frameworks.

It’s fine to do so, but knowing the core primitives of the language and the DOM can get you very far without having to reach into a bucket of libraries from npm.

As for bundling, there was and will always be tools, people like to think it was just throwing script tags onto a page before npm and the modern packaging ecosystem happened but that’s not really true. At the heigh of jQuerys popularity there were (and are) entire CDNs devoted to serving it and its plugins (which many evolved to serve all kinds of different pre-packed JS bundles) as was a myriad of concatenation tools that even pre-existed before nodejs

I remember namespacing and dynamic loading tools too. I can’t remember their names anymore but this is not a new thing.

It’s always been volume and choice. It’s much bigger today than it was back then but it’s always been this way as far as I can remember

You are misusing the word simple. Simple means fewer, which is quite different from easy which means low effort, straight forward, or less learning.

I definitely meant simple. To the average newcomer to Javascript, what they're familiar with is server side rendering. An HTML page is sent from the server, the markup is rendered, and bam - a page.

Now, go tell this newcomer that you don't actually need a server to serve multiple web pages, it can just serve one! Client side rendering with a client side router is a pretty far departure from what even experienced programmers know about the world.

Now, go tell this newcomer that you can absolutely still render components from the server without redrawing the whole page. They'll enjoy this until they run into the limits and constructs of SSR. Again, a pretty far departure from send a whole page.

Now, go tell this newcomer you can do both at once, and that often it's beneficial to do so. You have taken what was a very simple task and made it quite complex.

It's nothing compared to Python, I feel. I'm trying to get up to date there now, and just this week two different runtimes were announced. There are X different projects for type checking. Django isn't hot anymore, so there's now all kinds of smaller libraries to piece together instead. To get going you have to start messing with pyenv (not to be confused with pyvenv which is deprecated), venvs etc. The official tutorials leave much to be desired, lots of newer language features aren't even mentioned, and the docs act like a reference (which is understandable) but a bad learning tool, if you're lucky and not just being pointed to a technical PEP. Like, I know it has a syntax for decorators, but the only mention of that in the official docs I stumbled upon was the syntax definition of the language.

Of all languages I've had to learn in my professional career, Python has been the hardest. Not because it's a hard language, but because I have to hunt for what to actually learn.

I don't mind JavaScript and the expanding functionality of browsers. I do mind that there is no clear separation of "web site" and "web app". When it comes to the later, these new apis are great. But when web sites (ie, primarily documents) start using these features, as a user I feel they almost always make my experience worse.

I hope in the future something like Gemini takes off, so we can stop stepping on each other's feet.

Terrible websites have always existed though. Maybe now there will be new ways to make bad sites, but I can't imagine on the whole the experience of the web will get worse..

People will just not visit sites with a bad experience if they have alternatives. Market forces and all that.

This will likely be a headache for developers more than a problem for end users..

> Nevermind that humanity has experienced a quantum leap in productivity

Hahahahaha, good one!

Houdini is amazing, especially because it does all its work in worklets (not the main thread)

To that I say: Houdini isn’t the enemy here. Some gripes about performance will be had for bad implementations but at the core CSS is still the foundation.

My core problem is that progressive enhancement or graceful degradation[0]

This of course is a symptom of bad industry practice and bad developer habits, that’s where I have a serious issue with our industry.

Houdini though? It’s the right technology for the job IMO

[0]: https://www.w3.org/wiki/Graceful_degradation_versus_progress...

A quantum leap has only very minor effects. Yes we are producing more but are we really productive? And last but not least, the web had positive and negative effects but the web isn't html, css or JavaScript

This is like saying "electricity also had negative effects because it's used for meme-y things like Christmas tree lightning or controversial stuff like Bitcoin mining". Yeah, fine, but literally our entire modern way of life is based on electricity. I wouldn't go as far as saying our entire way of life is based on the Web, but the Web definitely plays a huge role. Even if you want to ignore the Web personally, if you go out to buy bread, the bakery probably ordered the inventory via a website, so thanks to the Web.

And if the Web's application layer is not HTML, CSS or Javascript, then what is it?

The negative side effects of our technology including electricity led to environmental pollution, species extinction and climate change. How this will turn out for mankind is not certain. This could just be the calm before the storm for mankind. And the greatest benefit of the web is not at the user level, but below. Control and measurement signals do not need HTML, TCP and UDP are sufficient. All the APIs also deliver mainly text in the form of Json and the like. Apart from that, the technology may have improved for developers, but as a user the web pages were faster, slimmer, more informative 10-15 years ago. Today there is a lot of click bait and dark patterns. If you are looking for information off the mainstream ( I don't mean news but technical information) the data is mostly hard to find. Much is also simply gone because the links are dead, without Archive.org it would be even worse. "The net doesn't forget"? Bullshit. It forgets many things, but it remembers concert pictures of Beyonce.

And don't forget, this whole web paved the path for mass surveillance. "Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should". This is also true for developers. Have you ever read The Physicists by Friedrich Dürrenmatt?

That's not even really what Houdini is about, it's not true that "CSS has become javascript".

JavaScript is built on some very good ideas and a few very bad ones. -- Douglas Crockford

And the ecosystem even more so.

I’m curious which are the bad ones.

You're in luck cuz he wrote a whole book about it called JavaScript: The Good Parts. It's a good read.

But I don't care about the good parts.

I'm asking about the bad parts.

I guess I should have been more clear that he talks about the bad parts in the book in order to tell you what not to do.

I find automatic type coercion to be the worst one. Everything else is fine.

Javascript's combination of default global scoping and automatic instantiation of variables is another bug bear. It's too easy to unintentionally shadow a variable or in combination with automatic type coercion get bugs that are really hard to track down.

What does javascript have to do with e-commerce? It's not even an essential part of the web. I used noscript for years and only stopped because developers got lazy and stopped doing things properly. Unprecedented quality of life thanks to javascript? Get a grip. It's not even an easy language to learn.

Unprecedented quality of life leaps were possible because of 100% user experience focused websites. The user wants popup menus and other interactive elements, they are objectively, measurably better (check out any UX research website). And Javascript is the way to enable all of that functionality.

To explain it differently: UX is all about minor details that can be the entire difference between a github repo with one star from a buddy and an IPO with fuck you money for everyone involved. So things like "why does the website have to reload completely" are a no-brainer, Javascript is a must.

Note that I personally use 100% Typescript.

Reply on news.ycombinator.com