Hacker News Reader

> JS is the first language to really solve the distribution problem

Excuse me, what? I just spilled my coffee all over the desk.

Care to explain what you mean with the problem and how js "solved" it? In my view dependencies and distribution are terrible in javascript, but maybe we mean different things.

JavaScript is the only language in which you can write a program and distribute to every device in the world, today, cheaply and reliably. (technically this is an exaggeration - not everything has a browser. but you get the point.)

You don't need to write it though. The average Internet building person would be better off writing in a language which isn't terrible, and only using JS as the bytecode of the web.

Maybe. I think of it as an experiment. You may be right. It may also be that the potential of raw javascript hasn't been fully explored. That's my hypothesis. I don't think jquery was the best it could do. Time will tell who is right!

JavaScript won’t go through any revolutionary fundamental change because such a change would break the entire internet.

Believe it or not, some of us have written other "not terrible" languages and actually prefer JavaScript.

I don’t believe it. I refuse to believe that someone can become proficient in a technology which forbids runtime errors and doesn’t bitrot, and then think “you know what, I wish my programs would error more at runtime and also refuse to compile because dependencies changed.”

To want more failure is to be insane. I think rather a lot of programmers think they’ve tried alternatives, but in reality have experimented with syntax swaps of what is essentially the same language.

What language are you referring to? It sounds like you have something very specific in mind, because the usual “not terrible” suspects (Python, Ruby, Rust, Go, etc) don’t have the properties you’re talking about.

Ruby and Python are essentially syntax swaps of the same language. Also not sure how practical it is to write in any of Ruby, Python, Go, or Rust and generate JavaScript.

Elm would be an example of a language which is fundamentally better than JavaScript (and is a practical substitute for what most people are writing JavaScript for), but it isn't the only one.

I’ve been using Elm for over five years on personal projects, but it isn’t a replacement for Javascript as a language, just some client side projects and ones where its async ffi is sufficient.

I think you are falling into a trap of thinking there is a “best” in engineering when that’s basically never the case. Ask experienced developers why they prefer Javascript if you want to get a more nuanced view. I almost always reach for Javascript first, especially for server applications.

I am an experienced developer.

So am I, and yet we hold different opinions about which languages to choose for different purposes.

This article might interest you: https://josephg.com/blog/3-tribes/ (you seem to be tribe 1, I'm probably tribe 3)

I can see why you have come to that opinion, but I would actually put myself immediately into tribe 3.

My code is not poetry; it kinda sucks. I’m not a gifted programmer, which is why I make up for my shortcomings with better tools. I use Haskell entirely for the sake of pragmatism [and have in fact bet my businesses on it]. My experience is such that I can build something that just works much more quickly and reliably in Haskell or Elm than I ever could in PHP or Ruby or JavaScript or Clojure[Script]. And I wrote each of these professionally for years.

That's all and good, but you said you can't believe other people could prefer certain languages. I'm saying that you can simply find them and ask them. And not beginners but veteran engineers.

In other words, there's a simple way to disabuse yourself of your position in this comment: https://news.ycombinator.com/item?id=34257196 -- just ask experienced engineers why they prefer languages that you consider to be irreparable.

How about Java, C/C++, the .NET languages or Rust?

I mentioned Rust, and I left Java and C/C++ out for a reason. Also, none of them have the properties in question (forbids runtime errors and doesn't bitrot).

It's not even clear that a language exists, as we know it, that doesn't bitrot.

> I mentioned Rust

Ah sorry, overlooked that.

I just spent most of the afternoon trying to make a government java program work. It won't apply electronic signatures. I know because it throws 47-line exception tracebacks and does nothing on the UI. Its documentation is for windows xp and windows 7. Yes it is the last version, from mid last year. That's real bitrot.

Related to C pray they didn't hardcode implicitly something of the architecture. Or be surprised when a bad pointer fails in one OS but works in another.

The .net languages are wonderful. The best time I remember in my life was trying to debug what version of the .net runtime was required for a program. So much better than getting laid or going on holiday /s

Compiling to JS doesn't solve the problem because the language (JS) isn't the problem. The problem is the browser and its inadequacy for building applications in many areas - lots of APIs that are not fit for purpose as well as simiarly inadequate protocols.

This environment is additionally hostile to compilation - TypeScript had to bring some really amazing type system features to the table to get most engineers to reluctantly accept the headaches of compilation for the browser.

ES6 Modules, HTTP/2 and sourcemaps were supposed to fix these issues to some extent and all of them created major new headaches instead. Its like there is something fundamentally broken about the browser that we don't fully understand, successfully sabotaging all solutions we come up with.

The JS ecosystem is the furthest ahead in making this broken environment barely usable with a bunch of hacks to compensate for its shortcomings - a new language will need to fight hard to get close.

I love Typescript

It is not always aspects of stability that are most important. I prefer js because it might be the fastest language to get an MVP out the door, among other things.

I think the economic argument you're making is the most sensible one, and it's going to be highly context dependent. Personally, I subscribe to the idiom that nothing is more permanent than a temporary solution.

I'm trying not to sound all gatekeep-y, but I think this is the downside of a low barrier to entry. JavaScript has attracted a lot of programmers who just don't have the experience to manage things like maintainability, dependency management, or non-breaking upgrades. Some of them go on to create things that are great in the moment and deservedly become popular, but then fall prey to problems in these areas as they age. The same has happened to various extents and at various times with Python, Ruby, PHP, and so on.

On balance lower barrier to entry is a good thing, but it does have characteristic problems too. In fact, I'd say fault lies partly with more experienced programmers and particularly packagers, who often tend toward avoidance (or worse) instead of helping these newer ecosystems avoid known pitfalls.

I really don't like PLs that's optimized for beginners because I believes they are not in "beginner" phase for that long (probably a few months), and often time the PL trades that with downside that developers have to live with in next 10 years+. The selling point I'd like to see is not "beginner friendly" but median developers friendly.

Nicely put.

But what is this "build-less front-end" you speak of? Surely there's build somewhere, you're just hiding it?

The browser itself performs a kind of build step. It happens per script tag, and you can catch "compilation errors" in your own code using window.onerror if you want to.

Surely you must use JavaScript libraries in your front end though ... don't they need compilation?

Believe it or not, using libraries, compiled or otherwise, is not a requirement of either the HTML or Javascript specifications! The single biggest benefit of front-end builds is modularization; however browsers support that natively now (e.g. script type=module), and have for some years.

>> using libraries, compiled or otherwise, is not a requirement of either the HTML or Javascript specifications

But no substantial modern application can possibly be built without them.

I can see that using modules could avoid the need for compilation.

>no substantial modern application can possibly be built without them.

That's certainly false, since substantial applications predate React, Angular, svelte, etc.

But you have a point. Steve Yegge once wrote that his company wanted to write a word processor in assembly and it seemed like a good idea at first, but then it was like drawing a straight line 100m long using only 2mm line-segments. The major purpose of these libraries is to increase the "length of the line-segments" to something more consistent with the distance you want to cover. The question is whether or not their exists a unit of abstraction in raw js/html that serves this same purpose. E.g. it's a demonstration proof.

Working on it.

> no substantial modern application can possibly be built without them

Check out Firefox.

Plain foo.js file. Included in the web page. That's it. No compilation, uglify, translation, crap. Plain file, straight from your scm.

No build frontend dev is a thing, although obscure.

Preact has a no build path in their documentation: https://preactjs.com/guide/v10/getting-started/#no-build-too...

And here’s my no build react setup: https://github.com/jsebrech/create-react-app-zero

You can "do the build step" before deploying it to the CDN, kinda like how skypack esm modules work: https://www.skypack.dev/view/luxon

Of course, unless you do it tailored for your project, you don't get some nice features like tree shaking, but it's very convenient.

> and to some degree it's design (or lack thereof) reflects the trade-offs required to hit the distribution problem out of the park.

How so? The first part I agree (as pure accident and the fact is thing bundled on the browser) but JS/C share the same problem: Terrible "design", ill-suited to the task, but sadly what was bundled.

And resistance to fix them (where in the case of JS could be super-mega-easy).

To switch from JS to TS I’m willing to give up absolutely anything. I’d do five minute build times per small source file to do TS.

TS is probably as good as transpilers get. It really is quite good. I like that it maps one ts file into one js file and creates readable code (although output is normally bundled so readability is lost). I like that ts aids dev discovery in tools (intellisense) at write-time. But ts still needs a build step, and that's a big down-side to the immediacy of "plain" javascript.

If browser vendors bundled tsc or its equivalent then we'd both be stoked.

> If browser vendors bundled tsc or its equivalent then we'd both be stoked.

Not exactly this, but there was a proposal that would allow for typescript type hints to be considered as normal JS syntax: (in the same way python PEP 484 – Type Hints are considered optional type hints)

https://github.com/tc39/proposal-type-annotations

Deno on the server side is pretty cool and uses https://swc.rs/ (Speedy Web Compiler) - doesn't take forever to start, but kinda implements typescript as if it was just a type annotations without the more in-depth actual type checking, so it is possible.

Having a build step is our only hope of being able to extend and customize the language.