Could you elaborate? I've never done either and I'd be interested in hearing some more details about why it's not working out for you.
Doing anything with web tech is much faster at first, but web app debugging ( if you can even call it that ) is utterly dreadful so development ends up being slower.
It makes me think that the people who designed a lot of this stuff simply weren't in their right minds, were willfully ignorant, or just didn't care. As a result, it's easy to get held up for hours finding bugs that won't even make it past the compiler if I'm working in Visual Studio. It's like being in the dark ages!
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.
Everything is so disparate and cobbled together. It's like people think that the ability to glue JS "libraries" together in "interesting" ways is a smart way to develop software. I think, as a C++ programmer, that design decisions that appear strange and stressful to me are behind a lot of the JS fatigue that people talk about these days. In the C++ world, such Frankenstein creations would be thought of as weird or incompetent, or only ever done as a last resort ( like when you don't have access to source code and you never will ). Like, the idea of passing so much stuff around as strings or JSON 'objects'.
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.
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.
I think a good analogy is as follows: "modern" web development is like if I were to write a C++ application without using the type system. You know, I could just use std::string for everything. Numbers are strings. Objects and their fields can be represented by strings. I would just pack everything into strings. Then of course, I'll have to parse everything to make sure things add up afterwards. I can write all sorts of interesting libraries to help me work with all my text, without ever realizing that these libraries wouldn't have to exist if I had done things right. It seems like web tech forces you to do things that would have been regarded as utterly foolish 40 years ago, never mind today.
The last two weeks have left me struck with the following notion: "this is all just text". Everything is text. It's like an utterly incompetent C++ programmer just did everything with strings. "My data structures are just text!" "My objects are objects because they're in separate text files." "My modules are modules because they're in separate directories."
It makes no sense at all.
If you have to build a desktop app with jquery soup (or even angular), I definitely feel for you.
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.
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.
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.
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 -.-
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.
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'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.