[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 20994



File: 1482338339954.png (55.05 KB, 300x166, ISSonLive_20160527_063040.jpg)

No.20994

Here we talk about reducing the dependency of JS on our websites.

For example, by replacing JS animationd with CSS animations.

  No.21007

That's a good idea. Last time I had to make an image slider, I made it using CSS because I think it is easier and simpler, even tough I know JS.

  No.21030

>>20994
I use noscript and I noticed recently that I don't have to turn on javascript for ns1.com to load and look pretty. It even has a few animations

  No.21032

>>20994
This may seem like a fairly noob question (More of a designer) but how would you replace jQuerys slideToggle function with CSS.

  No.21050

>>21032
By creating an animation that goes from max-height:1000px (more than the object's height is - you can change this with media queries) to 0. If you don't know how to do it I will post the code tomorrow (actually using a phone) unless a lainon does it first.

  No.21058

>>21032
>>21050
What I said was wrong (sorry). You can use transform: rotateX(90deg); inside a @keyframes with transform-origin: 50% 0%; but in some cases you should override different parameters of the element you try to make visible or invisible. For example, if you want to apply this animation on a paragraph, you'll have to make line-height, margin-top and margin-bottom to 0 first. If you don't do it, the object will disappear but the space where it used to be will remain.

Also, added some CSS animations on my blog yesterday.

  No.21272


  No.21278

>>21272
Thanks for those links

  No.21398

I guess this is the right thread to drop this. Reading this I definitely don't feel to work in WebDev if ever manager to get into IT :

https://medium.com/friendship-dot-js/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558#.9eyhh0sn2

  No.21399

>>21272
>youmightnotneedjs.com
>Requires js if you want the code to have colors
How ironic.

  No.21400

>>21398
>Imagine if [...] the car you drove to work had 291 parts. You’d be worried, wouldn’t you?
I'm pretty sure cars are made of more that 291 parts. Cars nowadays are pretty complex.

  No.21423

>>21398
$ tree node_modules/ | count
zsh: command not found: count
$ tree node_modules/ | lines
zsh: command not found: lines
$ tree node_modules/ | wc -lines
wc: illegal option — i
usage: wc [-clmw] [file …]
$ tree node_modules/ | wc -countlines
wc: illegal option — o
usage: wc [-clmw] [file …]
$ man wc
$ tree node_modules/ | wc -l
292

The pain, the cringe, and he HAD to document his incompetency at the command line.

  No.21425

>>21398
I had a hard time believing the image of Guy wasn't a joke by the author; the massive incompetency, faux seriousness, and immaturity of the JavaScript community is amazing to watch every couple of weeks, like a cartoon.

It's interesting how the leftpad drama is now being blamed on a rogue developer, when that's nothing close to the truth.

>>21423
I agree. I at first thought he had a point. I quickly realized he was simply incompetent, which really put a bad feeling into the entire rest of the article. Even though it's interesting, one gets the impression that this is exactly the type of person who shouldn't be telling actual programmers what to do.

  No.21426

>>21425
>>21423

I didn't care about this specific part but noticed he included the error nonetheless and though it was a way to "realistically" show how a npm app is deployed. But now that you highlighted it I'm kind of confused about it being a joke or not. There is plenty of commands I always forgot the syntax even after a decade (useradd, find, "special" mount), but damn, that's a lot of stumbling just to use wc.

To be fair I always took way more time to deploy a website than It should have been on paper. Like Python virtualenv drived me mad, but that's not on topic.

  No.21433

>>21400
>>21423
>>21425
>>21426
You do realize that article is satire, right?

  No.21434

>>21433
Yep. There's also this.
>I opened up babel-core in vim, then turned off my computer because Ctrl-C wasn’t exiting, then opened babel-core in Sublime Text 2.

  No.21464

>>21433
As the third post you replied to, I was wondering.

It's hard to tell with JavaScript. If you'd told me about the leftpad library before I was aware of it, I would've thought it was probably a joke.

  No.21465

>>21464
I think that's the point. Despite the obvious clickbait title, the author's gaffes and the surreality of having a picture of some dude in the source code to one of the most used libraries in node (it was actually added after that article as ASCII, by the way, with a test and all [0]), a lot of people would still struggle to understand if the article is a joke.

[0] https://github.com/babel/babel/pull/3641/files

  No.21574

A sort of showcase of what's possible without JS:
https://github.com/you-dont-need/You-Dont-Need-Javascript

  No.21618

As an aside, how far is it possible to go optimizing websites in general? I can usually keep my simplistic pages to less than 2 kB each, and then compress static content to reduce to less than 750 bytes. Has anyone had better results with a reasonably useful website?

This is actually plenty for many of the industrial applications I work on. But in certain cases shaving off 50 more bytes would be worth even the ugliest of hacks. For example, some networks can only transmit at less than 2kb/s even without contention. That is, take 5 seconds to load that 750B page.

Ironically, it might actually be faster to send only some JS, with the HTML/CSS stored ahead of time.

  No.21619

>>21618

Make sure you send your content gzip'ed. A simple modification of apache configuration files (or most any other web server set up).

That'll allow for anything sent over to be compressed. Of course this won't work well enough for pictures or any other media that's already been optimized within their own respective editing suites/tools, however, as for textual data. It'll be a great boon.

You can also use an HTML minifier to strip out any unnecessary white space.

  No.21625

The abundance of examples of how things often implemented in js can be replaced with css demonstrates one thing: We are replacing js with new methods to achieve the same things. Yes, it's fun to bring up all the pitfalls of the world's most hated language since COBOL, but the real problem is how too often websites favor form over function. The need for prettily animated custom-rendered slider toggles increases the hardware requirements for what can be seen as a baseline acceptable web browsing experience.

Yes! Down with js! But not by replicating all the ills of the web in something that's not even supposed to be a programming language!

not like this

  No.21629

>>20994
I'd love to see sites that look pretty without client-side scripts. I'd be all over noscript if it didn't break half the websites I visit

  No.21632

>>21625
>but the real problem is how too often websites favor form over function.

oh shut up. The point of a website is to convey information, and like it or not information is better conveyed in pretty formats. Form = function.

  No.21640

>>21632

The point of a website has long been what ever that website wants that point to be.

>>"oh shut up"

Uh-huh right.

If you think a little past your own a e s t h e t i c bubble, you'll realize what the web has become. The most platform independent way to communicate applications using a mostly unified UI api (HTML5/CSS).

>>21625 has a point. If you look at any benchmarks regarding keyframe css animations over lets say programmatic Javascript, it introduces latencies and performance issues. You've completely missed the forest for the trees with what this lain has said. It's not that "oh the pretty lights" should be stomped out of the web experience. It's the way we're going about it. We're contriving new ways to remove something that is perfectly suited to the experience. And even if we use the most performant option it's taking its toll in performance.

Personally I believe that it isn't inherently the technology that bloat, but rather, as is usually the culprit, inexperienced programmers that aren't keeping an eye on the UX. Some pretty horrific things are being done with JS (and CSS) in terms of performance. Very few webdevs will properly tune their website to be peformant across the average UX case. Pick and choose: either the webdev is too lazy to test their site across several browsers and platforms, or their is a distinct lack of education in this testing process to begin with.

I believe that it's a mixture of the two, but mostly the latter. Any casual glance at most of these code academy like tutorials or videos gloss over the bare necessities unless you specifically search for keywords like "performant JS", or "UI/UX tutorials". Which is probably why there are specific degrees and specific job titles pertaining to the UI/UX in particular.

This same effect happens in the realm of concurrency. Most desktop programmers (where concurrency/threads are available) fail to test the peformance of their software. And when they do attempt to add concurrency they run into problems such as using the proper conventions such as contexts, locks, semaphores, non-blocking I/O, polling, etc.

I'd say a more accurate description of things is Form = UI(function)

If we're thinking about closures.