What was it about JavaScript that wanted you to leave programming? I'm just curious.
JavaScript is a never ending grind.
Callbacks, then Bluebird, then Promises, then a sync await.
a new testing framework every six months. a new web framework every couple of years. aimless, massive changes to the language (classes in a prototyped language? Why not).
JavaScript then coffeescript then three versions of typescript. too many UI libraries to mention.
JavaScript on the server? the people making the most popular web framework abandoned it 5 years ago but who cares?!
paradigms that make no sense (react morphing from a UI library to the full app). a million ways to manage state.
then you have a few big players calling all the shots (FB, MS). I guess we use functional components now. Eurasia has always been at war with Oceana.
It’s tiring. I’ve spent my entire career doing this stuff; and I’m never quite good enough before The Next Big Thing comes along.
I know things change over time everywhere, but it’s hard to imagine anything moving faster with less purpose than the JS ecosystem.
(Apologies for typos and grammar; I’m on my phone)
But the ecosystem around is just that never ending grind. At my last job, over the 3 or so years I was working fully stack, it was just a constant churn. Start with React / Redux / SRR / Jest / Mocha / (probably some other testing frameworks) / Flow. By the end none of the original testing frameworks were being used. React had introduced Hooks, which I actually like, but it was a whole new paradigm to learn again. Flow was out and we needed to migrate to Typescript as quick as possible. And this is just the React ecosystem!
React has its place and I'm definitely comfortable working with it (also writing 0 tests cause I have no idea where to even start for that) but I'm looking forward to the day maybe simple web apps get back to simple setups. Projects like LiveView[0] for Phoenix really give that hope.
While that's true, the completely opposite is true for Javascript the ecosystem.
I don't have much time for this cr*p, nor do I like it, so I tend to use olde fashioned JS + libraries like jQuery for old fashioned multi page web apps. I want to learn Blazor and Vue for SPAs to keep it more simple.
Imagine if you were a woodworker making furniture. You make the same furniture every day and love your craft. But every month, someone shows up, takes all your hand tools, and replaces them all with a set that are mostly the same but slightly different and all have completely different names.
I got into web development, but for me that means mostly back end. I pretty much dislike big opinionated JS frameworks like Angular, although I have to learn it and I will since I took over a project which uses Angular on front-end. Sometimes I generate HTML on the server side, when I can, using a bit of old fashioned JS and jQuery where is needed. Sometimes I write a REST API for backend and write the frontend using good old fashioned HTML, CSS, JS and jQuery. I like this two approaches the most.
Now I'm planning to learn Blazor and Vue for SPA development.
As an analogy, consider fiction. Imagine reading as many new novels as possible as they're released. Well, most of these novels will be completely irrelevant 5 years from now. The good ones stand the test of time. So you might as well only read novels that are 5+ years old, yet are still relevant and receive acclaim.
If you worry that taking this approach with JavaScript will make you fall behind, my question is: Behind whom, exactly?
There's no way many in the industry can keep up with all the changes you listed as fast as they're coming out. Therefore, it follows that a great many of your JS developer peers are "behind." Therefore, it's okay for you to be, too.
What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows. Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest. The result is that I end up skipping a lot of the fads that die on the vine. For example, I largely missed CoffeeScript.
I think a lot of pain from JS comes from the expectation that one can and should keep up, when you probably can't, and definitely shouldn't.
It's also because the JS ecosystem is absolutely massive -- too massive. Instead of consolidating around a good package, people create a new one. You end up with a small number of contributors (often one) per library, and being on the bleeding edge is the only way to make sure your dependencies are maintained.
The problem with this is that everyone jumps on new fads so quickly that, if you don't, you're likely to endup with a bug-ridden, half-baked, vulnerability-riddled, unmaintained/abandoned, slowly collapsing, termite-infested framework as the basis of your entire SAAS business, or whatever it is you're trying to run on something that even the creators abandoned for the next fad.
> What happens to me, personally, is I start on some new project or company using a pretty recent stack at the time. Over the course of the next few years, that stack becomes "outdated" as new things are released. However, it also matures as its documentation improves and its community grows.
You have to be very, very lucky to accidentally end up with a "pretty recent stack" that will still be maintained in five years. On the other hand, the next part shows that you don't actually go with the 5+ year old "stood the test of time" tools:
> Eventually, after 2-5 years, I move on to another project, and just take that time to catch up on the latest.
Having to learn a whole new sub-ecosystem in as little as two years is exactly the kind of mind-destroying grind everyone's complaining about. I don't think anyone's just jumping on the newest thing that appears every six months; they're all just having to move to some new toolset every two to five years and burning out ten years into a career because otherwise they'll end up having to be the new maintainers of whatever tools they're using due to the fact nobody else is using them (and thus no one else is maintaining them) any longer.
ECMAScript and everything that touches it has become an actually focused bane for the joy of programming. It was fun just writing some clean plumbing for JavaScript applications in the past, but everything else about the process always ended up involving a bunch of scrambling to catch up with rapidly changing technology, planted on shifting sands even while I'm working with it, any time I start on a new project, where all I'm learning is a new set of persnickety conventions that will punish me if my approach is "wrong", force new work-arounds on me, and generally suck up all my time learning new rules to follow instead of interesting new ways of thinking about things that make me a better programmer and software designer.
Learning the interesting stuff, and figuring out new approaches to new problems based on the needs of those problems (and not the whims of the community), is a lot of what makes programming fun for many of us.
Linux exhausts me similarly.
* ALSA; esound; PulseAudio; etc. Just give me updated OSS or sndio on a BSD Unix system. That shit is stable, well-maintained, and not arbitrarily different every few years.
* SysV; upstart; systemd; etc. Just give me BSD RC. Maybe it's not ideal, but shit, it isn't swallowing 80% of userland with eventual ambitions of conquering the kernel and some of the worst defaults I've ever seen.
I'll just stop now, but I could go on for days in this vein. Maybe some of these tools are great, but I don't expect any of them to remain ascendant for more than five years in a form that is effectively recognizable by any significant measure but its name. The churn drives me insane. One of the reasons I aimed for software development in my professional life, abandoning the system and network administration (aka "ops") side of thing, was to escape all that crap. I want to write quality code, build new things and improve existing things, not participate in a rat-race to remain relevant just to have acquired nothing enduring from decades of effort other than stock options and a nice car.
However, JavaScript as application code just feels entirely verbose. I guess coming from a very opinionated framework like Rails leaves you sheltered, but I'd rather use a technology designed for the task I'm trying to accomplish than to shoehorn JS into something else.
Personally I find no elegance in JS, and writing it feels like a chore. If I had to do that daily I'd want to quit too. Obviously YMMV, but I get no joy in trying to fit the tool to the job, I'd rather just use another tool.
One of the reasons it's so popular is because JS is like Latin. If you know some words from one Latinate language, you could blag your way around half of Europe, probably order a meal and find directions. If you know some JS syntax, you can scrape by using half the tools out there today, and accomplish a bunch of different things.
If you want to go and live somewhere though, it's better to learn the native tongue.
However, I'm in a position where I have enough autonomy to avoid all that crap and just use the bits I like. When you get minimal and ignore all of the noise about the latest hotness JS libraries, the plain language (not including the lanky browser APIs) is not unpleasant especially over the last few years where some modern syntactic features were added - You can go even further and be selective of the language itself and it can get even more pleasantly minimal, my recent delight has been excluding classes and prototypes as much as possible.
When you take this approach the whole "churn" issue disappears (JS is backwards compatible, you will never have the issues you have with Rust or Elm forcing you to re-write).
I suppose this is the argument many make for C++ which is that, yes it can be a complex nightmare, or (if you are able) you can restrict yourself to a desirable subset and have a happy time. In JS's case, most of the complexity is from "keeping up" with the community and libraries, not the core language itself.
In the mainstream professional JavaScript world, my advice is to escape as quickly as you can, and pursue things where the learning focus is on more interesting things than the arbitrary whims of the authors of half-baked (because they never have time to mature before they die) frameworks. If you can just live on the fringes and write JavaScript your way and not worry about constantly impending obsolescence of your entire technology stack (from Linux all the way up to your JavaScripty CSS framework), though, I'm sure you can have a great time doing it.
I'm writing a lot of C and Ruby these days, and I love it. I get to learn more about myself as a programmer, instead of more about other programmers as fly-by-night framework developers.
I write my own UI/MVC type code from scratch just because that's the way I roll and my requirements there are a combination of minimal, extremely performance sensitive and in many cases esoteric where I have to write the UI anway so it's not much work compared to forcing existing libraries to do what i want... but if had to I could replace it with some hip and upcoming UI + MVC library and still keep 95% of my core code completely independent and intact.
I think JS world feels like massive churn if 90% of what you are doing is UI UX etc, because that's the interface that can never sit still in the name of progress... either that or you (not you necessarily) are doing it wrong and not separating UI code from your application code (I've seen this happen quite a bit in ye olden angular days where everything becomes attached to angular for no apparent reason, and angular itself is the worst of OOP + MVC where everything is convoluted and difficult to follow).
If you build on others' frameworks, and those frameworks drop out of maintenance because the maintainers moved on to shiny new things, any security vulnerabilities or emerging incompatibilities with browsers can quickly prove ruinous for people who used those frameworks.
I wrote a SPA while working at a consultancy. It was actually pretty churn-proof the way I wrote it, but during one vacation day and the following weekend a couple people (including the boss) just rewrote the whole thing to use more faddish framework stuff. I don't work there any longer, but since then (about 2016) they've probably had to effectively rewrite it twice if they kept up with that approach.
That's what I mean by "constantly impending obsolescence".
I jumped into React early-on (5 years ago), and it's still going strong, and has been for way longer than Angular / Backbone / ExtJs ever did.
I wouldn't say Express is abandoned, I feel it's more that it's "matured". I mean what else can you add / improve?
State management is still an un-settled area; 2 years ago it seemed like Redux was the best choice, but GraphQL / Apollo is eating its lunch. However, when you think about it it still follows a similar conceptual model, but making it even more declarative: You have your "store" (the query result), and you dispatch "actions" to modify that store (the mutations). You just don't have to dispatch an action to fetch data from the server anymore; Apollo handles that for you.
It's true that JS churned very fast for a long time, but I'm seeing signs of it slowing down as problem areas become "settled" one-by-one.
My point is, you start to glimpse these overarching patterns as you interact with different takes, and you learn what works and what doesn't, ultimately empowering you to intelligently make tradeoffs or designs of your own. The chaos of web development is, IMO, because it was a new frontier, and a lot of inexperienced leadership occurred. This was compounded by bootcamps churning out people experienced only in Framework X, causing poor re-implementations of nearly _everything else_ inside Framework X.
It sounds like you feel like you _have_ to keep up with these things - perhaps someone else on the team is constantly insisting on migration, but they don't have to go through and tediously migrate and test everything. I'd suspect this lack of autonomy is at the core of your dissatisfaction. You can, and should, say no to a lot of trends, and if you do pick up something new, you should be able to clearly articulate why it's valuable, and these values should be more than superficial.
Another thing worth noting is that the release you work on today is the "legacy, painful" code of tomorrow. But that's a good problem to have - it got the job done. It just happened to get it done in one way, when there are really N ways, and so obviously the numbers game will work against you eventually, even in the imaginary case where the implementation is perfect.
I've been programming professionally for 20 years and doing exclusively frontend with React since about 2014.
After the whole React Hooks thing, I can't freaking wait to do something else; and I'm absolutely livid with their decision to promote Hooks.
They should have forked React instead of introducing that into a somewhat mature ecosystem. Already went through this fractured bullshit with Coffeescript, and a million other frameworks of the moment. The JS community just doesn't learn, and when you see a big player like Facebook making the same mistakes, there really isn't much hope.
Then I got into modern JavaScript with Reactjs, Nodejs, TypeScript, and other mess. Initially, I was excited because that's what everyone was and still is talking about and I love learning new things.
But it is too ugly in JavaScript land. People make fun of PHP but with PSR standards it is easy to enforce coding standards. In JavaScript land, everyone has their own standards, no easy way to enforce them, but most people don't follow their own standards. It is ugly spaghetti code mostly. Debugging tool is browser which makes it nearly impossible to troubleshoot when you are dealing with tons of minimized libraries. And even when you are dealing with simplest tasks JS developers start looking for libraries instead of just writing 5 line function.
I was ready to leave programming for management or other jobs but changed my mind and learning embedded systems, game dev, and some other cool techs. Hoping to transition to robotics or something else soon.
0.1 + 0.2 → 0.30000000000000004 $ irb
irb(main):001:0> 0.1 + 0.2
=> 0.30000000000000004
irb(main):002:0>
$ iex
Erlang/OTP 22 [erts-10.6.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe]
Interactive Elixir (1.10.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> 0.1 + 0.2
0.30000000000000004
iex(2)>
$ python
Python 2.7.17 (default, Dec 2 2019, 13:23:33)
[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.12)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.1 + 0.2
0.30000000000000004
>>> northrup@Topaz:~/Desktop$ perl -de1
Loading DB routines from perl5db.pl version 1.55
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
main::(-e:1): 1
DB<1> say 0.1 + 0.2
0.3
northrup@Topaz:~$ csi
CHICKEN
(c) 2008-2019, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.1.0 (rev 8e62f718)
linux-unix-gnu-x86-64 [ 64bit dload ptables ]
#;1> (+ 0.1 0.2)
0.3
northrup@Topaz:~$ sbcl
This is SBCL 1.5.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (+ 0.1 0.2)
0.3There are lots of other examples of doing it "right" (using more suitable numeric types) over at https://0.30000000000000004.com/ (alongside a bunch of examples that, to your point, just round, or to the GP's point, just stick to binary floats).
sbcl 1.4.16 uses single floats: https://ideone.com/ruw5qi
I don't know enough about Scheme to dig under the covers to see how it's being represented internally.
(setf read-default-float-format 'single-float) (+ 0.1 0.2) => 0.3
(setf read-default-float-format 'double-float) (+ 0.1 0.2) => 0.30000000000000004
On LispWorks 7.0 I get 0.30000000000000005 for double-float. Hmm.
The output of inexact numbers is typically truncated. In CHICKEN, you can use flonum-print-precision to tweak that. In an example, straight from the manual:
> (flonum-print-precision 17)
> 0.1
0.10000000000000001Aside from financial applications, there’s very little reason to care about the trailing remainder.
northrup@Topaz:~$ sbcl
This is SBCL 1.5.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (= (+ 0.1 0.2) 0.3)
T
* (= (- (+ 0.1 0.2) 0.3) 0)
T
"Financial applications" happen to be pretty common reasons for number crunching :)
Internally, they're probably both 0.30000000000000004 (depending on precision), so an equality check returns true.
It could also be that they're both 3/10 rational numbers, but given other tests in this thread that's likely not the case out the box.
northrup@Topaz:~$ sbcl
This is SBCL 1.5.8, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (- 0.3 3/10)
0.0
* (= (- 0.3 3/10) 0)
T
* (= (- 3/10 0.3) 0)
T
* (= 0.3 3/10)
NIL
CL-USER(3): (rational (+ 0.1 0.2))
5033165/16777216
CL-USER(3): (rational 0.3)
5033165/16777216 DB<1> say((0.1+0.2) != 0.3)
1