Live data from Hacker News

In web design, everything easy is hard again

frankchimero.com

81–90 of 335 posts

Re: In web design, everything easy is hard again

#81
post #60

Earlier quoted context omitted.

I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is…

I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems. I agree that they are problems, but their impact on day to day use of the language is zero. If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to…

I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal.

I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard.

I guess worse really is better.

Re: In web design, everything easy is hard again

#82
post #25

Earlier quoted context omitted.

I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing…

Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up r…

I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.

Re: In web design, everything easy is hard again

#83
post #74

>simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw >[...] >I had to install a package manager to install a package manager. And that's coming from a designer, not a programmer. A few years ago I had to take over a project that required installing something like 6 different package managers, 2 build systems, and a dozen different languages (counting things like jade and coffeescr…

One of the best things about working for myself is that I write all my web stuff in vanilla JS. While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers. Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why the…

> I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them.

Corporations got owned here, though. The web ecosystem managed to create this whole big spaghetti of a toolchain, and now they get to command great salaries to keep it all working. A vanilla JS developer would actually be more of an replaceable widget or sprocket than a modern web developer, but modern is now "industry standard", so corps don't even know they're overpaying.

Re: In web design, everything easy is hard again

#84

Maybe somewhat related: can anybody guess what the idea behind the images in this article is? trans.gif is just a 1x1px invisible pixel.

It's lazy loading the images - when the page initially loads, it only loads one small image (trans.gif), and the file specified in the data-src attribute isn't loaded until you scroll near to the img tag. Specifically, it's using this plugin: http://luis-almeida.github.io/unveil/

The given use of that on frankchimero.com is bad.

If I use uMatrix then even enabling scripts for the site won't show the images.

Moreover, if the javascript is turned off completely, the proper approach for the given task is having the

    
and the images properly specified.

One of the images is just a PNG of an emoji U+1F632 (my guess). Another of the emoji of the cake. He could have saved on these two completely.

That leaves us with the tile svg and the 170K PNG for the face of the author, which should obviously be a 40K JPG.

Finally, the img tags on that page don't contain dimensions, whereas it's probably(1) better to still have them: https://www.computerhope.com/issues/ch001158.htm

Given the topic of the post (the need to keep things simple when making web pages), I consider these observations relevant.

1) Probably as I'm not in the business and I don't follow most recent developments so I don't know if the arguments from computerhope.com are obsolete by the most recent standards or implementations, so all relevant technical information is welcome.

Re: In web design, everything easy is hard again

#85

Earlier quoted context omitted.

A counterpoint is that people develop Stockholm syndrome over especially broken technology, and immersed long enough will no longer register just how ridiculous some aspects of it are.

It's very easy to take that knowledge you built up over years for granted and assume anybody who doesn't grasp it immediately is an idiot.

[deleted]

Re: In web design, everything easy is hard again

#86
>Easy is hard again

>JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.

I attribute much of this to the cargo culture that always dominated the webdev space. I lost count to how many seasoned devs (5+ year) I met who were telling me that "Framework A" is faster than vanilla JS and DOM with which they were built with, or array methods are for some reason faster than loops without function calls.

Another weak side of JS today is it being driven by "design by committee" and attempts to treat the patient by measuring the average body temperature of all patients in a hospital.

I put to doubt the level of basic CS proficiency of most JS framework authors. Some times they try to appear smarter than they are.

Re: In web design, everything easy is hard again

#87
post #32

Earlier quoted context omitted.

I came here to say the same thing. :) The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches. The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be bett…

You can't honestly propose XSLT as a programming language in a thread where half the comments are about how shitty JavaScript is. I mean, JavaScript isn't God's gift to mankind, but XSLT? I have a very hard time coming up with a worse programming language than XSLT, across all dimensions. INTERCAL, maybe? If XSLT had been proposed as a satirical esoteric programming language, people would've laughed and believed it.…

But XSLT is functional so that makes it awesome right?

XSLT 2 was actually usable. 1 on the other hand... it really did feel like a twilight zone sick joke.

Re: In web design, everything easy is hard again

#88

Earlier quoted context omitted.

I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is…

Both ESLint and TypeScript solve all of that except the integer thing. But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to compla…

Actually, in Python integers have no upper limit (sic!).

I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.

Re: In web design, everything easy is hard again

#89
post #25

Earlier quoted context omitted.

Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up r…

TypeScript has previously been recommended, so I will take a look. I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.

WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.

Re: In web design, everything easy is hard again

#90
post #40

Earlier quoted context omitted.

Why would yo want to triple (I guess even more) your work just to have a semantic title when you can use an alt-text?

But there's no alt text. The code looks like this: Everything Easy is Hard Again And is styled in such a way it's not visible. This is bizarre.

Bizarre? The h1 is probably there for SEO or screen readers.
Post reply on HN