Hacker News Reader

Comment by randomsearch | Hacker News Reader

This is my experience of web development, every time I return to it.

I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.

JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.

If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here.

It also feels that many web ecosystems have an over-inflated sense of self-importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions.

I need to build a website soon and I’m dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I’ve got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. “Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life” would be my favourite O’Reilly of all time.

View on HN

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful

Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, focused on pragmatism) would be right up your alley.

If you're ok with a dynamic language (i.e. strike rigour), then look no further than Clojurescript [3], Clojure's [4] little web brother. An elegant and simple Lisp, it makes almost all other dynamic languages completely obsolete.

There most definitely are sane options for developing for the web if one is willing to use a compile-to-js language.

[0] http://elm-lang.org

[1] http://www.purescript.org

[2] https://reasonml.github.io

[3] https://clojurescript.org

[4] https://clojure.org

That's incredibly high praise for Clojurescript. It's got some great features but it has flaws, too. I feel like many people new to web dev would be more confused setting up a Clojurescript project than they would be with JS. It was a lot of googling when I did it a couple weeks ago, and that's coming from someone who has done several times over the years (what's this boot thing, I was told lein was the best thing ever?).

Those are all great languages. It is important to realize that they will increase bundle sizes, which is a common rant about web pages these days. Hello world in Bucklescript/Reason, for example, is 23 KB (anything touching the std lib at least), Elm much bigger than that. My friend's 500 line Clojurescript/Reagant app was over 500 KB uncompressed, 5k lines of JS will come in at 140 KB.

It's worth being aware of the tradeoffs you are making, because often when people are selling new tech they tend to overstate advantages and understate disadvantages.

> It is important to realize that they will increase bundle sizes

Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript.

That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.)

I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.

And for non-functional languages?

Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing.

[rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing functional programming everywhere is IMO just insanity and everybody is silent about many warts and weirdness of purely functional programming. [/rant]

Elm is the opposite. From this article:

https://medium.com/@eeue56/why-type-classes-arent-important-...

"Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right."

And

"Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses, but it is less likely that they are than Haskell developers. Alternatives like Purescript provide more abstractions and powerful type systems suited to those from the Haskell community. There are many of us Haskell users who sit happily with Elm too."

Elm favors simplicity and pragmatism over academic FP lingo. You need to change your way of thinking a bit, true, but it benefits the architecture. And it'll take weeks, not years!

You will not find the words "monad" or "category theory" or "algebraic datatype" used in the Elm docs.

Thanks! Do you know any good (Udemy?) course in Elm that won't take too much time and gets into important parts quickly and thoroughly?

I don't get why you need udemy course. Just read official tutorial with open sandbox/project.

maybe this? https://pragmaticstudio.com/courses/elm

The guide is probably the best resource to get started: https://guide.elm-lang.org/ It introduces you to the language as well as the concepts / architecture.

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect programmers could have discovered them -- after all they are (simplifying a bit) merely a way of generalising composition.

Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good imperative languages. They don't force you to go purely functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned ML-variants are (slightly) better general-purpose imperative languages than the Javas, Pythons, PHPs and Javascripts of this world, because they are more consistent, they have types/type-inference, and their statefulness fully supports higher-order state and powerful modularisation without restriction, not to mention pattern matching.

Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional programming) is another benefit of Scala and ML-variants.

Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more.

The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.

Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.

> Debugging is one of the biggest problems with FP

I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.

I guess if you start using nth-order functional compositions and everything is a recursion, it's super difficult to figure out what is going on from e.g. stack traces or just simple log statements. And often FP programs are more-less solutions to "puzzles" and to understand the solution you need to keep that "puzzle" on mind. Now what are you doing if you have multiple levels of "puzzles" at the same time and you need to connect two separate subsystems via some deep-level information exchange, given there are no mutable variables/singletons for you? I am sure anyone taking FP seriously hits this kind of problems regularly and they often take long time to come up with satisfactory pure implementations.

Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e:

    do
       x <- newIORef 0
       writeIORef x 2
       print =<< readIORef x

will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints.

[0] https://en.wikipedia.org/wiki/Software_transactional_memory

For F#, is it a debugger designed for F# or just good integration with VS’s .net debugger? If the latter, I should mention that the problem remains even when using C# if your code gets too functional (e.g. getting rid of some LINQ for debuggability is a common trade off).

Indeed there are some quirks in VS 2015 even in C#, like writing a function as a generator isn't as pleasant as it could be. Haven't tried VS 2017 yet. I think we're a little spoiled on .NET though, we've forgotten how bad debugging is in other languages!

Interesting. Where do you hear that? What I've heard (and experienced) is that Haskell makes is easy to come back and understand code written a long time ago (because the language allows one to structure code very clearly).

I'm not a historian. It's certainly true that monads or monad-like things where discovered independently in many context. This isn't even surprising, given how natural, and trivial in a sense monads are. But the systematics realisation of the concept and its wide applicability comes from algebra and the efforts to recover algebra categorically. Let me quote from Wadler's [1]:

The notion of monad comes from category theory [...] It first arose in the area of homological algebra, but later was recognised (due to the work of Kleisli and of Eilenberg and Moore) to have much wider applications. Its importance emerged slowly: in early days, it was not even given a proper name, but called simply a "standard construction" or a "triple" [...] Eugenio Moggi proposed that monads provide a useful structuring tool for denotational semantics [...] He showed how lambda calculus could be given call-by-value and call-by-name semantics in an arbitrary monad, and how monads could encapsulate a wide variety of programming language features such as state, exception handling, and continuations. Independent of Moggi, but at about the same time, Michael Spivey proposed that monads provide a useful structuring tool for exception handling in pure functional languages, and demonstrated this thesis with an elegant program for term rewriting [...]. He showed how monads could treat exceptions [...] and non-deterministic choice [...] in a common framework.

[1] P. Wadler, The essence of functional programming.

Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.

It's not that bad.

I've been learning Elixir (a functional language) for a new project I'm working on and even with only being able to allocate 20-30 minutes a day on it, I don't feel like I need to relearn everything. This is with no prior functional language experience, just a bunch of general experience with Python and Ruby.

I have no formal CS education and while I've heard the terms category theory and monads before I have no idea what they are. In my mind, monads are some Haskell related meme and category theory is thinking about whether or not to use categories on a blog engine.

I found Elixir to be curiously easy to adapt to. I spent like 15 minutes glancing Elixir's documentation and now I'm running a Phoenix based web app (somewhat comparable to Rails but not really) following an "error based development" work flow.

This is where you try to do something, completely fail at it, look up the answer and figure out how to apply it. I don't even know how most of Elixir / Phoenix works yet I'm able to accomplish real things.

After spending 15 minutes reading Phoenix's docs on routing, I actually feel like I understand Phoenix's routing system better than other frameworks in different languages that I've worked with for years. This is partly because it's so easy to just trace a function call back to another function call and understand what's going on (plus their docs are badass).

> And for non-functional languages?

I would recommend Typescript then.

> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.

True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.

> I would recommend Typescript then.

Funny, all people using Typescript I know use it in functional way (computer vision/AR in a browser).

If you want an imperative and statically typed language, try Kotlin: https://kotlinlang.org/

...which targets JavaScript in addition to the JVM (and being an officially supported language for Android development): https://kotlinlang.org/docs/reference/js-overview.html

Immutable dats structures in CLJS pairs well with react type frameworks. Trying to make js pretend it supports immutable structures is what turned me off the most about react/js

I ended up going with vue which uses mutations instead of having to return structure copied from functions.

Just made more sense to me. Maybe MobX does this for react? Idk

I would argue that web development have never been as easy as it is now and that a lot of people just does not take it seriously enough to bother to learn it properly. People think that just because that they did some jQuery development 10 years ago they should be able to use to the same skills now and discard all new developments.

Being able to use modern JavaScript and with linting/prettier will in practice make it pretty rare that you end up doing stupid things due to language limitations. And if you want types you have TypeScript that works very well in most work flows.

html/css is pretty ok to work with these days and libraries like React and that echo system makes it pretty easy to scale web development so that many people can be involved in the same code base.

The nice thing about the current situation is, if you want to you can still use jQuery, basic CSS & HTML5 and ECMA sub version 6 for 99% of all sites that exist and are likely to exist. That will remain true for the next decade at least.

Most sites are not applications and never will be. Most businesses will never need a complicated site. Most of the Web has zero beneficial use for React or ECMA 6. Factually that's easily demonstrated just by looking at data compilations of what the Web largely consists of: static content, typically pushed out into the world via a basic CMS. That isn't going to change. Most of what's going on is an evolution in the top tiers, up the value chain. Facebook & Co have dramatically greater technology demands than Joe Small Business or Susan the blogger.

Easy? No, I believe it's very hard to setup a frontend project.

1. install node.js 2. npm install create-react-app 3. create-react-app your-app 4. npm start

Now you have a react app with a development up and running. To create a production build write "npm run build". To add a package write "npm install the-package".

It's just as easy as it always was. Put a script tag pointing to your favorite tool in a blank html page, and get going.

Oh, you mean setting up a state of the art web application? Years ago we had to roll our own pipeline, often building our own bundler and you had to use a ton of separate tools not meant to work together. There was no package manager so we had to download all of the stricts from random websites and hope for the best sticking them in a /vendor folder.

Nowaway you use the CLI of your favorite framework, type 1 command and you have an app all configured for a real world production environment. It's never been easier (and is easier than pretty much any other type of software development).

The only thing that changed is that since its so easy, you are expected to produce a high quality app if you want to be taken seriously. That part is hard.

It's incredibly easy, given that every major framework has a cli that does it all for you.

> I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.

It is, but it's getting better because so many different approaches have been tried that some of the more scalable and maintainable ones have been worked out. Also, (thank heavens) browser support is a lot more consistent now.

> I need to build a website soon and I’m dreading the front end.

If you're a software developer, I recommend some atomic/functional CSS toolkit, like Tachyons. That will free you from having to do probably 90% of the CSS work you used to have to do, and it matches a more programmer-type mindset to styling elements.

I'm building a site now, and so far it I've just needed to define some style classes for the colours, and the rest of the styling is already included out of the box via their reusable classes.

For the JS side, really depends what sort of dynamism you're looking for. You can go with a tiny JS library for polyfilling and standardizing browser behaviour [1] if you're just doing simple DOM manipulations, or if you expect to be doing a lot of AJAX with dynamic rendering, go with something like Surplus [2], or Vue, React or Mithril if you want something more standard.

[1] https://github.com/naasking/PithyDOM

[2] https://github.com/adamhaile/surplus

I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?

Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.

TypeScript has previously been recommended, so I will take a look.

I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.

WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.

> WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically.

How come?

It's too simple to support dynamic language features AFAIK.

So are machine instructions. It wouldn't be any harder to build a dynamic language runtime on web assembly than for regular assembly.

I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.

If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.

There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used.

I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.

Yeah I mean, many compile-to-JS languages have pretty good ecosystems (I know Elm is one, and I believe you that ClojureScript is too), but it's always going to be a pain in the ass at some point. Hell, I've been wrestling with just setting up Jest with TypeScript not that long ago, and measuring code coverage still isn't perfect. You're not going to tell me that you never run into those sort of things with non-JS languages that compile to JS.

I use Elm for all my front-end work. Its compiler and debugging tools are really nice. I also like its functional nature. Elm helps eliminate most of the common issues with JS code and I can also accomplish the same thing with a lot less code in Elm. It's probably not for everyone, but I like it.

Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript).

On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language.

JavaScript was a perfect choice for Node.js. It's event-driven design is a perfect fit for a performant web server. Python would have been a bad choice, because it didn't support asynchronous programming when Node.js was created. Furthermore, using the same language in the backend and frontend will reduce context switching, enable code reuse and generally speaking improve implementation efficiency.

Yea, modern JS... it's just a joke, no integers, still funny effects with []+[] and {}+{} and []+{} and {}+[]. Good luck with writing anything serious using such a crap.

Both ESLint and TypeScript solve all that. In all honesty, if you're not using tools like that I'm not sure you're doing "modern JS development". It's like complaining that modern C++ is a mess while refusing to use references and RAII.

In C++, proper tools are part of the language. In JS, they're part of ecosystem of third party components that's changing on a weekly basis. There's a difference.

ESLint was released in 2013. TypeScript in 2012. People keep complaining about this "weekly basis" stuff but really the pace has been pretty slow lately.

If you want to use constexpr in C++ you're going to have to upgrade your compiler as well, right (and, if you're unlucky, "migrate your project files" and all that mess)?

> In C++, proper tools are part of the language.

You couldn't be more wrong. The toolset that you need to develop decent C/C++ programs is massive and took decades to develop.

Modern ECMAScript is still stupid, yes. Weak typing is 100% a bad idea, and no new language would take this approach. It has, however, obviously improved to the point where it's actually quite okay to use – a modern ES7 app exploiting features like class sugar, async/await, improved syntax etc. is perfectly serviceable, alongside a linter to prevent the stupid features from old versions biting you.

But a whole bunch of 'serious' applications have obviously been written using JS, and it's a totally stupid view to think otherwise. Frankly the people who are the most concerned with 'my language is better than yours' litigation are by far the least productive developers I've encountered.

this is all wrong, sorry.

modern js is still js. the fact that linters are _required_ to keep code sane is proof enough. typescript is a different language, i'd wager it doesn't count, even though i agree it's a considerable improvement.

au contraire, many developers know exactly what programming in js looks like, especially compared to other languages. i used to think that c++ and boost compilation was crazy. now i look at glorified web pages with 200MB+ of dependencies and wonder how we got there.

i agree that js was a perfect choice for node.js, because it was the only choice for node.js - to use the same language that runs in the client. that doesn't make it a good - or even sane - choice in the greater perspective. python was and still is a good choice - twisted was used to create async services before ajax was a word. you can also take a guess from where the promise/deferred pattern took at least some of its inspiration.

What language do you use that does not have a linter?

> wonder how we got there

I fully blame the virtually non-existant standard build- and module system in C/C++/JS for a lot of the current problems.

This is one of the reason I really want to learn Rust. Compared to make/npm/gulp its infrastructure looks heavenly.

> python was and still is a good choice - twisted was used to create async services before ajax was a word.

Async was not part of the core language when Node.js was first released. Even today the library ecosystem of Python is fragmented, not everything works asynchronously.

"linting" is subjective, preferential—not required.

Python built linting into the language itself and it's super annoying.

It's getting frustrating how much these discussions get dominated by people who self-admittedly haven't used a technology very much and then rant about it. Besides what you brought up, the package manager thing doesn't even make sense.

I'd suggest that inexperience/ignorance isn't a great place to analyze anything from. Some of the "major" issues that dominate these discussions are not problems in practice.

A counterpoint is that people develop Stockholm syndrome over especially broken technology, and immersed long enough will no longer register just how ridiculous some aspects of it are.

It's very easy to take that knowledge you built up over years for granted and assume anybody who doesn't grasp it immediately is an idiot.

It's easy and lazy to assume that you're the enlightened one and everyone else has some defect like Stockholm Syndrome that keeps them from seeing the light.

Other people simply accept different trade-offs than you.

>Modern JavaScript is not a very badly designed programming language.

JS fans said the same thing years ago, claimed that it didn't need classes, more extensive core library, or better syntax. Then came ES6, almost a different language, and they magically changed their opinions to match. Apparently all those features they dissed were needed and good. After seeing this kind of switch-a-roo several times I realized that most of JS community have no fucking clue. They will gladly consume and defend absolutely anything they currently consider "theirs" and "modern". It's a matter of fashion and identity rather than language and tooling quality.

JS was and is a horribly designed programming language. The Web would be lightyears ahead of its current sorry state if the core language was a dialect of List of Smalltalk.

>JS fans said the same thing years ago, claimed that it didn't need classe

Well, I didn't make that argument.

ES6 is not almost a different language. It provided many good features, though.

>JS was and is a horribly designed programming language.

Nope.

I didn't find JS any worse than Java, PHP or Python.

They all have really ugly parts at least in JS they don't slow you down.

I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is true: 9999999999999999 == 10000000000000000.

I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems.

I agree that they are problems, but their impact on day to day use of the language is zero.

If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community.

The language itself is the last problem with JS

I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal.

I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard.

I guess worse really is better.

That's like saying group XY of people is bad because you got mugged by one person of that group one time.

While I understand that a problem like this is unnerving, it isn't the rule.

Wait, did you just call me racist for not liking JavaScript?

A chauvinist.

People throwing around strawmen in here like nobodies business.

We can do this with all languages and tell ourselve we're using the "superior" language.

> turns out JS was implicitly casting my string value to octal

How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though).

I guess maybe parseInt can do that, but that's neither casting not implicit.

Looks like it's been fixed in ES5. From memory I was performing an operation on a html color string and if you clicked a color with a certain prefix it would crash.

I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting.

https://stackoverflow.com/questions/2547836/why-doesnt-an-oc...

> Looks like it's been fixed in ES5

That was published 9 years ago.

Presumably by calling parseInt('010') which used to detect zero leading strings as octal.

I enjoy Javascript, have also programmed in it professionally for a little longer than you, didn't read all the docs in depth, don't have a great memory, and it on (admittedly less and less all the time) rare occasions still surprises me with unexpected or downright bizarre behavior. (But I also use other languages and thus know what sanity looks like).

Sure, you can work around JavaScript's warts, but it is one thing to say the warts can be circumvented and quite another to claim that JavaScript is on par with well-designed languages like Python.

I do agree with you that the JavaScript community's issues you mentioned are hell to deal with; however, in my opinion, JavaScript's internal weaknesses are one of the driving factors behind this churn.

Both ESLint and TypeScript solve all of that except the integer thing.

But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to complain about on the internet.

Actually, in Python integers have no upper limit (sic!).

I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.

Oh wow, really? I feel pretty stupid now. All languages I've used in anger have an upper limit for integers so I'd just assumed this was pretty much general. I see now that it works in Ruby just like in Python.

Pretty cool! Learn something new each day :-)

It's a bit annoying when doing interop between languages that have the (more common) 2⁶⁴ limit and JS - int64 for IDs etc is fairly common and you then always have to remember to convert them, e.g. by putting IDs as strings in JSON output instead of as a number.

Just because JS' _this_ doesn't behave like in other languages doesn't make it bad, I mean it's behaviour is well defined.

JavaScript is more dynamic than most languages and yes this may be hard to grasp for the average developer, especially when they come from languages that are considered "more mature".

> behaviour is well defined.

True, and we could go one step further: it's unambiguously defined, with invariant rules that can be used to prove a conformant implementation.

Yet we still struggle with making sure we've got all of the tools that could check the mistakes I have accidentally made before I had shipped the code.

XMPP had been defined as formally: where have we ended up with it now?

Just wanted to make a few counter-arguments:

> re: it doesn't have multiple ways of declaring a function...

Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?).

Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax).

> re: Python's datatypes are straight forward...

While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in.

> re: 9999999999999999 is precisely 9999999999999999

It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with.

FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.

Python has at least 4 ways to define a function: you can have a plain function, a bound instance method, a bound class method, and a lambda, which is similar to the same options js has.

Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks.

Other than Python's superior type handling and standard library they seem like very similar languages to me.

9999999999999999 > Number.MAX_SAFE_INTEGER === true

JavaScript numbers are IEEE754 double precision floating point format.

I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language

Let's take a step back here: the web is designed, from the ground up, for hypertext, interlinked documents comprising text and images, some of which are clickable and lead to other hyper-documents. HTTP - hypertext transfer protocol. "Web dev" should be referring 100% to things that happen on the server, which can be in any language you like, generating documents that are rendered as the end user would like. Forcing a thing designed for documents to run entire applications is what has gone wrong, it is, on the most fundamental level, an incredibly stupid thing to even try, but the entire industry did, and here we are today. It would be like MS declaring all Windows development henceforth will be in VBA macros for Word.

This is why the real engineering disciplines don't take software engineers seriously. You would never see a civil engineer try and construct a bridge out of some completely inappropriate material...

it may be, on a fundamental level, an incredibly stupid thing to even try, but it also seems to have been an incredibly necessary thing and incredibly appreciated thing by most of the world.

Necessary how? All the actually useful things you can do on the web you could have done with a 90s browser. I bet Amazon still works in one!

Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I guess...

> All the actually useful things

You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works.

In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web.

You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web today. You would have to strip the services down to make them work, ie turn them into completely different products.

Simply put, most of the things most people do online today, can't function in a 90s browser. Just try using IE 5 or Netscape 4 with nearly any of the major Web services today. You can't. IE 5 with Facebook's non-mobile site? You have to build an entirely different product to make that work, basic interactivity drops to near zero.

1990s MapQuest sucked, big time. Google Maps is a radical improvement. How about simple things, such as smooth, fast, highly interactive stock charts, or real-time updating stock quotes, without having to reload the page constantly? 1998 browser? Nope.

Would the user experience be better if everything on the Web adhered to strict 1998 standards? That's an obviously subjective opinion. I don't think so. Do people like to see instant previews of the content they're about to post to Facebook or Twitter? When they click the little upvote arrow, do they like to see an appropriate reaction? When posting basic content or interacting with simple site features, do they like having to reload the entire page?

All those things existed before they became web sites, and they aren’t web sites for any particularly good reason today. Email is a good example. GMail is Outlook rewritten in VBA running inside Word.

Let me guess... you’re a JS dev and you think “little upvote arrows” are where the real value is?

Gmail is Outlook rewritten in VBA running inside Word, except it works better and doesn't leave you open to a bunch of viruses. I mean did you ever use the Windows client of Outlook? On the one hand your argument makes it seem that you did, but on the other hand you also seem to prefer it to Gmail which makes me distrust the argument completely!

Other than that Email is a good example.

Except for the fact that most people use these services in the browser even when there are native clients available? In nearly all of the listed cases the bottleneck is almost always the network and not the JS runtime.

Clearly the users are wrong, I guess? Perhaps you should explain to them why your delicate design sensibilities dictate that they should download native clients because you think HTTP has gone off spec.

Let me guess... you're a COBOL dev and think computers should have never developer GUIs.

you're a COBOL dev and think computers should have never developer GUI

Not quite that old, but I was doing web and Java professionally in 1995, so I’ve seen it all.

The users are not wrong; they’ve simply been trapped in a local minima by inexperienced developers who would rather reinvent the wheel than make progress. Except every time the wheel gets squarer.

Thank god for speaking up about this. This whole thread has me contemplating a career change. I'd rather dig a hole and fill it back in. The OP is pondering what framework to use for the front end. How about you do the design/css/copy then worry about the framework.

I think the main problem is everyone insists on over engineering a fucking website.

You'll likely love typescript. You can spin it up with:

npm install -g typescript

then put this in a tsconfig.json file:

{ "compilerOptions": { "emitDecoratorMetadata": true, "module": "commonjs", "target": "ES5", "outDir": "ts-built", "rootDir": "src" } }

then run tsc -w

you can tweak the compiler for prod or debugging output etc. with these flags for the cli or the json config: https://www.typescriptlang.org/docs/handbook/compiler-option...

Then you could add a single css file in which you prefix class names using something like: myprojectuniquename__someelement.

Then if you use async/await instead of callbacks, flexbox in your css, check supported browser features by googling 'caniuse feature', and use fetch for network access, you could have a pretty simple system that works for you in under an hour.

> Things are not pythonic.

You say that like it's always a good thing. I remember I spent 4 hours trying to import a function from a file that was in a sibling directory before I finally gave up and copy pasted the function.

There's also other things that really rub me the wrong way in Python. Once you get used to writing computations as a map/reduce/filter pipeline with fat-arrow functions in ES7, Python lambdas and list comprehensions feel so crippled and lacking in comparison.

There's a lot of other things that ES7 does really well such as imports, asynchronous code with promises/async-await, array/object destructuring, the spread operator, etc.

Don't get me wrong; I love Python and use it heavily in my day job, but it's not the end all and be all. There are fantastic libraries written for Python that make life really good (think Reportlab), but for applications that are highly asynchronous and I/O heavy, I'd take ES6 running on Node any day over Python.

I feel like everyone is picking up on your language complaint, but maybe that is not your biggest concern.

It seems like you give JavaScript as an example, but what really worries you is the complexity of the front end ecosystem.

Here are a few ideas to reduce that complexity:

Don't use a package manager, you can copy dependencies into folders.

Remove steps from your build pipeline unless you really need them. Use ES16 to get native promises and imports. Or don't use ES16, so you can remove that step from your build pipeline.

Use as few dependencies as possible. Whenever you can, make use of native browser behavior and CSS.

Less automation may help reduce his complexity, but will lead to more instances of breaking things do to mistakes due to manually performed steps. In general, I agree with part of your point - only use what you need. But make sure you are using the things you should.

I read all of this, made a 8 paragraph long retort about the stupidity of backend devs in this thread, then deleted it.

The reality is, if you don't currently serve a website 1,000,000 people want to use, just pick some terrible server side piece of crap and call it good.

If you want 1,000,000+ people to use your website, you better learn that a dynamic user experience is expected, and delivered with eloquent javascript and design.

Yes!!!!

> There appear to be an excessive number of package managers involved.

Largely agree with your assessment except for this. Which package managers are you referring to? 99% of the js world uses npm, and the other 1% uses yarn. I’m not aware of a single other package manager in the web ecosystem. In fact this is probably one thing where they got it right.

Bower?

It's all moving to npm

And those 2 are largely interchangeable because they use the same repository (barring unusual setups)

What is "PL"?

I find it kinda funny that you compare to Python as the way you want webdev to be, since Python and JS are very similar in my mind, aside from minor syntax differences and JS keeping more warts from it's early days, they are very similar environments.

I like Python and have been doing some Tensorflow recently, and one thing I've definitely noticed is that Python docs really suck compared to mdn JS docs.

The biggest problem with JS on the other hand, is it's lack of a decent standard library so you have to use a lot more 3rd party libs, and setting up a modern babel/webpack/linter/test tool chain is a pain in the ass with so many different options to choose from.

PL = Programming Language

Javascript WAS terribly designed but still allowed su to do amazing things. I would argue that in the last 3 years its come a long way and is no longer a terrible language.

I think complications of today came from the problems of its past where it was taken for granted that you needed a framework to get around browser differences.

My personal and professional view has been use plain vanilla modern JS. Make an informed decision on whether using a framework makes sense for your particular project.

If you're making a mess of JS, its more likley you need to re-evaluate your approach to the problem rather than the easy thing to do which is to blame the language.

>> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend

Low-code tools are worth a look, depending on your task. Due to some reason, they are rarely mentioned at HN, But they already work very well for business apps, with some tools even claiming "pixel-perfect" ui creation, so maybe it can work well for consumer apps too.

And Amazon/Microsoft and Maybe Google are all working/having on such tools, so it may indicate these tools are becoming popular.

Node.js with ES6 is a dream. i love it

I know when someone comes from C family language, he/she is not able to understand JS first but the person who knows JavaScript programming will never write like this. Actually JavaScript has few concepts those are much different compare to C family language like prototype and pure function which are superb. Even C family languages developer are now thinking to add few concepts from JS language.

JS isn’t really terrible, I’ve done 25 years of c, c++, go, pascal, swift and I found js lack of typing refreshing. I built a fairly complex app in 4000 LOC. This would surely have been 10x bigger in any of the languages mentioned above. If you use es6, you get rid of the most common js issues (var hoisting, this scoping, etc)

At some point 10x less LOC has to be factored in as a significant benefit

For website you don't need any libraries. You might consider some static site generator.

For SPA go with create-react-app with react router with TypeScript and MobX and you will be satisfied. If you don't need/want to configure things swap webpack for parceljs.

can your web site be pre-rendered or rendered on the fly? then do server side rendering - only send html to the client. if you need dynamic rendering - use static js - only for those parts. if you need everything to be dynamic rendered eg live push, multiplayer games etc do full js rendering but do not use static html! only css/js. i think the complexity comes from web devs familiar with server rendering tries to use the same paradigm with dynamic sites for example angular and react. you should do it more like a desktop app instead of web page. if it makes sense do the rendering in canvas instead of the dom.

You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover that most JavaScript developers do not understand the language well because of the same assumptions you are making. It's a highly misunderstood language due to human stupidity.

While it is certainly possible to understand JS it is - IMO - a waste of brain cycles that we have to live with. There's no doubth in me that even very good Javascript programmers can be significantly better in a better language.

E.g. Typescript gives you literally all of JS - and a way to keep things tidy.

Typescript which is a compile-to-js language in a weird way proves how lacking js is - while still buildiing on top of it.

"very good Javascript programmers can be significantly better in a better language."

This is not how it works.

Take this idea that JavaScript is a "badly designed language" out of your head and understand that about 99% of JavaScript's behaviours are intentional.

The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language.

It is not just misunderstood by your average Joe JS dev, but also by many who claim to be pros and experts.

JavaScript is a language that doesn't tell you how to do things, there are no constraints. This is why so many people suck at it.

They want to use statically typed classical inheritance constraints on a language oriented around higher-order functions, coercion and literally everything being an object.

If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it.

If you are convinced that there is already a holy grail structure to programming languages then you will always have problems with JS.

TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.

OOP languages are already hugely problematic when it comes to complexities. So imagine how overly complex the JavaScript eco system is becoming due to a generation of developers who want it to be more like x OOP language it does not have the foundation to be like.

There is no defacto solution for software engineering everything still sucks, and nobody remotely has it figured out.

> Take this idea that JavaScript is a "badly designed language" out of your head

Respectfully, no. The impressive thing about it is it was written in 3 weeks. Edit: I also didn't say Javascript was a badly designed language, at least not in the post you replied to.

The rest of it is like PHP (yes, I have programmed a fair bit in that as well).

> and understand that about 99% of JavaScript's behaviours are intentional.

So much worse ;-) There is one good defense for Javascript IMO and that is it was made in a very short time.

Intentionally leaving in a heap of footguns like Javascripts type coercion isn't brilliant, it is either pragmatic, myopic or evil. I say pragmatic in this case.

> The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language.

The classic Perl defense I'd say: ~you don’t understand the beauty of it.

> TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.

Well, every thing you can do in JS you can also do in TS.

In a sense you can say this is our implementation of what you said above: "If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it." And here you are right: Typescript is quite a lovely language:-)

Also: By this logic we should be programming in assembly.

> It was written in 3 weeks

Actually 10 days, with 22 years of development, but that has nothing to do with how it fundamentally works.

> The rest of it is like PHP

Are you joking? Ok so, JavaScript is a prototype based language PHP is (now) an OOP language. They are not remotely the same with the exception of dynamic types and even that is nothing like PHP due to the nature of JS engines like V8. But because if the prototype system it can emulate classical OOP.

JavaScript is also a higher-order language which mean it is a psuedo-functional programming language.

PHP and JS could not be further apart.

> The classic Perl defense I'd say: ~you don’t understand the beauty of it.

It's not about beauty, I'm saying that most people who think the language is making mistakes or doing something wrong just don't understand how it works. They blame it for their lack of knowledge.

> Well, every thing you can do in JS you can also do in TS.

But that's not why people use TypeScript, they use it to do TypeScript styled things.

> what you said above: ~ intuitive enough to create your own restrictions

That's the problem, TypeScript comes with a bunch of constraints, that's its purpose. Yes you can choose to use them or not. You could also buy a new phone and throw it off a cliff, but that's not generally why people buy phones.

> Also: By this logic we should be programming in assembly.

Assembly serves a purpose well, so does JavaScript. I'm just saying rather than trash things why not learn them first properly.

And once that lib gets larger then 4 files, it becomes slower and slower to maintain, because JS. Spinning up new devs on any large JS project is a pain. Typescript, no problems.

Lib size differences are ~0.

I programmed in more than 10 languages and I'm very productive with TypeScript and I doubt there's better language for interface development or I would be using it instead.

What exactly do you propose? I will test it out.

My suggestion is that you continue with Typescript.

I use Typescript as well.

> It's a highly misunderstood language due to human stupidity.

Or maybe it's a highly misunderstood language because it doesn't match human intuitions. That makes it a poor language, like the OP said.

A programming language is not supposed to match human intuitions. We are trying to take things from the physical world an represent them in the digital world.

A programming language should be modelled on physical life. But we still haven't figured this out yet.

I don't think many people understand what a poor language is, you really need to understand the spec fully and experiment with every paradigm in production to claim that JS is a poor language. Can you genuinely say that you have?

> A programming language is not supposed to match human intuitions.

I'd say that's a flat out false conjecture. Given a choice between two programming languages, one which better matches our intuitions and one which doesn't, the one which does will always yield programs with fewer bugs because we will simply be better able to express our solution to the problem being solved, and we will be better able to understand the program and so extend it.

It's like saying that door knobs are not supposed to match human intuitions, they're just supposed to open doors in the best manner possible. Well guess what property opens doors in the best manner possible when humans are the ones opening doors? A door knob that's most intuitive and natural for the majority of humans to use. HCI and ergonomic factors are seriously underappreciated in computer science.

> you really need to understand the spec fully and experiment with every paradigm in production to claim that JS is a poor language. Can you genuinely say that you have?

I've used OO, FP, prototype-based, logic and constraint-based programming languages. Yep, I think I can say JS is not a good language. It's improved somewhat, but still not great. It's not Brainfuck-bad, but it's not particularly good either.

> one which better matches our intuitions

> A door knob that's most intuitive and natural for the majority of humans to use.

Ok so let me explain better:

The UX = Human End-users POV (intuition)

Programming syntax = Human Developers (intuition or whatevr)

Tools to deliver (Browser API, CSS) = The domain/s

The way in which we structure work = the things we are building = things that exist in real life.

Websites are mis-leading because many pages appear alike people tend to believe that there's a lot of repetitive components but there really isn't in general.

So inheritance is usually way over used despite the style of programming.

I am not discussing how we use a door knob. I'm arguing about how we build the door knob of different variants in mass production.

> It's not Brainfuck-bad

Brainfuck is not a "bad" language, if it serves it's purpose well then it is good. I think Brainfuck is doing exactly what it intended to do.

There are people who have been using JS for 20 years who think it is terrible. It's because they have never taken time out to learn the language properly. Most JS devs don't

I'm not convinced that you have because you clearly wouldn't be saying x is a poor language. No language that is in high demand today is a poor language.

> No language that is in high demand today is a poor language.

Well that's clearly false. COBOL was in high demand at one point. The popularity or prevalence of a programming language has very little to do with its technical merits. We've seen this play out dozens of times over the past few decades.

And "X is bad" is typically intended as a relative measure. JavaScript would have been a great general purpose language compared to the state of the art in the 50s and 60s, maybe even as late as the 70s. It was maybe ok as an embedded document language at the start of the web in the mid 90s, since everything was so experimental and quickly evolving. It's not a good language now, and hasn't been for some time. It has some good qualities, but also many bad qualities that run into bad software engineering practices.

Finally, I'd say that any language that many people would rather use a transpilation/compilation target rather than use directly, is clearly a bad language.

I think JS is fine.

The root of the "problem" is that the web is an unusual platform. It actually punishes bloat, in a way other platforms don't. A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly. That means web developers must learn that code reuse is a tradeoff instead of seeing it as a pure positive. That's a good thing in my book. Either take the heat and replace your 10 dependencies with 1000 custom-written lines, which is usually easy in JS, or get out of the kitchen.

* A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly.*

Except that native apps, in practice, don't do that, and websites routinely load 10Mb of JS when the user only wants to read a 5Kb article.

The New York Times app for iOS is 119.8 MB.

Try Clojurescript + Reagent. There's no reason to use JS if you have a choice.

TLDR; The language design of JavaScript is not the problem. There are 2 problems in my opinion:

1. Our reliance on typed languages, compile-time errors, and IDEs

2. Too many choices for frameworks and libraries.

I wouldn't agree that JS is a poorly designed language. I will come back to that soon.

I would argue, like some others here that we are just too lazy. We enjoy the safety provided by typed languages and compile-time errors. That is one reason to love our IDEs.

Back to the problem. There are a lot of things that you are saying. I will try and address them one at a time.

> web dev has been badly engineered. * Yes, no, and it depends. Web Dev is a very board, it encompasses many technologies, like HTTP, HTML, CSS, JS, Application servers, etc. So you are saying HTTP id bad? or HTML is bad? I know I'm reading it out of context, but bear with me. I believe you meant JS is bad. That brings us to your next opinion.

> JavaScript is a very badly designed programming language. * When you say badly designed language, what is it that you exactly mean? Is it the syntax? Is it the grammar? Or is it the fact that it is loosely typed dynamic interpreted language? And what are the problems you talk of, any examples?

> Is JS a recognized terribly designed language?

* Who recognized it, any sources? Like the U.S.A. recognizes ISIS as a terrorist organization. I'm pretty sure the developers of node.js do not recognize that JS is a terribly designed language.

> There are many frameworks for the same tasks, that try to do everything.

* Yeah, I agree. I really hate having so many choices. I have to spend too much time investigating which is the best one for my use-case. I'm just too lazy. (sarcasm was intended) That said, I still agree, and it does make life hard. But too many choices is not a bad thing necessarily.

> There "appears" to be an excessive number of package managers.

* There is only NPM, everything else is either deprecated or based on NPM. Please inform yourself better.

> ... range of solid and well-designed languages and technologies, but at the front end ... choose the least poor of a bunch of crazy options.

* WHAT? There is only 1 option on the web today; JavaScript. Period. Unlike backend. What you are talking about are framework and libraries. Check the "too many choices" point above. If you believe that backend development has fewer choices involved, then I assume that you sir have limited experience.

Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.

Reply on news.ycombinator.com