161–170 of 275 posts
It took a lot of time and effort and being a stick in the mud, but the trick was ultimately an algorithm/abstraction I call source derivation (SDx).
Here's a simple example of the algorithm: https://codepen.io/SephReed/pen/gOaeQLv
I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…
The javascript framework fatigue meme was born during the early days of ember, backbone, angular 1, knockoutjs and meteor. Sometime between 2016 and 2017 was when it should have been put to rest.
As a software developer I consider the most important part of my job to be evaluating new tools and techniques. This craft is in its infancy and our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget. Nobody can afford to miss out on productivity enhancements and that means following trends, but with a critical eye. If someone is "tired" of this proce…
Really? I would argue it’s building software.
> This craft is in its infancy
We’ve been building software since ... dunno ... 1950s? 1960s?
> our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget
This is probably true, but I suspect chasing new tools isn’t the solution. I’ve seen a lot of very much with it development teams fail at building stuff because they couldn’t get their shiny new stuff to work predictably.
> If someone is "tired" of this process it might be time to consider another profession.
On the front end, yes, it’s probably par for the course. I suspect it’s because front end development is even more removed from rigorous engineering practice than back end development.
On the back end, however, lots of stuff is still built in Java and C(++) and it all works reasonably well.
It’s just not very exciting.
Earlier quoted context omitted.
Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of program…
Typescript is leagues ahead of Python. Types and async/await are the big ones, but destructuring, no lambda weirdness, optional chaining, nullish coalescing, proxies, JSON support, and generally debugging tools are all better.
* Python has async/await. It's not as pleasant as goroutines, but it exists and is presumably about as pleasant as async/await in TS, at least assuming you're using or not using the type system in both cases.
* Python has tuple/list/iterable destructuring. What is the specific limitation here? Maybe key/value destructuring?
* What's python's lambda weirdness? The single expression limitation? I agree that's tedious, albeit you can do a lot with a single expression (but not handling exceptions).
* JSON support. What's wrong with Python's JSON support? I mean, the type system can't model recursive types yet and that's super annoying, but the JSON stdlib seems fine. JSON maps pretty neatly onto Python dict/list/str/int/float/None/etc types.
* What are proxies and why are they desirable? Genuinely curious.
Let me make the argument against axios. Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you…
> adds 4.4kB (minified+gzipped) to your bundle ... Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!) A few times? You're suggesting doing that 50 or 100 times. Adding 4.4kb an actual few times is meaningless for the end user.
Don't get me wrong, there are valid reasons to use axios, and I don't have a problem if you communicate those clearly. But I believe few developers make a conscious decision about the tradeoffs, most developers simply dgaf.
Earlier quoted context omitted.
How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.
Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.
I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…
What do you mean, everyone is now updating their codebases to remove redux, HoF and switch to hooks.
I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…
React had the right idea, just make view management simple, don't force some bullshit IoC container on Javascript and that's it. If you want IoC that's your problem.
Ultimately the problem is that nothing replaces React natively in web API. A tool such as React shouldn't be useful anymore and Web Components isn't as ubiquitous as it was envisioned to be. In fact, I've never worked in any business that used Web Components.
But the biggest issues are on the node.js side and all the complex pipelines put in place in order to fix front-end development. In fine, the tools that will be successful are the ones that will still be actively maintained 5 years from now, and most of the libs/projects will not.
Earlier quoted context omitted.
Typescript is leagues ahead of Python. Types and async/await are the big ones, but destructuring, no lambda weirdness, optional chaining, nullish coalescing, proxies, JSON support, and generally debugging tools are all better.
I'm not well-versed in TypeScript, and I have plenty of frustrations in Python so it's not that I don't believe you, but I do have a few questions: * Python has async/await. It's not as pleasant as goroutines, but it exists and is presumably about as pleasant as async/await in TS, at least assuming you're using or not using the type system in both cases. * Python has tuple/list/iterable destructuring. What is the spe…
Tbh, it’s been years since I’ve done much Python. But the last time I did it was just really clear that TS had leapt ahead. Ecosystem may be part of it.
Proxies are essentially meta programming tools, tbh not fully sure Python doesn’t have similar but on looking they don’t seem as intuitive.