|
i feel like a lot of webdev problems could be avoided if they just accepted that worse browsers deserve worse experiences
|
#
?
May 14, 2019 15:42
|
|
|
|
| # ? Jan 15, 2025 06:28 |
|
|
Just make it a spinner, it's done when it's done.
|
|
#
?
May 14, 2019 15:43
|
|
|
Corla Plankun posted:i feel like a lot of webdev problems could be avoided if they just accepted that worse browsers deserve worse experiences the most popular browsers are the worst so you have to be ok w/ limiting ur reach
|
|
#
?
May 14, 2019 15:47
|
|
|
but the problem really isn't browsers, its entirely that js is trash by and for trash people
|
|
#
?
May 14, 2019 15:47
|
|
|
Aramoro posted:Just make it a spinner, it's done when it's done. it has been a spinner for 5 years, i wanted to give the user a progress indicator for the initial load, because how hard can it be? turns out, web """""development"""""'s gonna web """""develop"""""
|
|
#
?
May 14, 2019 15:48
|
|
|
Corla Plankun posted:just check for chrome and divide progress by two & jump to 100% when done if it exists now we're talking Shaggar posted:but the problem really isn't browsers, its entirely that js is trash by and for trash people shaggar was right
|
|
#
?
May 14, 2019 15:58
|
|
|
Corla Plankun posted:just check for chrome and divide progress by two & jump to 100% when done if it exists Workout the response compression ratio and add it as a header to the response and use that to scale the progress bar. Now you're webdeving.
|
|
#
?
May 14, 2019 16:06
|
|
|
Aramoro posted:Workout the response compression ratio and add it as a header to the response and use that to scale the progress bar. Now you're webdeving. Yeah I was going to say, have the server send the uncompressed size in a header. Or just remove all compression lol
|
|
#
?
May 14, 2019 16:09
|
|
|
probably the easiest "fix" would be to precompress all our files, calculate the average compression ratio and then if(isChome) bytesReceived = bytesReceived * chomeRatio. the progress bar would probably only be off by a few percent. and would give a reasonable approximation of the remaining loading time 
|
|
#
?
May 14, 2019 16:46
|
|
|
Wheany posted:it has been a spinner for 5 years, i wanted to give the user a progress indicator for the initial load, because how hard can it be? turns out wheany is whiny
|
|
#
?
May 14, 2019 17:04
|
|
|
CRIP EATIN BREAD posted:yeah but you get flexibility then. all you need to do is just write your own utility to wrap all that for you and boom, it works just like before. what if i told you that it's possible to make a flexible api without making common basic use-cases garbage
|
|
#
?
May 14, 2019 17:45
|
|
|
jk
Bloody fucked around with this message at 18:13 on May 14, 2019 |
|
#
?
May 14, 2019 18:00
|
|
|
Wheany posted:probably the easiest "fix" would be to precompress all our files, calculate the average compression ratio and then if(isChome) bytesReceived = bytesReceived * chomeRatio. the progress bar would probably only be off by a few percent. and would give a reasonable approximation of the remaining loading time lol that with all the frameworks and inept crap that webdevs poo poo out every week the problem of displaying an accurate loading bar isn't solved
|
|
#
?
May 14, 2019 18:03
|
|
|
Plorkyeran posted:what if i told you that it's possible to make a flexible api without making common basic use-cases garbage there's no good API written in javascript so you're not losing anything on that front.
|
|
#
?
May 14, 2019 18:04
|
|
|
Aramoro posted:Workout the response compression ratio and add it as a header to the response and use that to scale the progress bar. Now you're webdeving. train a deepdense CNN to predict the file size based on stock market and meteorological data and inject it into the page with tensorflow.js
|
|
#
?
May 14, 2019 18:07
|
|
|
CRIP EATIN BREAD posted:there's no good API written in javascript so you're not losing anything on that front. I dunno, parts of the DOM API work okay: JavaScript code:
|
|
#
?
May 14, 2019 18:14
|
|
|
im the parentNode
|
|
#
?
May 14, 2019 18:17
|
|
|
CPColin posted:I dunno, parts of the DOM API work okay: 
|
|
#
?
May 14, 2019 18:20
|
|
|
post.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode
|
|
#
?
May 14, 2019 18:20
|
|
|
CRIP EATIN BREAD posted:there's no good API written in javascript so you're not losing anything on that front. the thing which that pile of garbage for fetch() is replacing is the following: xhr.onprogress = (e) => console.log(`${e.loaded / e.total * 100.0}% done`) xmlhttprequest on the whole is not great but that's a pretty reasonable and good way to expose download progress. forcing you to implement a general-purpose stream transformer just to get progress information is not.
|
|
#
?
May 14, 2019 18:32
|
|
|
Plorkyeran posted:the thing which that pile of garbage for fetch() is replacing is the following: xhr.onprogress = (e) => console.log(`${e.loaded / e.total * 100.0}% done`) but i mean, you implement a wrapper once, that does the work for you, and you can use it. you don't have to copy/paste the implementation every time, and the flexibility lets library authors put their own stuff together. i guess you're coming from the world where every little trivial thing is supplied in one of 10,000 dependencies in your node_modules but you'll be shocked to learn you can implement some of this stuff yourself!
|
|
#
?
May 14, 2019 18:40
|
|
|
I agree that a stream transformation seems relatively complicated for getting response progress I agree that you'll probably write that once and reuse it with low if indeed any effort.
|
|
#
?
May 14, 2019 18:43
|
|
|
CRIP EATIN BREAD posted:but i mean, you implement a wrapper once, that does the work for you, and you can use it. yeah that’s true a really good counterpoint to “maybe this api should actually be useful” is “just work around it what are you a baby”
|
|
#
?
May 14, 2019 18:56
|
|
|
okay, so i implemented the stream processor. it loving measures progress in uncompressed bytes holy loving poo poo 
|
|
#
?
May 14, 2019 19:27
|
|
|
CRIP EATIN BREAD posted:but i mean, you implement a wrapper once, that does the work for you, and you can use it. or instead of making literally every person who ever uses a lovely api have to write a wrapper to make it vaguely acceptable, you could just make an api that isn't poo poo to begin with
|
|
#
?
May 14, 2019 19:29
|
|
|
Wheany posted:okay, so i implemented the stream processor. loving l m a o
|
|
#
?
May 14, 2019 19:39
|
|
|
also, i was doing this for the bootstrap script, which loads the actual (several megabytes uncompressed) application script files. currently it just creates script tags and lets them load in the background while the browser shows a spinner using a css animation. i wanted to use the browser's native functions so that the script remains as lean as possible
|
|
#
?
May 14, 2019 19:41
|
|
|
speaking of webdev crosspost from cjs thread: cjs: could hear very friendly, soft-spoken, and well mannered co-worker forced to work on webdev lament quitely in the next cube over "hell! i've gone to hell! why won't you work you piece of poo poo?"
|
|
#
?
May 14, 2019 19:48
|
|
|
Wheany posted:okay, so i implemented the stream processor. I betchu fetch is implemented w/ xhr
|
|
#
?
May 14, 2019 19:52
|
|
|
lol if you trust any webdevs to correctly reimplement anything on top of a low level stream api
|
|
#
?
May 14, 2019 20:00
|
|
|
redleader posted:lol if you trust any devs to correctly reimplement anything ftfy
|
|
#
?
May 14, 2019 20:06
|
|
|
Wheany posted:okay, so i implemented the stream processor. at least you can now submit a bug report that might get fixed since there's no backcompat issues because no one uses fetch
|
|
#
?
May 14, 2019 20:06
|
|
|
does anyone know what im supposed to do if i still want to display my component in angular despite not reciving data for my bindings?
|
|
#
?
May 14, 2019 20:18
|
|
|
HoboMan posted:does anyone know what im supposed to do if i still want to display my component in angular despite not reciving data for my bindings? I'm not sure what you mean. Like you want a blank component to show up despite having no data or the data not loaded yet?
|
|
#
?
May 14, 2019 20:21
|
|
|
idk about angular specifically, but generally for that kind of thing you use an empty model and then fill the model when the data arrives. as the model is updated with data the bindings should refresh the UI.
|
|
#
?
May 14, 2019 20:22
|
|
|
Aramoro posted:I'm not sure what you mean. Like you want a blank component to show up despite having no data or the data not loaded yet? yeah currently it's crashing on the bindings if there is no input but i would like the input to be optional i previously had the html for it wrapped in <div *ngIf="myData"></div> but my component is an editable form and i would like have filling out a new form just be calling it with no data HoboMan fucked around with this message at 20:39 on May 14, 2019 |
|
#
?
May 14, 2019 20:24
|
|
|
is resharper/dotcover a pos or is it just just loving with me today
|
|
#
?
May 14, 2019 20:26
|
|
|
like i want to cover my unit tests to see what poo poo is just completely untouched so i mash "cover unit tests" in the resharper test runner and the tests run and pass and then no coverage data shows up anywhere
|
|
#
?
May 14, 2019 20:27
|
|
|
i stopped using resharper after vs 2015 came out cause it was too much of a pain in the rear end and they refused to fix really annoying things that it did to break intellisense and code completion
|
|
#
?
May 14, 2019 20:34
|
|
|
|
| # ? Jan 15, 2025 06:28 |
|
|
gradle is loving piss trash garbage for rear end in a top hat fuckwads and i'm an rear end in a top hat fuckwad this week 
|
|
#
?
May 14, 2019 20:35
|
|
