> You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts.
When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it still has a lot of JavaScript baggage you'd want to strip out.
> I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future.
All the big UI libraries end up offering some kind of markup/constraint-based interface - which is ultimately data rather than code. And for editing that, a visual form designer makes a lot of sense. I like Qt's approach - you visually edit a markup form that's compiled into a class you can subclass, so you don't have to deal with the problems of code generation, and the markup is relatively version-control-friendly.
> Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP.
I'm not the person you replied to, but thrift/gRPC are a lot nicer to work with than REST APIs. Standardised protocol definitions that let you understand what kind of changes are or aren't forward/backward compatible, and no need to write a bunch of boilerplate by hand.
> I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript.
It's the same story as "no-code" tools: IT departments won't let anyone install an application runtime, but they're happy to install a "document browser" and let it run arbitrary code. It's understandable, but depressing.
When the bar are languages like F#, Haskell, Elm, Reason... How can JS be considered good? All languages have warts, but JS is a language full of them, ambiguity is the name of the game, mutating everything is encouraged and global mutable state is everywhere.
Very little has changed for JS outside of syntax, the core is still rotten.
> Modern JavaScript is pretty sweet to write compared to pre 2015.
That's damning with faint praise if I ever heard it. JavaScript has more or less caught up with the lowest common denominator of other languages. But I've yet to hear anyone make a good case for actively choosing to use it.
I'm a long-time Javascript hater. I recently did some vanilla ES6, now that browser support is finally at a point where you don't need to transpire to ES5 - I admit, ES6 is much nicer than things used to be, and not having to transpile is wonderful.
But realistically you still want a JS build pipeline of some kind, for minification, compiling SASS to CSS, and other things. And of course if you're doing "modern" frontend work, you're not using vanilla JS like I was - you're using a complicated framework like Angular, React etc, and having to deal with the likes of webpack.
And then there's the anaemic standard library - honestly, barely any better than it was 10 years ago. And then, largely as a result, you've got NPM-dependency hell, with hundreds or thousands of deps for just about anything. Want to trim a string - there's a package for that.
And then there are other languages and ecosystems - when you compare JavaScript to those... well, then you really have to admit it's a turd.
Hating on JavaScript isn't a bandwagon - there are many genuine reasons why people dislike it and the ecosystem. IMO, comparing it to a "circle jerk" is like that meme where some character is surrounded by fire saying "this is fine".
> And I'd be pretty skeptical of someone starting a new project in Lua today.
Well, there is the upcoming play.date SDK for example and a lot of jam games.
The biggest reason why these languages are used is because they are fun.
Don’t get me wrong, I really like swift and SwiftUI. But there is something quite liberating when throwing away the type system completely and just hacking at the code. This brings in new people who get motivated by seeing a thing shaping up rather than staring at weird error codes.
> but thrift/gRPC are a lot nicer to work with than REST APIs.
I agree with this, protobufs are nicer to push around rather than JSON. Ultimately though one can do pretty arbitrary stuff with either.
For your last point I think that is a separate issue. The ubiquity of web is certainly reason for its popularity. But I was mostly talking about why people hacked around issues with upstream rather than trying to find more sound solutions.
When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it still has a lot of JavaScript baggage you'd want to strip out.
> I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future.
All the big UI libraries end up offering some kind of markup/constraint-based interface - which is ultimately data rather than code. And for editing that, a visual form designer makes a lot of sense. I like Qt's approach - you visually edit a markup form that's compiled into a class you can subclass, so you don't have to deal with the problems of code generation, and the markup is relatively version-control-friendly.
> Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP.
I'm not the person you replied to, but thrift/gRPC are a lot nicer to work with than REST APIs. Standardised protocol definitions that let you understand what kind of changes are or aren't forward/backward compatible, and no need to write a bunch of boilerplate by hand.
> I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript.
It's the same story as "no-code" tools: IT departments won't let anyone install an application runtime, but they're happy to install a "document browser" and let it run arbitrary code. It's understandable, but depressing.