Not without making calls to c-bound processes that plug into the event loop or two independent JS run-times talking to each other which is also possible on the web through iframes or in Node via spawning child processes.
Single-threaded is desired behavior in the case of web ui and of Node, which is multi-process c/++ under the hood and JS responding to message queues.
It's pretty simple. Functions block. The messaging queue that triggers function calls in event-driven, setTimeout, XHR, talking to another JS runtime cases doesn't. So yes, you have to be careful to not lock up your entire server by processing images with JS function calls in the same runtime.
But the huge benefit you get out of this tradeoff is that you don't ever have to worry about two things trying to change something at the same time. Everybody is locked until your functions are finished and with async that doesn't typically take very long.
The synchronous lib calls in Node are mostly for convenience. I use them all the time when doing simple file I/O stuff where I just want to read something from a file, do something to it and stick it in a var or a new file. In a server or more complex application, however, you always want to use async callbacks.
setTimeout uses the same message queuing system as XHR, DOM events, or communicating with stuff that has its own stack like iframes or workers. That's why a function with a timeout of 0 will not fire until after it's enclosing function has popped. Functions block. Waiting for messages doesn't. That's the model for JS concurrency.
Or just use something like twig where the whole point is to have your view data sorted BEFORE you get to templating, which IMO, is the real source of clutter. Template systems should be boring, stupid, and clean. Making all of the things JavaScript has never been necessary. Definitely better than React or most anything else that's popular though.
Or just use a framework written by people with enough web UI experience to see Angular for the wheel-reinventing, best practice and performance-murdering charlatan that it is. Java teams love it. There should be no greater flashing illuminated red flag to a web developer than that.
There is no excuse for not knowing CSS as a front end/UI developer. That so few know much of anything about it nowadays, or think they don't actually need to is tragic, IMO.
Our industry has been overrun by resume-bullet-point silicon-valley-framework-coddling noobs/whores. I have always prided myself on staying up on the latest in core web technology. It's the reason I know what a !@#$ing tragic waste most of these idiotic frameworks are.
jQuery had the DOM covered and is in fact now redundant itself and could be managed with a much, much lighter lib that spends a lot less time normalizing assuming you're dropping support for browsers even Microsoft no longer covers.
LESS and SASS were good for vars and should have stopped there. Standard browser support is finally in the works for that. But you certainly don't need both and for FFS you're just making an unmaintainable styling mess using all of the other features, especially (noob, please), nesting which needlessly adds to selector count like nobody's business.
We do NOT need to ASP/JSPify the DOM. Keeping content/structure code separated from the behavior code was the reason proper front end devs were running circles around Java/ASP.net devs. What the fucking fuck is the point of adding your own custom tags to HTML, which already had a perfectly serviceable approach to binding behavior to it? Or creating an XML-like syntax you mix/match directly with your JS?
Silicon valley noobs, please. I had lazy loading scrollable tables that could handle 50,000+ lines of data back when Google Docs was choking on 2,800. This shit is not hard. Stop wining and spend the time you apply to learning frameworks with next to no core technology understanding to actually learning the technology you have before you start adding pointless layers that solve nothing on top of what's already there and you'll be shocked at how not-hard it can really be.
Or let's not. Let's load a massive freaking ridiculous CSS and JS library by the Twitter devs, because, yes, surely they know through their work with a site that essentially boils down to a single text area, a great deal about handling complex layout and UI concerns.
AMD for a web app? Okay, I can see it, certainly for non-trivial SPAs , which NOT EVERY SITE NEEDS TO BE. But first, how complicated is this web app? If not-very, why were people struggling with linking scripts in the right order? Why did they need to link so many damn things to get the job done in the first place?
And FFS, it's just "data-binding." Calling it "Two-way" is redundant and makes you sound like a jackass who doesn't know what the fuck is actually happening. And it's just a pattern. And not a very hard one to implement.
MVC and MV? are great. Really, whatever the fuck keeps data separated from an app layer from your DOM-handling is fantastic. Frameworks that make it easy to follow such patterns in a way that all developers can become familiar with are great too. But sweet JavaScript Jesus why won't they just stop there?
We used to laugh at Java developers. What the fuck are we doing to ourselves? Why haven't I gotten an honest to god core web technology or native JavaScript question at an interview in like 3 years? We have indeed, ruined JavaScript.
Where are you interviewing? All I get is Angular and React questions for interviews where I stated up-front to the initial contact that I'm no expert on either and have tended to stay focused on core technology developments when studying on my own time.
That's where MS tends to bug me. Why wasn't that fixed within a few hours of somebody discovering the problem? I ran into a similar issue on an app I just wrote that spits out CSVs. I googled, found a stackoverflow post about how to escape CSVs properly with Excel in mind, and fixed it. One primarily JavaScript dev and maybe an hour of testing, diagnosis and repair.
Alright so somebody with experience in a wide variety of DBs help me out here. Are the enterprise solutions really any more scalable than something like postgresql or is it more that they're more accommodating an enterprise mentality where you'll tend to run into more skill level diversity on the extremes and team A often doesn't necessarily have team B's expertise at stuff? By accommodating of course I mean willingness to take a buttload of money to help teams out with problems when needed and/or to blame when their mistakes explode in their faces and to never ever try to tell anybody that they're doing it wrong once VIPs with enough hit dice are invested in that sort of thing.
I do gather that a lot of DB admins that aren't very political about it do in fact respect MS SQL for some of its more competitive features. I'm just wondering if there's any reason to start with it for a low-cost startup scenario that could ultimately result in a non-trivial but fairly straightforward DB schema with potential for being used by very large institutions (universities at the largest I'd imagine).
I'm ignorant enough (primary experience is in web UI) that I'm leaning towards postgresql because I like the way the Django guys think and they seem to dig it. Also the no-nonsense license and yes, the not-profit-motivated thing is nice when backed by a strong core group which I gather postgres has.
But do the enterprise DB solutions handle severely massive amounts of scale better for some reason? Or is it more that they're culture-friendly to the sorts of companies that typically handle DBs of this nature?
I wouldn't let it anger you. I care about quality but every for-profit-company development team I've been on, I was forced to hold my nose at some point/many points/constantly due to some feature demand(s) that had nothing to do with providing a higher quality product and everything to do with either a customer and/or a manager that was a complete and total moron.
How do people get as hung up on browser features as much as they do anyway? I hardly use bookmarks anymore. I'm a web UI dev and I don't know half the shit Chrome does that's not development related.