> JavaScript allows getter/setter methods that can update the DOM when a value changes; this includes before/after and around-like methods that can integrate AJAX calls in a VARAIBLE name. e.g., you access the variable and an AJAX call fires and updates your DOM when the data returns with you doing ZERO coding.
Maybe I'm old but that sounds TERRIBLE. When my code is doing something expensive like a network call, I want to know about it.
Another way to look at it is you just removed 300 lines of buggy redundant code into one line that does exactly the same thing but without all the fuss. And now that your code is so small you can understand it better, and test it.
Also, there's this "new" thing called async/await: javascript is built on deferred execution, so you don't block on expensive calls. PHP is a dinosaur.
Reactivity is mostly used for managing the DOM in a natural, non-intrusive way, and my AJAX example is maybe extreme, but a good illustration. I'd say that concept in the frontend is biggest invention since 2010.
> Another way to look at it is you just removed 300 lines of buggy redundant code into one line that does exactly the same thing but without all the fuss. And now that your code is so small you can understand it better, and test it.
Maybe I'm missing something critical here, but the code doesn't go away, does it? You still have to have the AJAX implementation, it's just that instead of the intention-revealing interface of a call to something like fetch you have an intention-obscuring interface of magic properties.
The code still has to live somewhere, even if you've swept it under the rug. But now when you walk across that rug it's real easy to trip.
I believe you are arguing that high level languages shouldn't exist. :)
Did you write the driver that you call when you do HTTP request through a TCP/IP stack? No? You just swept it under the rug!
I kid, but I honestly don't understand your resistance. You don't seem to want to let go of some kind of anchor, referring to it as "magic properties." While I argue you already are letting go at so many other levels.
It is easier to read code that says:
div
p The current stock price is {{ stockPrice }}.
And then have code like this in your typescript MV implementation (using VueJS).
Every time the DOM is redrawn this updates, and it is 100% non blocking, easy to read, and trivial to maintain. (I didn't bother with a catch, but you should have an error handler elsewhere for non-transactional dynamics; also didn't index the data object since Axios returns JSON, but that depends on your endpoint that you wrote.)
The HTML (well, Pug, because who writes HTML?) is clean and easy to read; I didn't need to $('domObject').innerHtml() with jQuery; I didn't need to implement a wrapper around 'new XMLHttpRequest();' and I didn't need to block execution -or- write a big messy Promise<> because async/await. 80% of this benefit is a framework (20% is ES5).
Is that really so awful?
And: If you want to be skeptical of frameworks, I thoroughly encourage that because they need more critical eyes on them! Seriously, they need some restraint. There are some deep rabbit holes that devs go down which really turn a great idea into crap.
EDIT: I have to add that if we were working on a project you'd be looking at me funny, because I gripe about frameworks and tooling non-stop. I feel like I'm forced to waste time on so many hacks to utilize the truly brilliant ideas in frameworks. So I take no responsibility if you fall into the framework hole with the rest of us! :)
If the code was buggy, fix the bugs. If the code was truly redundant, you could delete it. I suspect you meant more that it was repeated in several places, in which case, of course refactor it to be more DRY. If you can write an abstraction that provides a consistent mental model and relieves programmer burden, then do it. None of that is in dispute.
My point is rather one of interface design. This is about communication with other developers. Help them out! Give them affordances to make their lives easier. Leave clues so they know what's going on.
A developer coming up to your template that just says {{ stockPrice }} has zero chance of knowing that this is going to secretly issue a network request. If it looks like a field reference, people are going to assume it has roughly the same characteristics as a normal field reference. That's an eminently reasonable assumption -- don't violate it.
Everyone would be surprised to see that take several orders of magnitude longer because it needs to touch the network. Everyone would be surprised to find out that they can't include that field in a template that might possibly be rendered when the user has no network connection. When things do something different from what they look like they're doing, it's surprising.
Maybe so; it's pretty normal to expect a property setter to perform additional operations, as it's necessary for making data binding more manageable among other things. But using Go to Definition takes me directly to the getter/setter, so imo it's not exactly hidden.
I think it becomes problematic (or more magical) when these network/database/expensive calls are made willy nilly throughout an application, without a dedicated class or layer to aggregate these kinds of operations. If you have things architected correctly, it's not a big deal to trace these kinds of things throughout your app.
Maybe I'm old but that sounds TERRIBLE. When my code is doing something expensive like a network call, I want to know about it.