The state of web development
-
Considering that hash collisions would be less probable than RAM or northbridge failure leading to the kind of filesystem corruption which could have the same outcome, I'm not fussed about hash collisions.
Also, have you seen the state of saturday morning kids' cartoons lately? I suspect they'd take less emotional damage from those German productions you mention, just quietly.
-
huge goat-sucking mountain range of excrement
But native mobile apps are the next goat-sucking mountain range of shit.
What is your beef with goats? they are cute and marvelous, they eat anything (have seen them eat from carpet to cardboard) and somehow manage to transform it into delicious milk, true mother nature
-
Yeah, none of them is bad but they get deprecated so damn fast.
-
We all know the issue here is JavaScript. Let's switch to activex and make vbscript on web a thing! Let's get rid of JavaScript!!!
Filed Under The BAD IDEAS Thread, BAD IDEAS,
-
Let's switch to activex and make vbscript on web a thing!
Fuck off. I had to debug a
classic ASP legacy app in VBScript just last week.
-
What is your beef with goats?
Nothing. I like goats. Especially when they knock over the children holding the food packages in petting zoo.
My daughter learned pretty quickly that watching other kids getting thrown on their ass is much more fun than actually feeding the animals.
-
That's girls for you. My sons would find being knocked on their arses by a goat to be the apex of amusement.
-
There's a false dilemma hidden here though.
Imagine that with low level C, a single developer can make a product in 100 hours that has an average of 3 bugs, and with the new tool the same developer can make the same thing in just 40 hours but it will have 8 bugs. Is the tradeoff worth it? Yes, no, depends?
Here's what you should ask instead: what if you told that developer to do it in 60 hours instead of 40, plus an extra 20 hours of QA? You'd probably get an even better end product, and you still saved 20 hours.
Just because a tool can be used to make things really quickly, doesn't mean you have to do it, you can still spend some extra time being careful.
I suppose some tools really can't be used to make good products, which does suck, but I haven't seen many cases of that.
-
1) You do not need to hit birthday paradox levels of probability, even a minuscule chance [granted higher than alpha particle hits, lightning strikes, catching fire and whatnot] would have major ramifications.
Don't hold your breath waiting for it to happen. Seriously. You've probably got far more to worry about from that list of disasters than anything in a dedup algorithm that uses SHA1, let alone the crazy low probability with SHA512 (where you're comparing with the earth spontaneously turning into a black hole when a strangelet hits it and other such crazy things).
Worldwide, there might be a few collisions a year across all data. The chance that you'll see the two things that actually collide on the same network segment at a point when you're expecting that hash…
-
Don't hold your breath waiting for it to happen
For random collisions I completely agree...but the "crypto secure" part does concern me. Without going into my specific reasons, lets just say that many crypto systems once thought secure have fallen, and there have even be exploits against SHA-512 that have reduced the number of attempts (though still huge) below expectations.
Remember the diligence with which something is attacked is directly tied to the value of breaking it...plus there would be other ramifications if SHA-512 addressible blocks was to happen...
Consider a key takes 16 bytes - a block is 4K, so the ratio is 256:1....This means that a current 6TB disk would hold 1.5 Petabytes of effective information with just keys [of course you would want some local cache for performance, off-line, etc...
-
Consider a key takes 16 bytes
A SHA-512 “key” takes 64 bytes. The “512” is the number of bits in the digest. ;)
-
Here is some prediction of the evolution of web technologies:
(by the way, why does some sites insist to redirect to HTTPS? I want to watch a publicly available video, why does the connection need to be encrypted?)
-
A SHA-512 “key” takes 64 bytes. The “512” is the number of bits in the digest
You are, of course, correct...I was abusing the term "key" as in what would be used as the key to a hash table to retrieve the appropriate datablock...
-
The traditional embedded systems are still around, those that you have to write in C and occasionally Assembly, but now it is the low power consumption that keeps them in business.
For us it's generally cost for the kind of embedded systems you would probably define as traditional. Most of our products wouldn't be viable with an ARM SOC in them, the cost point is so tight we had to move from Microchip to ST for our little 8-bitters. Although, in truth, porting was pretty painless, ST's documentation sucks though.
Also, traditional design still has a good foothold in very specific areas like safety-critical. I'm doing an DAL-C design at the moment that uses the lovely TI Hercules and that's in plain C with no RTOS.
I have seen people refer to phones as embedded systems, which is stupid they are hundreds of times faster and more powerful than my first desktop.
It's getting very blurry these days. Personally I consider something embedded if the processing element isn't the sole focus of the device (it has sensors, displays, effectors etc.. as major defining points of it's function) and that most people wouldn't call it 'a computer' to eliminate the tablets. I wonder if someone like the IET/IEEE have a formal definition?
-
I suppose some tools really can't be used to make good products, which does suck, but I haven't seen many cases of that.
You don't do much javascript, I gather?
-
(by the way, why does some sites insist to redirect to HTTPS? I want to watch a publicly available video, why does the connection need to be encrypted?)
Beca...
discourse... why...
Because perhaps you don't want people to know that you're watching that video. Perhaps because the servers are hosting some privacy-critical thing like a message board for refugees and they're not using SNI, so refugee traffic is masked by your video traffic. Because SPDY and HTTP/2 only work with TLS, thanks to Google's manacled fist and Mozilla's leather boot. Because that's the new default, and the site owner hadn't bothered to change it.
-
Worldwide, there might be a few collisions a year across all data.
With SHA1: conceivably. SHA512? Nope.
-
(by the way, why does some sites insist to redirect to HTTPS? I want to watch a publicly available video, why does the connection need to be encrypted?)
Because some other folks think that anything and everything is a valid attack target, including your attempt to watch said publically available video. sigh
Nation-state attackers are the last thing computer security ever needed to deal with...
-
Going back to the OP, and quoting:
Despite these various cruft-reducing features, I still believe this is an area ripe for innovation in the browser space. Why is it that as a publisher of articles your only real monetization option is injecting bulky ads that produce a worse experience for everyone?
Why, oh why, do the marketoids think that advertising should basically do the equivalent of shouting at the top of its lungs over the show you're trying to watch? That's the
right there -- there's nothing inherently wrong with text or a static banner image for an ad, and neither of those need JS to power them, but web marketoids are a bunch of half-brains who think that making a pop-over auto-play video (with sound, of course!) or some other equivalent JS-powered (or worse, Flash-powered) heap of rubbish is better at getting people to get your message than some carefully crafted ad copy could be?Filed under: 99.9% of web adverts are cop-outs that show the ineptness of their "designers"
-
This belongs here:
-
publically available video
Well, is the video really publically available? Or is it just a gateway (http:) to the actual availability (https:)? Pedantic perhaps...but there are some considerations...
-
Well, is the video really publically available? Or is it just a gateway (http:) to the actual availability (https:)? Pedantic perhaps...but there are some considerations...
Given that the video does not require authentication to access -- it's still publically available, even if it's served over HTTPS.
-
You don't do much javascript, I gather?
As has been said so many times before; there is very little wrong with JavaScript.
Your beef is with DOM. And while they're often encountered in an unhappy / unholy marriage; DOM != JS
-
Why, oh why, do the marketoids think that advertising should basically do the equivalent of shouting at the top of its lungs over the show you're trying to watch?
Tell me; have you ever been to an old-fashioned open air market?
-
Tell me; have you ever been to an old-fashioned open air market?
You aren't exactly trying to sit down and read the paper in the middle of said open-air market, no? That'd probably be a good analogy for what the marketoids are trying to do to the Web.
-
Given that the video does not require authentication to access
But they do require authentication - the certificate which authenticates that the machine which will receive the video is the machine that provided the certificate. What they do not have is selective authentication, nor do they have differential authorization [that we are aware of]....
Why would this possibly matter??? Consider that the SAME SSL certificate will be presented for each unique workstation no matter what content they access. With HTTP: this would not happen.
-
But they do require authentication - the certificate which authenticates that the machine which will receive the video is the machine that provided the certificate. What they do not have is selective authentication, nor do they have differential authorization [that we are aware of]....
No, you have this bass-ackwards, and TR
is you. The client (i.e. the machine receiving the video) is authenticating that the server is a trustworthy (for TLS definitions of "trustworthy") machine by dint of it having a valid certificate traceable back to a known Certificate Authority. The server is doing nothing to ascertain that the client is not presenting a false identity, or any sort of identity at all!
-
- brain dead type coercion
- function-scoped variables
- globals out the ass
noinsane type annotation system- typeof everything is object Object
- callback hell
- everything else
There's a reason why there's a new web framework out every couple of months, and the reason is simple: Javascript is unmaintainable. It's easier to throw out a js project and start again than to ever get around to polishing off its rough edges.
-
brain dead type coercion
The actual rules are quite simple and the type of degenerate cases you have to cook up to prove it 'brain dead' are not how you would write day-to-day JS. If you want brain-dead non-intuitive type coercion, try PHP instead.
function-scoped variables
Hi, let me introduce you to the
letkeyword.globals out the ass
Let me introduce you to ES6 modules, CommonJS
requireand AMDdefine/require.Long before those arrived on scene a common and well-established practice was to wrap modules of code into immediately invoked function expressions and manually export only a limited set of entry-points into your code to the global scope.
Also, it's DOM and the browser implementation of JS that decided on having the global object be the DOM window object. That's strictly not part of the language.
insane type annotation system
That's because the annotation system is meant for aspect-oriented programming and not for declarative annotations in the vein of C#'s
[Attribute]annotations.typeof everything is object Object
That's because you're supposed ot use
instanceofto determine what type an Object is. Thetypeofkeyword is strictly to find out what primitive type (or Object) a value is. Also,typeofreturns just"object". What you're thinking of is the so-called string tag"[object Object]"produced byObject.prototype.toString. And that actually returns different values for built-in Object types, e.g.,"[object Array]"for an array or"[object RegExp]"for a regular expression...Having said that: ES6 is going to give you a means of overriding the base
Object.prototype.toStringimplementation of string tag generation via theSymbol.toStringTagsymbol and nothing is preventing you from implementing a regulartoStringmethod on your own objects to override the one inherited fromObject.prototype.callback hell
An artefact of mis-use (or rather; complete lack of) user-defined flow control structures for async operations. You cannot really fault the language for not providing those, as asynchronous continuations were never part of its original design scope. And either way, ES6 and 7 are fixing that with generator functions, the
yieldkeyword and later on theaysncandawaitkeywords.You can fault Joyent for the single biggest flaw in NodeJS's design here: centering on callback continuation style programming when superior alternatives like Promises/A were already a thing.
everything else
You know; I take it back. Your beef is not with DOM. You're just an idiot that believes JavaScript is still stuck in 1999 and hasn't advanced since.
-
The server is doing nothing to ascertain that the client is not presenting a false identity, or any sort of identity at all!
And this is just as well, or http://www.youtube.com would not work at school; it's actually my proxy box that makes the now-mandatory https: connections to youtube, relaying those over http: to the workstations.
-
Why, oh why, do the marketoids think that advertising should basically do the equivalent of shouting at the top of its lungs over the show you're trying to watch?
From their point of view, the show you're trying to watch only exists to give them an opportunity to seize your attention. Why bother putting out baits if you're going to leave your traps at home?
-
The server is doing nothing to ascertain that the client is not presenting a false identity, or any sort of identity at all!
It's possible to force clients to present auth tokens as part of the SSL setup, but it's really quite uncommon because getting browsers set up with that sort of thing is a total PITA. It's more common when clients aren't browsers (e.g., B2B SOAP services, where it is one of the very few relatively portable techniques).
-
It's possible to force clients to present auth tokens as part of the SSL setup, but it's really quite uncommon because getting browsers set up with that sort of thing is a total PITA. It's more common when clients aren't browsers (e.g., B2B SOAP services, where it is one of the very few relatively portable techniques).
Yep. I was referring to the common-case since that was the case @TheCPUWizard seemed to be confused by.
From their point of view, the show you're trying to watch only exists to give them an opportunity to seize your attention. Why bother putting out baits if you're going to leave your traps at home?
Yeah, and their point of view is rather self-defeating IMO -- because yelling over the top of the show would drive their targets away.
-
Yeah, and their point of view is rather self-defeating IMO -- because yelling over the top of the show would drive their targets away.
But their message is soooo important that surely those wonderful members of the public will be only too happy to watch it and then go off and buy the product immediately? After all, the show is nothing like as interesting as OCP Drain-o Revolution Pink, the cleaning solution for today's woman-about-home!!!!!
-
It's a drain cleaner and a cocktail!
-
-
As has been said so many times before; there is very little wrong with JavaScript.Your beef is with DOM. And while they're often encountered in an unhappy / unholy marriage; DOM != JS
You mean people have a beef with the part of JavaScript that Netscape created to manipulate the browser window? The one that people hate so much that the standards body for ECMAScript tries to disavow that it was ever part of the language?
Tagged as: ECMA isn't Big Brother and some of us remember that we weren't always at war with Eastasia
-
Actually, if they don't clear your session cookies before log-in and don't bother to mark the cookies as Secure, it'll make the website open to certain type of attack.
-
If you want brain-dead non-intuitive type coercion, try PHP instead.
☑ “Javascript is bad, but at least it's not as bad as x”
Let me introduce you to ES6 modules
☑ “Javascript is bad, but a different language that is derived from Javascript is better”
Long before those arrived on scene a common and well-established practice was to wrap modules of code into immediately invoked function expressions and manually export only a limited set of entry-points into your code to the global scope.
☑ “Javascript is bad, but it's possible to work around that badness”
Long before those arrived on scene a common and well-established practice was to wrap modules of code into immediately invoked function expressions and manually export only a limited set of entry-points into your code to the global scope.
Sure, and what happens if you typo an assignment?
That's because the annotation system is meant for aspect-oriented programming and not for declarative annotations in the vein of C#'s [Attribute] annotations.
No, not ‘annotations’, type annotations. You know, a way to ensure a variable is of a certain type?
int x; String s;kind of thing? (That'sx = x|0; s = s+""for you lot).You cannot really fault the language for not providing those, as asynchronous continuations were never part of its original design scope.
☑ “Javascript is bad, but that's just because it wasn't designed to be good”
Your beef is not with DOM.
Hell yeah it isn't. The only reason I would ever want to use Javascript is to manipulate the DOM. If there were some other language that had the same first-class access to the DOM as js has, I would be on it in a heartbeat.
You're just an idiot that believes JavaScript is still stuck in 1999 and hasn't advanced since.
Look, I'm just saying what I see here. If you want to go to github and make 95% of the js libraries out there not be an unreadable stream-of-consciousness crapfest, by all means be my guest.
-
With js libraries it seems there's a new one every year that all the hipsters use and you should too.
I think you mean every week*
-
If there were some other language that had the same first-class access to the DOM as js has, I would be on it in a heartbeat.
Given the state of how the DOM is, you'd be hating on that language too. The DOM sucks in all languages.
-
Given the state of how the DOM is, you'd be hating on that language too. The DOM sucks in all languages.
Oh, I don't know. I could like the idea of having native C#-ish access to DOM elements, provided they would actually expose what they are and what properties they have while writing the code.```var myDiv = DOM.GetElement
("#divMain");` anyone?Or LINQ:
where div.Classes.Contains("header") select div;` No more jQuery.
-
If there were some other language that had the same first-class access to the DOM as js has, I would be on it in a heartbeat.
Their used to be. It was called VBScript. It was a bad idea. It went away.
... actually Silverlight had first-class access to the page DOM as well. It was a good idea. It unfortunately also went away.
-
JavaScript sucks independently of the Dom. It's a mess of compromises and half-baked features and, worst of all, it's not strongly typed. Developers love JavaScript because developers love unnecessary complexity. They love throwing legacy code out and starting fresh. JavaScript gives developers every excuse they need to cater to their half-ass whims. JavaScript is a bad language.
-
Blah blah, a CNN page showing a simple article makes 200+ HTTP requests and uses 2 MB of data. It sucks, but it's par for the course
Just out of morbidy curiosity, I jumped into an intranet Microsoft Dynamics CRM instance ("On-Prem Install," the salesman cooed with smug sophistication). ~125 requests and 10.5MB later, I had a dashboard of open Cases. About 3 minutes later, I hit "Refresh All" to get fresh data for all the widgets and it brought in another 3MB of data.
This is an application which has a huge cloud install base for its users. Microsoft's answer to other CRM solutions. I still can't imagine using it from a mobile setting without Wifi or some kind of native app whose primary job is reducing the amount of data it pulls from its server.
-
some kind of native app whose primary job is reducing the amount of data it pulls from its server.
It has a (separate, not "responsive") mobile web profile and it has native apps. They pull down fewer items at once, and don't load form definitions if you haven't customized them. If you have customized them, well, it kinda has to.
-
JavaScript sucks independently of the Dom.
Yes. The crazy things with
thisbinding just gets my teeth on edge, and the horrible lack of key things like proper libraries in the majority of deployments just piles suck on suck.It's a mess of compromises and half-baked features and, worst of all, it's not strongly typed.
All languages are compromises. Every last one. A language is defined by its compromises. But the half-baking was particularly strong when JS was shat out.
The “strongly typed” thing is where I'll disagree with you. While typing is sometimes useful, it can also be a PITA when you're doing integration code, which is the level at which most scripting languages are used. Having to write lots of code to stick things together just because the component libraries you're coupling together to make the application don't derive from a common model hierarchy is just annoying. (Even more fun is when they both claim to implement the same standard, but do so incompatibly…)
Mind you, I think the issue you're raising is actually that types attach to values and not to variables. And JS does some distinctly strange stuff in its type conversion operators. I don't like JS.
-
(by the way, why does some sites insist to redirect to HTTPS? I want to watch a publicly available video, why does the connection need to be encrypted?)
Because the NSA are probably noting the fact that you requested that video, and are using it to improve their estimated likelihood of you being a terrorist, dissident, or "radicalized American".
-
The “strongly typed” thing is where I'll disagree with you. While typing is sometimes useful, it can also be a PITA when you're doing integration code, which is the level at which most scripting languages are used. Having to write lots of code to stick things together just because the component libraries you're coupling together to make the application don't derive from a common model hierarchy is just annoying. (Even more fun is when they both claim to implement the same standard, but do so incompatibly…)
That's a red herring re: strong typing -- Lisps and Python are strongly dynamically typed languages, and work quite well that way.
Mind you, I think the issue you're raising is actually that types attach to values and not to variables. And JS does some distinctly strange stuff in its type conversion operators. I don't like JS.
I think he's conflating strong typing and static typing as well -- and JS sloppy typing is neither.
-
This post is deleted!
The Birth & Death of JavaScript
