antris

I've learned ages ago that parseInt cannot be used like this, so it's not a problem for me, but I thought linters already take care of this case? Also I wasn't talking about using parseInt, a broken function like this so I'm not sure what the quirks of old, widely known bad parts of Javascript have to do with using functions as arguments, which is one of the most powerful features of the language.

Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.

In addition to negative index support, a function is more easily composable e.g. converting a list of indices to a list of objects: `indices.map(myObjectArr.at)`

I've lost count on how many times I've wrote this function manually.

You could replace nazis with any group of people with a specific message that they want to spam all day, every day and it would still be a horrible decision to let them roam free in every public forum. Whichever the group is, not ALL forums on the internet should be about the grievances of that one group. Though, it just happens that nazis are the ones who seem to be the quickest and most common group to take over forums. This is because they need an audience for their crap, and on every forum either the nazis get kicked out or their audience leaves. I never mentioned any real world consequences (although they definitely exist too), but even if you purely talk about discussion quality and ability for people of different kinds to participate, you usually have to be kicking some nazis out eventually, because they tend to become as overbearing of a voice as the moderation lets them.

Sure, nobody likes political correctness but without any controls on content on a public forum as a part of a ToS, nazis and other people who are desperate to express their hate, and even break the law and recruit others will eventually find it and spam the hell out of it. 4chan is a perfect example of what happens to an actually occasionally funny place that allows any kind of discussion "just for lulz". It's been a cesspool and barely anyone remembers how it was before the nazis came in. It's just how it works when the forum is public and there's no moderation. If you want good discussion without limits, I suggest joining smaller communities that are harder to flood in this way, or talk to people you know in real life.

Now that you mention pasting things into #django-dev, one thing that stuck with me was https://dpaste.com/

I think it was more closely branded as a "paste service for django community to use" than it is now, but I keep using it because it just works perfectly, without any captchas, ads, complicated UIs or other unnecessary fluff, the domain name is easy to remember and it's been up every time since around 2007 when I discovered it. Just paste, submit and share the link, and it always works as you expect.

As there's many threads relating to the controversy surrounding Freenode, I guess everything about it has been already said.

It's sad to see it crash and burn this way. I have fond memories of freenode, and especially the #django-dev channel. Before Discord or Slack existed, I remember as a relative newcomer to web development frameworks, it was an invaluable resource to me. This was a time when I think Django 0.96 was being prepared for release.

I always got some help for my newbie questions and especially the core contributors were both tremendously helpful and exceptionally polite and friendly towards me every single time.

I haven't used Django in years, not because the framework isn't good, but because my career just took a turn elsewhere. The fundamental attitude and professionalism of the Django community was rock solid and from what I hear nothing has changed.

Here's to memories of Freenode and for the bright future of Django and Libera!

Yeah, and digital camera manufacturers aren't adding megapixels for nothing and processor makers don't chase higher clock speeds for nothing, right? Because why would they keep adding pixels and increasing the clock frequency just to make the tech numbers look more impressive in order to sell more electronics? Yes, sounds pretty ridiculous.

Now of course, maybe the new retina screens appear slightly sharper if you have exceptionally good eyesight, but I have long ago stopped seeing any improvement in sharpness of smart phone displays. The screens do look better in terms of better colours, contrast etc, but at a typical distance with an individual with normal eyesight, adding more pixels does pretty much nothing at this point.

When the pixels are so dense, that using the monitor at its typical viewing distance makes pixels indistinguishable. But not just in the sense that you cannot see that your view is pixelated, rather in the sense that packing the pixels any denser wouldn't make a difference.

Quality desktop monitors viewed at their typical distance do not look pixelated, e.g. you rarely are able to see individual pixels especially if proper antialiasing is used, but they do still almost always have a lack of sharpness that could be corrected with a denser display.

On retina smartphones, making the pixels denser wouldn't make the image look any sharper from a typical viewing distance. Once you achieve that, I'd say it's "retina-grade".

>the rest of the world to learn one standard system/language than to have every app/product/document adapted to every single language/script/whatever in existence

But they don't. That's precisely why the text input handling is so difficult, because it has to solve it for all apps. How many apps have you worked on that has had to create their own text input system from scratch? I think for most developers that's zero.

Like the article said in the end:

>The necessary complexity here is immense, and this post only scratches the very surface of it. If anything, it's a miracle of the simplicity of modern programming that we're able to just slap down a <textarea> on a web page and instantly provide a text input for every internet user around the globe.

I don't know where this Apple dig is coming from. Most applications are just putting a bunch of strings into database and displaying strings from a database. This has always been the case with or without Apple, and it works the same way regardless of platform.

Are you not aware that just because a certain piece of content doesn't suit you at this moment, doesn't mean that the content is bad?

In addition to yourself, there are other people in other situations who are looking for different kinds of content.

Then you serve the ads on the same set of elements that also contain critical content to the user. You can't block ads from Twitch / YouTube with a rule if the ads are baked into the stream itself. Same goes for any other kind of "element" that doesn't explicitly set itself apart from the actual content.

The ads have long ago started evolving away from a simple "here's an ad neatly placed into its own semantic container so that blockers can target it".

The non-profit can still have rules in place on who is accepted as members and who isn't, as long as the rules don't break any laws (discrimination etc.). They also can have a mission statement and rules that are not up for vote. They can have members enter a contract with the non-profit when joining as a member.

Also, depending on who's "taking over" and who's "taken over", it can be argued that if the majority of members that provide the majority of the funding to the non-profit, shaping the non-profit according to the majority of its members is the right thing to do. If there's too much differences in opinion, the non-profit can also split any time.

I already told you what I did and several developers did before React to combat the same problems the React addressed, but somehow you seem to dismiss all of it. If you don't want to believe it, that's fine. I know what kind of code I wrote before React, your ramblings won't change it. Have a good day.

>You probably could, but did you? Oh, wait, you didn't. The hot tech du jour when React was released were knockout.js and backbone.js.

I did. It's kind of funny to hear that you cannot even entertain the idea that people actually did declarative UIs before React with plain old vanilla JS, because that was my bread and butter back in the day. That's precisely how I did frontend until React came along, and so did many others. We sometimes sprinkled in some CoffeeScript to get nicer function syntax, before () => {} and babel existed, but it wasn't necessary if we wanted to avoid a compile step.

Just because some frameworks were prevalent at the time didn't mean that everyone used them. Large portion of seasoned developers rejected all frameworks and still do today. They had shot themselves in the foot with MVC/"trying to do everything" -frameworks enough times to learn that not all answers come from a single framework that encompasses your whole application. This is nothing new or esoteric, and still today a good lesson to learn for new developers. Instead many people continue to use "the standard" framework, fighting against it when it fails to fit the domain logic of their app, and waiting for a new framework to arrive to save the day. Frameworks have gotten much more flexible about this today, but React wasn't anything revolutionary on the framework side of things.

It's not as simple as "React bad/React good". A framework/library can be good in certain aspects and bad in others. I loved React when it came out, because of the VDOM. Wasn't a fan of everything else though, and especially not a fan of how it was used as "the new standard framework to tightly couple your application into". This is not a contradiction, it's just non black-and-white thinking.

If you judge technologies based on a single anecdote you've heard on the internet then I don't think this conversation serves any purpose. I don't know what bone you have to pick with any technology other than React, but achieving declarative DOM manipulation pre-React was as simple as `(state) => $('<div>').innerText(state.message)` with the plain old jQuery. That was definitely easier than learning React, and by building a component structure with vanilla javascript functions, you could have all the functionality and expressiveness of JSX without a compile step or external libraries.

Of course this would cause problems that I've described in this thread before (scroll/form state resets, performance problems etc.), so the VDOM was the missing piece of the puzzle. Overall the concept of declarative UI was incredibly simple and predated React, but the VDOM was a great thing that solved the problems people were having with declarative DOM manipulation. If React had shipped just with the VDOM implementation, it wouldn't have needed to expand into a full-fledged framework and introduce a bunch of band-aids on top it. React deservedly skyrocketed, and the VDOM was an incredible thing to introduce at the time, but every part of React is quickly becoming outdated as more FP concepts from the past are introduced into the mainstream.

So all in all, React shaked things up in a good way, and finally people are ready to move on to make their apps actually reactive and taking a serious look on things that have been "academic" before.

Well that's why said

> React made a huge impact on web dev and deservingly so

The VDOM was revolutionary, no question about it. The comment I was replying to didn't even mention it.

Then I stand corrected. :) Maybe I wasn't looking hard enough earlier.

It was novel because you couldn't refresh the whole DOM based on your application state without user experience suffering, before VDOM diffing came along.

One these problems usually:

- application is in one state and the UI is in another state

- jQuery operations mutating the DOM causing weird edge cases after several user interactions

- the template language (handlebars, mustache etc.) was getting in the way because it lacked the expressivity of javascript

- application state was split all over the place between Models, Views and Controllers. instead, if you put as much state as possible in a single place in your application, it's much easier to just create declarative functions that take in an immutable state and output a DOM node object: `(state object) => DOMNode`

Right now I'd use React only for projects that require it as legacy or as a part of a framework. If you want to get things done quick, Next.js is pretty good framework for greenfield projects that uses React under the hood and I don't mind it being there too much. But similar things to React can be achieved with Svelte or Lit without having to ship and manage a VDOM implementation or JSX with its quirks (e.g. className).

So in summary, I'd stay away from all features of React other than VDOM, and even skip that if possible. And as a general rule, don't use any frameworks unless you can say why your project specifically really needs it. Surprisingly much can be done with basic HTML, JS and CSS. People who say "just use X" are trying to force simple answers to a field that is inherently complex and needs good judgment on which tools to use and when not to use them.

I suppose. It just feels weird that the post was highlighting hooks and context, while VDOM was omitted. VDOM was easily the biggest thing in my opinion. I had never seen anything like it and it worked wonderfully. It's not to say that everything else in React is bad, it's more like everything else pales in comparison to how huge VDOM was when it was introduced.

Kinda like hyping iPhones innovation without ever mentioning touch screens.

100% true.

But I'm not even talking about academic really. There were plenty of people who didn't buy into the "MVC/jQuery/templates" thing, and we were writing apps into production for actual customers. I've never been taught academically, but I realized that writing my DOM operations as declaratively as possible made my code much easier to maintain. So I started creating and updating my DOM in JS way before React, when it was considered "heresy" by people who didn't know better. And there were plenty of programmers like me, who never got academically trained or looking up category theory. They had just shot themselves in the foot with the silly MVC stuff too many times to care anymore about what other programmers think.

For me, and people like me React was a GODSEND. We started immediately hyping it, but there was huge resistance early on to adopt it. React was a great improvement from the status quo. But then later on we realized that people started using it as a framework just like they had with "templates+jquery+backbone+whatever" and although the DOM things are a bit easier now, many people don't understand any better why or how React is good and when it's bad to use...

As I said, the VDOM was novel. However, unidirectional data flow, lenses and FRP with RxJs all predate React. There was also Elm which was a full framework that was based on these concepts, and ClojureScript with its whole ecosystem that did things a bit differently. Though most people who do utilise functional programming concepts prefer not to use a framework but pick-and-choose libraries that do the job for that specific project. That means that the field was (and is) very scattered, and there's no single "React but better and made earlier". Because React is a unique combination of tools. But each of those tools have been done in one form or another many times, except for the VDOM, which I believe was novel.

On another note, a React component in FP is just any regular old JS function with a signature: `(state) => HTML string`. React is such a simple concept that it wouldn't have needed any sort of library, if it weren't for the performance and DOM reset issues.

Svelte does reactive UI without a VDOM at all. Every DOM operation flows from declarative instructions based on the state of the application, without a need for VDOM or hooks.

The compiler is quite mature and used by countless apps in production right now.

https://svelte.dev/

I've been using it myself and it doesn't feel academic at all. The Svelte Kit toolkit, a successor to the Sapper frameworks is also ready to use but it's not 1.0 yet so might be a bit unstable. But if you're worried about having to figure things out then you can use Sapper+Svelte or just Svelte just fine, and they're very robust and well documented.

State and DOM being mutated all over the code base was the norm before React. In many apps, state was a thing that was spread out all over the code and could be mutated by any part of the code. And a DOM was another global state on top of that, that had to be kept in sync with the data of the application. Otherwise users would be shown a state that wasn't representative of the actual state of the application. People did this with careful DOM modification code, trying to always remember to set, reset add and delete DOM nodes correctly. Of course, this caused many bugs and sometimes huge performance issues.

If you tried to solve this problem by redrawing the DOM every time your app state changed somewhere in the code, the browser would freeze and all your form elements would be defocused on every update, scroll states would be reset etc. etc.

React solved this by the diff algorithm and doing surgical updates of the dom based on the components state. It does this by manually reading the state, keeping a virtual DOM in its memory and doing diff calculations.

But if your whole app is reactive by design, there's no need to read the app state, doing diffing or figuring out which DOM node to update which one not to update. The DOM update operations flow naturally by the declarations given by the programmer. Frameworks such as Svelte are moving into this direction and they're already seeing quite significant performance improvements compared to VDOM implementations.

>Well, isn't there something a little "revolutionary" about mainstream adoption of cutting-edge techniques?

Taking the example of hooks, React has hooks because it was released with a bunch other stuff in addition to the VDOM, people started using those things as a (poor) framework, shot themselves in the foot repeatedly and finally hooks had to be introduced as a fix on top of that.

Calling that band-aid "revolutionary" or cutting edge technology, kind of sounds wrong. They never would have been there and wouldn't have been needed if it weren't for the bloated original release.

But of course, even if that band-aid makes people think differently about building apps, it's all good. That's why I mentioned in the post that it's a great thing. But calling it "revolutionary" when a large fraction of programmers have been doing it that way for ages is a bit of a stretch.

Yes, yes and yes. All of these concepts are variations of what has been done before in a number of ways. Mostly by "FP academics" who "live in fantasy land", until everyone else starts using them too.

Transpiling, hooks and components have all been done (and done better) before React came along, but often they were laughed out as esoteric toys that have nothing to with "real programming". It's just hard to teach these concepts until you actually use them, and it's hard to get people to use these concepts unless they are included in something else that you need.

The same happened early with React, both JSX and VDOM were laughed at by many developers because "they looked stupid" to people who didn't understand them and were used to one way of doing things. MVC+jQuery+templates was the flavour of the day.

Same thing with TypeScript, FRP and so on.

Most likely, whatever concept is gaining momentum today, it's an exact or approximate copy, or in rare cases a novel remix of what has been researched 10-20 years ago, and used in production for 5 years before you heard about it on HN

These people who like to apply category theory etc. in programming have heard this mocking of their work as stupid esoteric fantasy (and then seeing them become mainstream later) so often that they literally called one of their specs "Fantasy Land" https://github.com/fantasyland/fantasy-land

There's still lot of work to be done. JavaScript doesn't even have proper immutable data structures natively, which would be a REAL low hanging fruit.

>In my opinion, React made a revolution with hooks and contexts

I agree with your overall point 100%, but to be honest nothing in React was / is innovative except for the virtual DOM diffing, but even that is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture. React made a huge impact on web dev and deservingly so, but all of the other ideas have been implemented and used on the web before.

Of course it's great that React is bringing some of these good ideas to mainstream, but they've been there way before they have been distributed along with a VDOM algo.

The point was that relying on marketing messages causes the user having to research themselves what the product is actually good at and what it isn't good at and wasting time because the company isn't upfront the products strengths and weaknesses. The product might be sufficient in the end, but marketing will very rarely tell you what the product is actually sufficient at and what it is not.

The statement wasn't about whether the product is actually good or not, though in extreme cases, yes, the product is worthless while the marketing is all rainbows and sunshine. But relying on marketing is bad for the user in nearly every case, even if the product is good.

And even if you are "one of the good guys", your users won't know that. That's why you should verify from independent sources, or do your own research.

If marketing was really a reliable source of information, reviews, samples, product trials etc. wouldn't be a thing.