Pherdnut

I just realized I totally managed to 100% skip Blu-Ray.

Yeah, this is more like the used car dealership noticing that a lot of their clientele drives Toyotas. SPIES!

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.

Isn't kind of the height of stupidity to attempt to secure transactions on any client-side app?

- a javascript developer

Check the news. Major DDoS attacks today since this morning in the US.

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.

Thanks a lot assholes.

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.

Okay, you can enhance the API that already exists for this I suppose but I'm not sure how you could write a library for that purpose.

Can't we all just agree to blame it on the sales guys?

But oh-so-handy for validating e-mail addresses.

Does it have to be common or just regularly enough encountered for it to become seriously irritating.

Booth-babe stuff aside, I thought the article was primarily about being non-technical at a startup.

You can write perfectly performant apps in most languages. The problem is often the communities that surround them. Node.js has some nice advantages but I wouldn't compare by performance next to C# and Java. I'd compare on community, language philosophy and typical code quality. Java and C# and the median developer level are awful.

This is brilliant.

I didn't say I recommended he come back to the US any time soon.

Facebook is pretty much 100% https already. Think about it.

A much shorter version of this article: "Quit Google. Quit Facebook. Quit Apple. Quit Microsoft. Quit Yahoo. Quit Skype."

Google doesn't set the standard for JavaScript. The ECMA does. Microsoft tried their damnedest to run things their way on the DOM API for over a decade(which, yes, is set by the w3c since it's not the core language) and it seriously tarnished their image with client-side web devs and designers to the point where people actually started doing something they hadn't done since the browser wars which was put up "Sorry, we don't support IE" on their web pages (no, not major corporations, but there was a bit of it going around spurred on by regular anti-IE rants from the Opera guys).

Not long after it came to that we got IE9. The first !@#$ing IE browser in over a decade to finally support the exact same DOM spec Navigator did in 2001.

So no, as long as there are multiple browsers and platforms no one entity controls JS. Google did create V8 which we all like a lot because it kicks ass and any time we want more performance we can bind to C but it's not the only non-browser option for running JavaScript. We've got Rhino and whatever the hell Gnome Shell runs and god knows how many other platforms I don't know about (just learned Gnome Shell scripts via JS yesterday)

So no, Google has no leverage to force any major changes in JS. They have made several attempts to introduce their own cheesy language paradigms that look/act a lot more like Java (because they are Java whores) and yes the down-compiled languages are all the rage (you are a fucking MORON if you use coffee script professionally is all I'm going to say on that), but Google most certainly does not and never will have more than a little bit of influence on JavaScript's design nor incentive to because it has a vested interest in preserving its core features so that we don't "break the web."

The argument that it needs to be smaller is hilarious. It is miniscule compared to Java or C# and runs with a fraction of the syntax. And why did the author link to an article on Dart in reference to this topic? Dart is nothing more than a butthurt segment of Google devs trying to replace JS because their largest endeavors with JS have demonstrated that they're completely incompetent at it. Their spreadsheet app craps out when rows reach the 10 thousands and they have no clue how to architect. They just write procedural JS when they're not trying to mimic Java with it.

I don't think I would want to be an ex-NSA agent with "asylum" in Russia or China right now or at any time in the near-future.

If they only move a little bit in just the right conditions during the winter, why do they maintain course for so long before making sharp turn and then maintaining that course for a long period of time? Wouldn't the wind have to be mostly blowing in the right direction for years during the winters and then suddenly start mostly blowing in another direction for years? Or is it maybe some subtlety in terrain variation that determines where they'll move?

So we want them to be more open but we don't want to host their open source code for all to see? Believe me, I'm sharpening my pitchfork and lining up my torches over this thing, but that just doesn't make any sense.

But we don't even know for sure yet whether they had a choice and how this all came about. They're not allowed to talk about it. They could compromise DuckDuckGo and they would be legally bound to not say anything either. At this point I'm just waiting to see if they take this seriously. If they don't. I have to find non-US-alternatives to practically everything I use.