Hacker News Reader

Given that we're not dumping JS anytime soon, I think that the shortcomings of JS are kind of moot.

Once you accept that 1) JS and the ecosystem has a ton of shortcomings, 2) JS isn't going to be replaced on the web for front-end for a while, then I think you can move on and think about things more objectively.

I like this project because at this point in 2024, it feels like it should be easier to build and deploy cross platform web/mobile apps (I blame Apple for PWA not taking off). React is not my cup of tea, but if One's mission pans out, then I'd use it to streamline my workflow if I were building across web and mobile.

I'd personally prefer PWAs and Apple making it easier to install PWAs as apps since that would make it even easier and more streamlined from a DX perspective. Right now, we all have to jump through these hoops and build this extraneous tooling and infrastructure because of Apple's resistance on installable web apps.

Nobody said "dump Javascript", and that clearly isn't what I meant [1]. I put that part in only to illustrate that these problems were knowable at the time that Meteor was created.

What I am saying is that the paradigms of "modern" front-end development are all wrong. Don't re-invent basic functionalities of the browser. Don't try to turn the web server connection into a glorified database (either by implementing bastardized HTTP-SQL, or by treating the socket as a bidirectional JSON channel). Accept that server-side generation of HTML is fundamental to the medium. Embrace progressive enhancement. I could go on.

None of these things requires that you drop JS as your language. If you wanted to build Rails in JS, you totally could [2].

If I had to draw a crude metaphor, the state of web development today would be as if an entirely new generation of engineers decided that TCP was wrong because most stacks are implemented in C, and therefore re-created bad versions of handshakes, etc. by writing a new protocol on top of UDP in Javascript. It's not the language, it's the architecture.

[1] Though you absolutely should consider that JS isn't perhaps isn't a great language for most forms of development, and be open to, you know...using better tools when they're available, instead of trying to do everything in the lowest common denominator, while patching over all of the stuff you're missing with gobs and gobs of bad libraries.

[2] Though again, why would you want to? I submit that the core cognitive dissonance here is that as soon as you accept that these "modern" paradigms are wrong, you quickly conclude that Javascript is a net burden on your development process. But sure, if you really like it for some reason, then great. You can use it.

I'm not a web dev, but I see a conflict between server-side HTML generation and a local-first application. ;)

I think there's 2 distinct use cases here: a) a classic "web-site" that people "visit", interact with and leave b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state

Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there. I'd aim at 100 ms page loading time (without initial network delay).

Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top". This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps.

And about people re-implementing TCP: I first thought you referred to QUIC. Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).

You're correct about the two use cases. The problem is that too many websites/developers think they are case b) while they really are case a)

> as if an entirely new generation of engineers decided that TCP was wrong because most stacks are implemented in C, and therefore re-created bad versions of handshakes, etc. by writing a new protocol on top of UDP in Javascript

WebSockets would like a word

100% honest as someone who loved Rails - i really love building with react and tamagui if you put together the right tooling.

95% of apps people glue together are quite bad so i get that some people see it as a lost cause, but i could never go back, it's clearly better to me but only if you do manage to have the time to put together a great stack.

once zero is released i'd be interested to see your opinion of trying it out.

To play devil’s/react-dev’s advocate: the appeal of local-first is that you can easily configure which business logic you want done on the server, leaving anything that can be done on the client to the client for latency and cloud bill reasons.

  javascript lacked (lacks?) even the basics of a practical programming language -- real packages and the like

Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else? Like, splitting up your code into packages gets you some performance benefit in other languages? I have python packages (read: __init__.py files) in my Flask app, but I’m not sure I’ve ever missed them in TS - am I missing some big picture? In general web bundling is so complex I tend to treat it as a black box, so that could easily be on me.

  you're re-inventing wheels (like routing, rendering, a request/response paradigm) that the browser does for you, for free.

I’m having trouble seeing what you mean here. I know the typical “implementing an SPA is tough because you have to fake pathname manipulation/history” warnings, but I think you’re going a step beyond that. React does rendering on a way more performant level than browsers if you’re just changing subsets of the DOM, and I’m really not sure what you mean by the “request/response” paradigm at all, sorry. SPAs do have to handle async requests on the client and normal websites make the server do that when building the page, but ultimately the difference seems slight. What am I missing?

  for the vast majority of CRUD websites

I mean, do people making crud websites really need any frameworks, and do they browse hacker news? Aren’t static sites a pretty solved problem by people like WordPress? Seems like the hard part of that would just be writing content and filling templates, maybe some styling — not any engineering work.

Agree with you pushing back on the TS hate. The ecosystem and tooling have gotten very mature and very productive IMO for building UIs.

However, static sites are by definition not CRUD sites and yes I would guess most HN web devs make CRUD sites. And I would submit that in 2024 there is still not a rails-level happy path for doing that in ts (though Redwood is trying).

> Interesting. As a typescript user with a million npm packages this surprises me. In the sense of “managed dependencies” JS/TS has tons of packages, but I’m getting the sense that you mean something else?

The very fact that you cite Typescript (itself a hack built on top of Javascript to make up for its deficiencies), and npm (a third-party packaging system...since, you know...JS doesn't/didn't have one), is just emphasizing my point.

Setting aside the goodness or badness of either of these things, you're so immersed in the complexity of all of the hacks that you don't even see it anymore. It's the old joke about the fish and water.

Imagine a world where packages and types were a built-in, first-class feature of the language...oh wait.

What language has a built in dependency system…? How would that even work? I’m confused. Every dependency system is a registry of dependencies vetted by some group, along with one or more compilers/runtimes that know how to speak that group’s format. Who cares if the group is GitHub (TIL… ew, tbf) vs. the language nonprofit itself?

Also, more importantly by far: can you point me to what language(s) you’re talking about? C++ doesn’t seem to have a “built in” dependency manager, just vcpkg and Conan. Python has poetry, anaconda, and pip, the latter of which is run by the Python nonprofit — but something tells me that’s not the old school classic you’re referencing lol. Java has ant, gradle, and Maven, none of which seem official. I guess we’re talking about ruby, since their manager is published by a group that claims ownership of the language (https://rubycentral.org/)?

Basically I’m still not sure what im missing. I very much might be a fish in water, and I am a newbie to all of this, relatively! But I’ve never once noticed a real difference in the languages I’ve developed in professionally (those mentioned above, minus ruby) so I’m not sure what ruby’s being more “first-class” gets me. At a certain point, if your build system is setup using boilerplate, then the two steps are 1. Download package, 2. Import package into relevant file and start calling its members. What part of that can be improved?

> What language has a built in dependency system…?

Literally every language with support for modules that extend across files has some form of dependency management. Even C -- simple as it is -- has headers and source files which separate interface from implementation. Some languages go further (e.g. Ruby), and have far more developed, standard systems of version management built right in -- rubygems will do the graph analysis of your module includes, resolve dependency cycles, enforce versioning, and so on. Python is a total mess when it comes to high-level dependency management, but only because it offers 3-4 different "standard" ways of doing it!

Notably, Javascript didn't even have the the export or import keywords until ES6 (2015). It had literally no support for even the primitive, C-like version of the idea, and there were multiple competing implementations of it, from Node, to CommonJS, to RequireJS, Webpack, Babel and so on. But you still can't get rid of webpack, though -- JS has no built-in notion of minification or tree pruning, so that's all still implemented via a panoply of third-party tools.