Hacker News Reader

Honestly, it doesn't reflect my experiences. I come from a C++/C#/.NET/WPF background. For the last 3 years i worked on web applications.

Debugging

Chrome devtools can see into every aspect of the app at any time down to a single frame. That extends to the server if you're using Node. With Webpack code is written live, parts you edit change, the rest stays put. State management like Redux makes the apps flow inspectable. Debugging has never been more powerful and easy to handle.

Frontend

The key is picking the right foundation for your project. React/Vue are the fastest MV systems i have worked with. To get comparable results in XAML we'd write 10 times as much code that probably even performs worse. Yes it can crash and burn some day, but we're so close to web components, it's not going to sting like the ng1 debacle.

Data

JSON has been invaluable. I see more and more C++ devs rely on it (nlohmann/json). I won't go into benefits, this one is obvious. Types aren't a problem. Most people do fine without them. If you need types you have Flow.

The point is,

if you barely know your way around, haven't worked with ES6 and modules, the eco system and npm are foreign ground, you will have a bad time. But if can pick the right pieces, chances are you will have a blast.

This year has been somewhat different in that i had to introduce grumpy C++/C# devs, that have been re-tasked because their stack is falling out of favours, to JS. In the beginning they're all a bit like you, they have done some "research" cherrypicking bits and pieces that fit their "JS is a toy" & "lib fatigue" agenda. One week in they've made their first experiences and start to sense the possibilities. Two weeks in they start to grasp the idea that worlds biggest dev community is behind JS-literally whatever it is they seek is on npm. A month or so and they're happily building apps.

> I just can't fathom doing anything large scale without access to real tools, real abstractions. I mean, in JS, abstraction means using separate JS files that people actually believe represent real modules or something! Yeah, separate files are not actually abstractions. Separate directories doesn't mean that something is a module.

I'm not sure what you mean by that, but ES6' module system is not markedly different in practice from, say, Python's.

> Like, the idea of passing so much stuff around as strings or JSON 'objects'.

Just use Typescript and enjoy strongly-typed everything.

> Let's see, I need a graph. But instead of writing an actual graph that uses pointers and objects that are actually separate nodes, I'll use the DOM. It'll be like a tree, except it's made of text. I'll make a 'tree' of objects with the DOM. Or maybe I'll use JSON, which is also just text. I'll write some other tools that allow me to insert JS into these 'objects' so that I can modify them. Yeah, it won't be weird that I combine my data structures and my code, because I'll just use more JS to parse the file and then write another file that will actually be fed to the browser. Text transformation as application development is just totally batshit.

Well, JS doesn't particularly force you to use the DOM as storage. A standard Redux + React solution has a store with a given data model, that is rendered in possibly completely different ways by its React view.

> In fact, despite all the shiny new toys, the fact that text is used for just about everything makes it all seem like a huge technical debt factory.

Again, Typescript (or Flow) is a solution to your problem, here. Basic JS is terrible, and I intend to never write a single line of it if I can help it, but strongly typed JS lets you get things done.

If you dig into the chrome developer tools you will find a lot of tools that make web app development easier. The ability to find memory leaks in the profiling tool has made large javascript applications much less stressful.

Some of the things you mention are no longer best practice, for example, using strings for templates or JSON.

That's actually a good way to describe javascript, C++ without types. It makes the language more approachable. You have to remember, it was always meant to be a scripting language. There will be things that limit the size of applications built with it, and it is not optimized for maintainability.

>That's actually a good way to describe javascript, C++ without types.

I'm sorry but this is just not even remotely true. Javascript and C++ are so different in nearly every aspect it's ridiculous to be comparing the two, from performance to the type system to being compiled to the design philosophy... C++ is far more that js with types -.-

Maybe it is not terribly accurate. At work, we jokingly describe javascript as C++ without all the features, because most of the developers at my work have a C++ background.

My point, even if it was not clear, was that javascript is a simple scripting language. It doesn't need a type system to be useful.

What stack are you using? The description you give doesn't match my experience with modern javascript (react, webpack, flow/typescript, etc).

If you have to build a desktop app with jquery soup (or even angular), I definitely feel for you.

I'm using Electron ( shell? ) to make a simple desktop app. Certain things are much nicer, such as the ability to have everything be "owner draw" in a way that isn't as frustrating as using owner draw in the usual context. IE, I can easily at a bitmap background to whatever component I want. I can control a lot of the look/feel of the UI with style sheets.

IMHO, React is another way of covering up 20 years of bad design decisions that went into web tech. React is the natural reaction to using a tree of text to represent data structures. If things were done right, React wouldn't exist. By 'real modules' I mean things like DLLs that can be hot swapped at app start or at runtime. The more I look into things like Atom, the more I am disturbed by what constitutes 'state of the art' in web tech.

Have you used webpack? It allows for hot swapping and a bunch of other module features.

I mean, react (and associated frontend technologies) are just a way of making it easier to write code within the constraints of browsers, which are honestly a small miracle. Yes, they're a pile of hacks upon hacks (the web was designed to share physics papers, not deliver complicated multimedia applications), but they let you write the same code for every major operating system, device, and form factor that exists and deploy it seamlessly over an unreliable network. It's shocking that everything works as well as it does.

And as programmers, everything we use is just papering over the horror of writing network-connected cat-sharing apps on weird-shaped bits of metal - why worry about a light abstraction over the JS build step?

My experience with Atom has also been sub-par, but Visual Studio Code is pretty cool and built on the exact same platform (electron).

I think you're the exact target audience for typescript, for what it's worth. It will give you type checking, IDE integration, compiler errors, modules, etc basically for free and is (not exclusively, and IMHO) built for people who find javascript distasteful.