|
Yeah, you have to read the docs before you can just start throwing them into your code all willy-nilly. AFAIK, there's no hidden gotcha's. I'ts just that you have to use them like the docs tell you to use them. Of course, you wouldn't think that if you just saw the syntax because, for better or worse, they look like regular ole' functions that you can just slap into your code wherever.
|
#
?
Sep 30, 2019 18:17
|
|
|
|
| # ? Jun 4, 2024 08:08 |
|
|
That reminds me of something I came across yesterday. https://wattenberger.com/blog/react-hooks It's a good article, but really I just thought the UI she has for code diffs is neat. Particularly when you hover the mouse over the...lines(?)...between the code blocks on each side showing the diffs.
|
|
#
?
Sep 30, 2019 18:20
|
|
|
99% of hooks gotchas are prevented by just using the ESLint plugin with rules for them. Create-React-App is even configured to fail to build if they raise any errors.
|
|
#
?
Sep 30, 2019 18:57
|
|
|
Thermopyle posted:It's a good article, but really I just thought the UI she has for code diffs is neat. Particularly when you hover the mouse over the...lines(?)...between the code blocks on each side showing the diffs. That does look super cool and the best that I can tell is that she is using prism+d3 to do it. Would have never occurred to me.
|
|
#
?
Sep 30, 2019 19:09
|
|
|
MrMoo posted:Does anyone know how to properly implement a texture atlas in modern THREE.js that uses geometry based UVs instead of hacking offset/repeat in the texture and cloning it's UUID? The latter now results in multiple texture uploads to the GPU. I don't know anything about texture altases or the fancy uses of texture buffers that are common, but don't these screenshots just make it look like a much simpler issue of common mistakes when plugging in the numbers for texture coordinates? Such as U and V being swapped or the wrong sign?
|
|
#
?
Oct 1, 2019 06:32
|
|
|
I fixed it by manually testing every combination of {0, 1} UV values,  It ended up with some unused values, or at least with no effect on the output. I guess the vertex order used within THREEjs for a PlaneGeometry doesn’t match what anyone else normally uses.WebGL is still making GBS threads it’s pants on performance though. At least the Chromium Team are pushing through daily updates for OffscreenCanvas. Performance in a WebWorker is more reliable. I’m down to 10 GL calls a frame, I’ve been reading on how to get this down to 1, but that looks a bit tedious, grouping the meshes by material. Some of the THREEjs demos on their home page I assume do this to achieve the low GL call rate. FYI: you can debug the JavaScript and view renderer.info.render to see basic GL API stats. MrMoo fucked around with this message at 14:45 on Oct 1, 2019 |
|
#
?
Oct 1, 2019 14:38
|
|
|
The Fool posted:That does look super cool and the best that I can tell is that she is using prism+d3 to do it. Would have never occurred to me. she's got perfectly good source maps being served up, you can go and look at it. as an enthusiast of web technology, I really don't love JSXing all the things. the individual blog posts are React components and... I mean, it's very very nice and it works pretty darn well but...
|
|
#
?
Oct 1, 2019 19:28
|
|
|
prisoner of waffles posted:she's got perfectly good source maps being served up, you can go and look at it. Agree with this. It works very well, but it's not ... nice.
|
|
#
?
Oct 1, 2019 19:38
|
|
|
Ola posted:Agree with this. It works very well, but it's not ... nice. Wait, you say you agree, and then say its not nice, but the person you're quoting said it's very, very nice! But anyway... prisoner of waffles posted:she's got perfectly good source maps being served up, you can go and look at it. How would you do it?
|
|
#
?
Oct 1, 2019 20:33
|
|
|
Thermopyle posted:Wait, you say you agree, and then say its not nice, but the person you're quoting said it's very, very nice! Seems there was a state lost in some reducer there. e: To be serious, React works drat well when you use it, but I don't like how it is to read and work with. It just seems so far removed from what is actually taking place in the browser window.
|
|
#
?
Oct 1, 2019 20:57
|
|
|
the end result is nice, but the guts are rather opaque. I'm not saying that the finished result isn't nice, but that I don't care for the implementation technology. why? 1. transpilation makes things opaque. she didn't have to serve up source maps and the input source and many (especially many companies) don't. 2. transpilation steps make it harder to reproduce a workflow and/or keep a workflow working. 3. JSX, aka "might as well be everything in JS", means that certain types of basically static information (styling, document structure) get stuck in the middle of a general purpose scripting language. usually when there's a functional division of concerns and appropriate languages per concern it's best to use the weakest language that fulfills your needs for each concern, lest The Script Get Complicated And Hairy. I know that this is not a novel take or especially insightful.
|
|
#
?
Oct 1, 2019 21:36
|
|
|
MrMoo posted:I fixed it by manually testing every combination of {0, 1} UV values, You should be able to do more than 10 GL calls a frame -- I can push up to around 5000 draw calls a frame at 60fps, so something sounds very off to me. Are you on SwiftShader or something?
|
|
#
?
Oct 1, 2019 23:30
|
|
|
prisoner of waffles posted:the end result is nice, but the guts are rather opaque. I'm not saying that the finished result isn't nice, but that I don't care for the implementation technology. Oh, ok. I thought you were specifically calling out using React components or JSX, but I think I now understand that your critique is the same whether it's React/Angular/Vue/whatever. (FWIW, I don't exactly disagree or agree, but I see where you're coming from now.)
|
|
#
?
Oct 2, 2019 00:52
|
|
|
prisoner of waffles posted:3. JSX, aka "might as well be everything in JS", means that certain types of basically static information (styling, document structure) get stuck in the middle of a general purpose scripting language. usually when there's a functional division of concerns and appropriate languages per concern it's best to use the weakest language that fulfills your needs for each concern, lest The Script Get Complicated And Hairy. Counterpoint here: using separate CSS and tag definitions for components (whether it's React or whatever else) loving sucks because CSS is awful.
|
|
#
?
Oct 2, 2019 04:42
|
|
|
i am semi-unqualified to speak and a semi-hypocrite here because 1. i've never had to do real heavy lifting in CSS 2. I actually liked using google closure compiler (via plovr) 3. next time I get a chance to do a hobby project I'm probably going to use typescript (one hypocrisy strike against me for transpilation) and native web components (actually consonant with the previously-expressed values).
|
|
#
?
Oct 2, 2019 15:25
|
|
|
Typescript is good for client side, since you still have to compile that either way, and Typescript's is the best compiler I've used. Unless you're using Typescript and Babel in which case you're just another one of those people that thinks it's totally ok to use every single toolset at the same time.
|
|
#
?
Oct 3, 2019 08:45
|
|
|
Babel is kind of a requirement to do typescript and react.
|
|
#
?
Oct 3, 2019 15:14
|
|
|
The Fool posted:Babel is kind of a requirement to do typescript and react. That doesn’t make sense, Babel is a subset of TypeScript functionality. How else would it work? You compile TypeScript/ES9 or whatever to ES6 then transpile to ES5 in Babel?
|
|
#
?
Oct 3, 2019 15:56
|
|
|
MrMoo posted:That doesn’t make sense, Babel is a subset of TypeScript functionality. How else would it work? You compile TypeScript/ES9 or whatever to ES6 then transpile to ES5 in Babel? It's entirely possible that I am missing something or things have changed since I did this, but as of a year ago when I was first looking at typescript, literally every write-up I could find had you using webpack+babel to get react+typescript up and running.
|
|
#
?
Oct 3, 2019 16:48
|
|
|
I don't use a compiler for client side stuff
|
|
#
?
Oct 3, 2019 16:50
|
|
|
The Fool posted:It's entirely possible that I am missing something or things have changed since I did this, but as of a year ago when I was first looking at typescript, literally every write-up I could find had you using webpack+babel to get react+typescript up and running. e: no, I didn't look hard enough before I posted - webpack-cli brings Babel in Munkeymon fucked around with this message at 17:03 on Oct 3, 2019 |
|
#
?
Oct 3, 2019 17:00
|
|
|
The reason to use Babel with Typescript is so that your code doesn't explode in browsers as soon as you want to use a library exclusively written in ES6/ES7/whatever.
|
|
#
?
Oct 3, 2019 19:16
|
|
|
Does Typescript preclude you from taking advantage of ES6 features? Holy poo poo
|
|
#
?
Oct 3, 2019 19:22
|
|
|
No, browsers can though.
|
|
#
?
Oct 3, 2019 19:31
|
|
|
Dumb Lowtax posted:Does Typescript preclude you from taking advantage of ES6 features? Holy poo poo No, but it doesn't compile non-Typescript things.
|
|
#
?
Oct 3, 2019 19:32
|
|
|
Roadie posted:No, but it doesn't compile non-Typescript things. Last I checked TS is a strict superset of JS, so it'll handle any valid JS, but not React's JSX. Or were you thinking of, I dunno, CoffeeScript?
|
|
#
?
Oct 3, 2019 20:22
|
|
|
Dumb Lowtax posted:Does Typescript preclude you from taking advantage of ES6 features? Holy poo poo Munkeymon posted:Last I checked TS is a strict superset of JS, so it'll handle any valid JS, but not React's JSX. Or were you thinking of, I dunno, CoffeeScript? Not all browsers support all ES6+ features. TS doesn't handle transpiling such features, babel does. When they hit approved status there's a few ES2019 proposals I'm using ASAP. Pipeline operator and optional chaining are high on my list of features that will greatly improve my day to day developer life and Typescript won't help at all during the probably years long wait between the features being accepted and browsers actually implementing said features. edit: Oh BTW, typescript does compile React JSX without the need for babel. Thermopyle fucked around with this message at 20:45 on Oct 3, 2019 |
|
#
?
Oct 3, 2019 20:28
|
|
|
I hate the idea of needing compilation and source maps just to use the built-in official syntax of JavaScript. ES6 stuff is more readable and has been the standard since 2015, so why can't whichever browsers that are so far behind get forced into niche usage territory at this point? Sounds better than adding a whole extra layer of abstraction in code execution, just to be inclusive toward those users. What's the most major ES6 feature that's still unsupported on a very commonly used browser?
|
|
#
?
Oct 3, 2019 20:52
|
|
|
Dumb Lowtax posted:ES6 stuff is more readable and has been the standard since 2015, so why can't whichever browsers that are so far behind get forced into niche usage territory at this point? Sounds better than adding a whole extra layer of abstraction in code execution, just to be inclusive toward those users. Force how? The passage of time will take care of it eventually but browser compat is a business decision (assuming a commercial project here).
|
|
#
?
Oct 3, 2019 21:24
|
|
|
Dumb Lowtax posted:I hate the idea of needing compilation and source maps just to use the built-in official syntax of JavaScript. ES6 stuff is more readable and has been the standard since 2015, so why can't whichever browsers that are so far behind get forced into niche usage territory at this point? Sounds better than adding a whole extra layer of abstraction in code execution, just to be inclusive toward those users. What's the most major ES6 feature that's still unsupported on a very commonly used browser? Safari on iOS doesn't support default parameters. :/ But whatever we decide is the most major feature not widely supported is just going to be a snapshot in time as of right now. Browsers always lag behind the ES standard. When every browser in use supports every ES2016 feature, we're going to be moaning about there not being widespread support for whatever ES2017 feature. Unless you're willing to be hamstrung by the whims of the browser powers that be, just throw Babel or whatever into your build process and don't worry about it again. Unfortunately, language features are not actually decided by the ES committees, they're decided by a bunch of different browser companies and they're always changing what they make available and each is making different decisions at different times about what is available. Like, I want to use the ES2019 proposal for optional chaining. JavaScript code:Thermopyle fucked around with this message at 21:52 on Oct 3, 2019 |
|
#
?
Oct 3, 2019 21:44
|
|
|
Thermopyle posted:TS doesn't handle transpiling such features, babel does. Technically Babel doesn’t either, they just ship a pack of polyfills. You can use those with ES5 targeted TypeScript output. I use Babel and TypeScript for different projects, certainly not together as a pipeline.
|
|
#
?
Oct 3, 2019 21:52
|
|
|
MrMoo posted:Technically Babel doesn’t either, they just ship a pack of polyfills. I don't think this is right. How would they polyfill arrow functions?
|
|
#
?
Oct 3, 2019 21:55
|
|
|
Thermopyle posted:Not all browsers support all ES6+ features. Isn't transpiling down to legacy browser speak what --target is for? And, yeah, while I was looking up target, I found the JSX option. Thinkin' MrMoo was right on this one and TSC has come a long way since I last used it. e: well poo poo 
|
|
#
?
Oct 3, 2019 22:02
|
|
|
Munkeymon posted:Isn't transpiling down to legacy browser speak what --target is for? I guess I should make the same disclaimer you have...I don't often revisit my project config boilerplate (it just works, I'm afraid to touch it!) so I can't say for sure what TSC does right now. So, take all of what I say with that in mind. Anyway, the "problem" with target in the past, in this context, is two-fold. (neither of which are show-stoppers). One, it just lets you target a JS version rather than JS features*. Like, if you target ES2016, you're going to end up with code using default parameters that work everywhere except mobile safari. (if you just say gently caress it and select ES3 as your target, you end up with sub-optimal performance in different scenarios) With babel you can select the actual browsers you're targeting. Secondly, it doesn't support all ES6+ features for transpilation. If you're using TS, you already have a build step and there's really no reason to avoid adding Babel. If you're using Babel, try TS...types are cool and good. If you're using neither, you're in a netherworld of features that may or may not be supported by the browsers people are using. * You can do something like this in package.json... JavaScript code:
|
|
#
?
Oct 3, 2019 22:20
|
|
|
TypeScript is cool & good except for when its compiler output goes completely off the tits. http://www.typescriptlang.org/play/...ggxQwIjJicm44kA this only happens when using babel, because it uses the "isolatedModules" flag or some weird bullshit like that, which means that multi-file compilation isn't allowed, so it has to fall back to normal, non-const enums, which means weird poo poo happens https://github.com/babel/babel/issues/8741
|
|
#
?
Oct 4, 2019 01:26
|
|
|
MrMoo posted:Technically Babel doesn’t either, they just ship a pack of polyfills. You can use those with ES5 targeted TypeScript output. You've confused Babel and core-js. core-js is a bunch of polyfills, Babel is a generic engine for translating syntax and preprocessing code.
|
|
#
?
Oct 4, 2019 02:03
|
|
|
Babel-polyfill is a package in NPM for general ES6 polyfills for ES5, “Babel” itself is the transpiler. You should realize webdev is a dump and the same name is used all over the place.
|
|
#
?
Oct 4, 2019 02:12
|
|
|
MrMoo posted:Babel-polyfill is a package in NPM for general ES6 polyfills for ES5, “Babel” itself is the transpiler. I'm sure I'm missing something, but I'm not sure how your point is related to the point that Roadie is making. Anyway, just to be clear, this makes it sound like they're unrelated packages that they just happen to use the same name. babel-polyfill is the official polyfill that Babel provided pre version 7.4. Now babel just directly includes corejs.
|
|
#
?
Oct 4, 2019 02:39
|
|
|
I is dumb, no problem. I'm not a webdev so I only pick up changes from this thread. It looks like Babel supports TypeScript now? Just to be even more confusing, and an odd situation. https://babeljs.io/docs/en/next/babel-preset-typescript.html
|
|
#
?
Oct 4, 2019 21:08
|
|
|
|
| # ? Jun 4, 2024 08:08 |
|
|
Yeah. It'll convert TS files to JS and do all the other stuff Babel does. Of course, it doesn't do type-checking so you still have to have tsc as part of your build process.
|
|
#
?
Oct 4, 2019 21:33
|
|