Until you're working on a project where the turtles eat the errors... Funny story, that's how I've been describing the issue with how errors have been handled on the project I'm working on, where there are SO many areas where errors are just ignored... so they don't propagate up the chain/stack... doubly annoying in a node environment where it's all supposed to be error first (as in the first thing you think about an…
I was describing the problem as "turtles all the way down, except the turtles are eating all the errors, and the rabbits can't find them"
honestly, in JS/Node, I find it easiest to use a SQL adapter that can handle template strings as parameterized queries... const results = await sql.query` SELECT ... WHERE foo = ${bar} `; if (!results && results.length) return; await myQueue.add(results); Which works unbelievably well... There's not nearly as much need for boilerplate/translation layers in what is already a dynamic environment. I wrote a wrapper for…
Maybe I'm missing something, but that looks like SQL Injection ready to happen.
sql.query is a function that will receive two arrays, one is the strings part, the other is the injected values... the template processor takes those arrays and turns it into a parameterized query to the database.
IMO react is a big step backwards. Adding an abstraction layer almost never produces a better result, it just makes things more complicated.
I'm glad you added the qualifier "almost" because, even in low-level C, you're typically sitting on about 4 layers of abstraction: C -> ASM / byte code -> machine code -> primitive CPU operations
That's what I'd call a good abstraction. You can write in c, debug in c and very rarely (if ever) be forced to know what the lower layers are doing.
All these javascript and css transpilers however, they force you to know the higher level, the lower level and many of the intricacies of how one translates to the other.
Yes. I feel like we're in the dark ages right now. JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very quickly. Impossible to refactor. CSS - Also becomes impossible to manage. Who knows if the class you wrote is or isn't being used in HTML or JavaScript somewhere. Same problem, read-only, it only gets bigger and more unmanageable. HTML - At the heart of it, the fo…
If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks: * HTML * CSS * JS * A server-side language (eg Python) * SQL And then come the (leaky) abstractions on top of them: * A framework to make JS bearable (eg Angular) * A framework to make server-side bearable (eg Django) * A framework to make CSS bearable (eg Bootstrap) .…
+ A framework to make the web app framework more suitable for API development (eg Django Rest Framework)
You probably do not have the complexity level of these companies either. To me js and css are kind of manageable, a bit the same way as python: use strongly enforced linters forbidding anything ambiguous, do not jump every other day in a new sexy bandwagon, and do not let one line of code commited in without an automated test running it on a ci machine. What I found harder to manage is the young FE devs themselves: f…
> What I found harder to manage is the young FE devs themselves: for them it seems every new project, or every new view in the same project, is the opportunity to use a completely different, new toolset. Oh, and some new syntaxic sugar candies supposed to "save" a couple of keystrokes (which is the worst reason you can find to use a new syntax requiring its own tools). I find this very dangerous, especially when the…
As an employer I would be negatively surprised if a candidate for FE never heard of react, angular, etc. But I also see a red flag of the candidate were to assure me to be knowing all of them bottom up. That would mean a lot of toy projects and unstable personality, if not plain lies. I'd be looking for someone able to work for some years on a code base, grasp its stack, improve the overall structure, quickly find and fix bugs in a sustainable way, etc.
The amount of breakages I get using my static site/blog generator has my leaning toward worst ever. If that's any indication then anything actually complicated would be breaking all the time.
This doesn't sound like a NodeJS problem.
I'm not sure if it's nodejs or the various npm packages are to blame, but a problem with the ecosystem node lives in is a node problem.
Because it has to do something nothing could everdone before ? Unites the worl, provides collaborative environment. So it needs time to evolve. You will hate it less overtime
Brave, Slack, Atom, Popcorn Time, I'm sure there are many others. Electron ( http://electron.atom.io/ ) is becoming a popular framework to use.
Brave is a web browser, so I'd give electron most of the credit for making that work. Popcorn time I don't know anything about. Slack and atom though? Both are simple client UI's and both have much less bloated alternatives.
Yes, admittedly, none of these are that complex. I thought Visual Studio Code was built ontop of Atom, but I might be wrong. Both built on Electron anyway - which was originally part of Atom.
Technical: * Multiple browsers that respond to the same code slightly differently. * Multiple platforms that all need to be supported. * Countless different screen sizes to consider. * Standards that aren't supported across browsers and platforms (and different versions of each in use) * Hundreds of undifferentiated web frameworks that all claim to do the same basic task better than each other. * Thousands of ways to…
What is your source for full stack devs being under paid? Or maybe a better question is what do you consider a low wage for a full stack dev?
I'd say a starting guess for determining low wage for full-stack devs is anything < (backend dev salary + frontend dev salary), using market averages by location. If you're going to have a single person doing the work of two, pay them accordingly. Otherwise, hire two people and lighten the load.