|
wonderful thank you! Looks like everything is working how I want it to
|
#
?
Nov 3, 2021 16:51
|
|
|
|
| # ? Jun 10, 2024 21:55 |
|
|
Any advice for somebody with a lot of UI/UX research and design experience who is looking to dip their toes more into the development side of front-end to help pad their resume? I know my way around Python, and have decent knowledge in networking in general, as well as a Masters in UI/UX research and design, but I still feel like my technical skills could be improved.
|
|
#
?
Nov 12, 2021 15:55
|
|
|
Gay Retard posted:Any advice for somebody with a lot of UI/UX research and design experience who is looking to dip their toes more into the development side of front-end to help pad their resume? I know my way around Python, and have decent knowledge in networking in general, as well as a Masters in UI/UX research and design, but I still feel like my technical skills could be improved. HTML/CSS/JS. Ideally learn those to an intermediate level then pick a framework (probably React or Vue) and learn that. There's a lot of tooling around CI/CD, building/packaging, etc, but I think with your background you'd be ok with just learning Git, and maybe the basics of Webpack and NPM scripts
|
|
#
?
Nov 12, 2021 16:37
|
|
|
Gay Retard posted:Any advice for somebody with a lot of UI/UX research and design experience who is looking to dip their toes more into the development side of front-end to help pad their resume? I know my way around Python, and have decent knowledge in networking in general, as well as a Masters in UI/UX research and design, but I still feel like my technical skills could be improved. My advice would be to force yourself to make a site without any server backend using netlify or vercel. Consume a baked json and go wild filtering and displaying info in different ways using and making components with Vue, React or Svelte.
|
|
#
?
Nov 12, 2021 16:40
|
|
|
What's the state of localisation libraries? If I just want to be able to switch strings with a dropdown, what's the most lightweight thing? I kinda like the look of https://github.com/ivanhofer/typesafe-i18n.
Chas McGill fucked around with this message at 17:33 on Nov 12, 2021 |
|
#
?
Nov 12, 2021 17:22
|
|
|
Gay Retard posted:Any advice for somebody with a lot of UI/UX research and design experience who is looking to dip their toes more into the development side of front-end to help pad their resume? I know my way around Python, and have decent knowledge in networking in general, as well as a Masters in UI/UX research and design, but I still feel like my technical skills could be improved. You can find a billion tutorials on medium for setting up a basic react app and then you can build some pages into it with your design experience. I would just start there (basic thing running) and then decide what you want to do. Edit: Facebook also has good react tutorials if you don’t wanna use medium (which I wouldn’t blame you for)
|
|
#
?
Nov 12, 2021 18:13
|
|
|
mitztronic posted:You can find a billion tutorials on medium for setting up a basic react app and then you can build some pages into it with your design experience. I would just start there (basic thing running) and then decide what you want to do. What's wrong with Medium? Or do you just mean the tutorials are hit or miss?
|
|
#
?
Nov 12, 2021 18:25
|
|
|
camoseven posted:What's wrong with Medium? Or do you just mean the tutorials are hit or miss? The quality of posts is hit or miss, which is bad for a site you have to pay for, and I'm aware of the irony here. Dev.to is a good alternative, but there's even more chaff because it's free, so you'll get a bunch of articles sharing the same background-filter: blur tip for a glassify effect or people repeating the same React vs. Svelte arguments.
|
|
#
?
Nov 12, 2021 20:17
|
|
|
Gay Retard posted:Any advice for somebody with a lot of UI/UX research and design experience who is looking to dip their toes more into the development side of front-end to help pad their resume? I know my way around Python, and have decent knowledge in networking in general, as well as a Masters in UI/UX research and design, but I still feel like my technical skills could be improved. 1. Design a UI or find a design you previously made and implement it with HTML and CSS. 2. Add interactivity with 3. Start over and rebuild it with React (if you're maxing out employability) or Vue (if you really don't vibe with React) 4. Convert all your CSS to CSS-in-JS 5. Convert all your CSS to Tailwind 6. Come back to the thread and argue viciously with us about what is the correct way* to do CSS. Congratulations you are now a front-end developer! *There is no correct way which is why most of us hop on to a new way of doing CSS that promises to deliver us from CSS hell every 2-4 years
|
|
#
?
Nov 13, 2021 06:58
|
|
|
camoseven posted:What's wrong with Medium? It’s better to use official documentation IMO. Medium seems more approachable if you’re new but everyone is different. Proposed medium because it has a low barrier of entry to start with. Hit or miss is part of it, though, definitely
|
|
#
?
Nov 13, 2021 07:01
|
|
|
Unless you have machinations to switch over to the dev side completely, I'd probably focus more on the HTML/CSS and just keep your JavaScript learnings to the most foundational level. Don't think it'd be worth investing time in learning React or Vue as a UX/UI designer. If you really want a leg up, I'd suggest you focus on mastering accessibility rules, especially as it pertains to HTML. Most devs I've worked with have never touched a screen reader.
|
|
#
?
Nov 13, 2021 13:14
|
|
|
This. As a UI/UX designer that can deliver implementable HTML/CSS that considers accessibility, you'd be worth you weight in platinum in most places I worked at. You can leave the business logic glue to us dev dweebs who can't draw, if that's not of your interest.
|
|
#
?
Nov 13, 2021 14:03
|
|
|
I have a flex row that contains two columns. The leftmost is much shorter than the right one. When I scroll down, I want the leftmost to stop as it nears the end of its height, and stay stickied to the bottom of the screen while the other column can continue to scroll downward. Making it sticky with "top: 0", makes it glued to the top, not letting me scroll to the bottom of its content. And making it "bottom: 0", doesn't seem to help in any way. Pretty sure I've fixed a similar problem before, but now I'm stumped.
|
|
#
?
Nov 13, 2021 15:56
|
|
|
I recently had to make automation tests for something I was not a part of developing, and since I’ve embraced @testing-library hardcore (got offered to help maintain a library about to be included the organization ) the pain of testing something that wasn’t developed with accessibility (and machine readability) is such a pain.Everything is so much easier if you just follow some very simple rules: - use real elements, not divs for everything - if you can’t use a label element wrapping or using the for attribute add an aria-label. An obvious example would be for icons, sure I could look for the element with the fa-Trash class and know I found the delete icon in my test. But how the hell is a screen reader to know that? - sprinkle roles where appropriate, like progressbar These things will be invaluable when writing tests, and means you are 90% or more done with making it accessible imho. And speaking of divs for everything, why do I see it so much from web devs? Is it some misguided attempt at having a CSS reset? And don’t even get me started on using float and clearfix. I find it very ironic that the solution to “never use tables for layout” required clearfix uses display: table; Thank you for coming to my TED talk!
|
|
#
?
Nov 14, 2021 08:55
|
|
|
If I’m someone who really enjoyed messing around with Elm for a while but now wants to learn a more mainstream (probably JavaScript/typescript) framework, what do you think would be a good fit? I really liked everything about Elm (functional, immutable, strongly typed, etc) except for the part where it’s one smart guy’s weird hobby and he never updates it.
|
|
#
?
Nov 14, 2021 08:58
|
|
|
zokie posted:And speaking of divs for everything, why do I see it so much from web devs? Is it some misguided attempt at having a CSS reset? Yes they just want an element to add styles to.
|
|
#
?
Nov 14, 2021 14:53
|
|
|
Yeah, it's "when in doubt" multiplied with laziness of learning about semantics.
|
|
#
?
Nov 14, 2021 15:34
|
|
|
Siguy posted:If I’m someone who really enjoyed messing around with Elm for a while but now wants to learn a more mainstream (probably JavaScript/typescript) framework, what do you think would be a good fit? React, by a long shot
|
|
#
?
Nov 14, 2021 16:01
|
|
|
+ TypeScript, so you can pretend you're still doing FP
|
|
#
?
Nov 14, 2021 16:04
|
|
|
I think I use divs for (almost) everything because the semantic elements seem to be based around making documents and I mostly make components. I try to be consistent with roles and aria stuff where it applies though.
|
|
#
?
Nov 14, 2021 20:12
|
|
|
Agreed that the big trouble with not using semantic tags is accessibility. Genuinely encourage people to try and use websites with some sort of accessibility hardware/software just to see how much of a loving nightmare we(and I do include myself in it, I could definitely be doing better) make the internet for people who are already at a massive disadvantage, and how significantly more usable it becomes when we take even very basic steps like semantic tags and alt-text everywhere. It's very eye-opening. Vincent Valentine fucked around with this message at 12:07 on Nov 15, 2021 |
|
#
?
Nov 15, 2021 12:04
|
|
|
In addition to screenreader accessibility, using semantic markup (and/or aria attributes) also ensures that your content shows up correctly in the browser's reader mode/view.
|
|
#
?
Nov 15, 2021 20:38
|
|
|
My TED talk will be: if you design for accessibility first, good UX will follow.
|
|
#
?
Nov 16, 2021 08:30
|
|
|
smackfu posted:Yes they just want an element to add styles to. Definitely React + Typescript combo. The DX + tooling has been rapidly improving these last few years.
|
|
#
?
Nov 17, 2021 19:50
|
|
|
I know Angular is a garbage trash fire and only idiots are still using it, but is it honestly impossible to do something like getBoundingClientRect on an Angular component? As in code:
|
|
#
?
Nov 17, 2021 21:22
|
|
|
zokie posted:- use real elements, not divs for everything zokie posted:And speaking of divs for everything, why do I see it so much from web devs? Is it some misguided attempt at having a CSS reset? Have fun trying to do a responsive-friendly layout of navbar elements or related article cards while only using "real" elements and no extra divs in there at all. HTML/CSS just sucks as a layout engine and even in the best case (flexbox everything, semantic everything, helper tooling for media queries) you often end up with extra wrapper divs for basic visual layout reasons.
|
|
#
?
Nov 18, 2021 00:29
|
|
|
Roadie posted:HTML/CSS just sucks as a layout engine and even in the best case (flexbox everything, semantic everything, helper tooling for media queries) you often end up with extra wrapper divs for basic visual layout reasons. Agreed but I will admit some libraries get obnoxious with divs. Like last time I used material-UI, they were using divs for select fields with no actual <input /> anywhere in the code. Using wrapping divs is most of the time necessary, but some web apps and component libraries really go overboard and i feel like it really depends on the quality of the developers on the team. After working at a few different companies with a few different UI libraries, I've decided if I ever get to start on a greenfield project, I'll probably just end up using my own components with just a styling library.
|
|
#
?
Nov 18, 2021 00:40
|
|
|
teen phone cutie posted:Agreed but I will admit some libraries get obnoxious with divs. Like last time I used material-UI, they were using divs for select fields with no actual <input /> anywhere in the code. Using wrapping divs is most of the time necessary, but some web apps and component libraries really go overboard and i feel like it really depends on the quality of the developers on the team. My absolute favorite was React Table. A library for making advanced interactive data tables... assembled entirely out of divs. They have since fixed it by making it headless (and even had an example with proper table markup), but dear lord it was bad to work with and exceedingly difficult to override the styling it came with due to it being an impenetrable maze of nested divs instead of an actual table. It's like the devs heard the old "don't use tables for layout" and took it to the illogical conclusion of "don't use tables ever, not even for tables". quote:After working at a few different companies with a few different UI libraries, I've decided if I ever get to start on a greenfield project, I'll probably just end up using my own components with just a styling library. After my horrible experience with React Table (and jQuery DataTables before that), I've taken to rolling my own data table components because writing one from scratch is less of a pain in the rear end than finding some library and trying to fix lovely markup and force it to do what you actually need it to do. I'm cool with outsourcing the lower level stuff like buttons, but as soon as there's a need for more for sophisticated/custom functionality, I'll go ahead and write my own thing. And for the low level stuff I use BluePrintJS, which I find to be excellent - markup is good, styling is super mild (meshes well and/or can be easily modified), and there's an emphasis on accessibility. However, if you're not doing a desktop-first data-heavy B2B app, then it's probably not the best choice. In other news, we finally have an actual frontend team at my company, which means we can divide and conquer and all work to our strengths instead of it being me doing everything mediocrely because I was stretched too thin and running on a half-baked, outdated education in React in isolation. And these guys are actually good at React and on top of all the new methodologies and best practices and poo poo, which means I can hand off a lot of the coding (resulting in better code) and dive more deeply into product, UX, data viz, and unfucking my stylesheets, which is honestly more where I want to be.
|
|
#
?
Nov 18, 2021 03:54
|
|
|
Roadie posted:Have fun trying to do a responsive-friendly layout of navbar elements or related article cards while only using "real" elements and no extra divs in there at all. Isin divs is inevitable, it’s using them when a nav, or even a button would be suitable that is pissing me of.
|
|
#
?
Nov 18, 2021 12:55
|
|
|
The Merkinman posted:I know Angular is a garbage trash fire and only idiots are still using it, but is it honestly impossible to do something like getBoundingClientRect on an Angular component? You need to get the native element, then use something like afterContentChecked. This might help: https://stackoverflow.com/questions/37881169/angular-2-getboundingclientrect-from-component And yeah re: Idiots using it. Honestly it still has its place in large scale application development. Plus it pays really good.
|
|
#
?
Nov 27, 2021 06:41
|
|
|
Ape Fist posted:Plus it pays really good. So does COBOL
|
|
#
?
Nov 27, 2021 20:08
|
|
|
prom candy posted:So does COBOL Typescript is significantly more pleasant than COBOL. I don't really think Angular is any more deserving of poo poo than, say, ASP.NET tbh.
|
|
#
?
Nov 30, 2021 08:11
|
|
|
Ape Fist posted:I don't really think Angular is any more deserving of poo poo than, say, ASP.NET tbh. No disagreement here 
|
|
#
?
Nov 30, 2021 18:08
|
|
|
I have a question I want to get some thoughts on. So I'm building out a library, and during the final build I want to offer importing UMD Modules along with a single-file build. So essentially I want to give the option for doing: TypeScript code:TypeScript code:I was reading through Webpack's tree-shaking docs, but (unless I'm wrong), there's no way to eliminate dead code at the time the developer builds their app that's consuming this library right? Tree-shaking is just purely for _your_ library's build time? https://webpack.js.org/guides/tree-shaking/ e: so I wanted to also comment on how my build is made. I do: 1. Babel runs through my /src code and creates a UMD version of every file in there and puts it in a /dist directory, non-minified 2. Webpack runs through the /dist folder and creates a root ./index.js Is there anything to gain by also having webpack create many files? In other words, have webpack create a dist/moduleA.js, dist/moduleB.js, etc? Because right now the /dist code is not minified, so it could add a tiny bit more bloat, but I'm not sure how worth it would be. teen phone cutie fucked around with this message at 23:45 on Dec 1, 2021 |
|
#
?
Dec 1, 2021 23:33
|
|
|
If I am understanding the question correctly, you want to be able to allow someone importing your lib to either import all of it or just parts of it? I’m not understanding what you mean by “dead code” here. If they can import each feature individually, what dead code will they also get? And if they are just importing the whole lib in one shot, then that would indicate to me they don’t care about dead code. So why would it matter?
|
|
#
?
Dec 2, 2021 04:29
|
|
|
HaB posted:If I am understanding the question correctly, you want to be able to allow someone importing your lib to either import all of it or just parts of it? Sorry yes that's what I'm asking - I think most of this is me being confused about how tree shaking (and surrounding terminology) works in the first place, since this is the first time I'm paying attention to it. I previously thought tree shaking meant "you configure webpack to only bundle what the user imports when they build _their_ code," which is wrong. I'm now understanding it's about removing unused code in _your_ source when you build your code? The thing I'm mostly confused about is, for package authors, why exactly does a single-file webpack build exist for a lot of packages, when I assume importing features a la carte is more optimal. What's the point in even having webpack create one bundle for situations like this? I guess for including as a script tag in HTML files, it makes sense, but I'm not crazy here when I say that if you're creating a JS app with webpack, importing feature-by-feature just makes more sense yeah? teen phone cutie fucked around with this message at 05:12 on Dec 2, 2021 |
|
#
?
Dec 2, 2021 05:02
|
|
|
Yeah there’s no need to build your library, that’s how you get things like lodash doubling your package size because you went import _ from “lodash”
|
|
#
?
Dec 2, 2021 05:23
|
|
|
I thought the point of tree shaking support in webpack was so that you didn’t need to mess with your imports since the bundler could tell what wasn’t being used by the code?
|
|
#
?
Dec 2, 2021 13:53
|
|
|
teen phone cutie posted:Sorry yes that's what I'm asking - I think most of this is me being confused about how tree shaking (and surrounding terminology) works in the first place, since this is the first time I'm paying attention to it. I previously thought tree shaking meant "you configure webpack to only bundle what the user imports when they build _their_ code," which is wrong. I'm now understanding it's about removing unused code in _your_ source when you build your code? It sounds like you're conflating a few things. You only need to worry about tree shaking when building your own code - not how it might affect someone else building code which happens to use your package. So you create your package, hopefully with ways for someone using it to import it all if they choose, or individual parts, and THEIR webpack will worry about the treeshaking for them. If they just import individual pieces of your package, then webpack won't import the rest of it, and if they import the entire thing, webpack (iirc) will at least attempt to shake out stuff they aren't using. HaB fucked around with this message at 14:42 on Dec 2, 2021 |
|
#
?
Dec 2, 2021 14:21
|
|
|
|
| # ? Jun 10, 2024 21:55 |
|
|
smackfu posted:I thought the point of tree shaking support in webpack was so that you didn’t need to mess with your imports since the bundler could tell what wasn’t being used by the code? The problem is that if a library is compiled and distributed as something like a single minified file, webpack can't pick out only what you're using and has to import it all. The safest way to distribute to a webpack user is to just package your code unmodified ES6 and let their webpack do the optimizations (although I've also seen some poorly-designed index.js files of just imports and exports that for reasons broke webpack's ability to target specific imports, so be careful there, too) Similarly, when using libraries, make sure you only import specifically what you're using. Webpack will see these code:code:
|
|
#
?
Dec 2, 2021 15:02
|
|