|
prom candy posted:Being able to do something yourself is not in itself a reason to do something yourself I'm not familiar with some of the solutions mentioned but when faced with kitchen-sink equipped, or bloated libraries I always prefer to just write it purpose built.
|
#
?
Aug 28, 2019 21:35
|
|
|
|
| # ? Jun 5, 2024 11:38 |
|
|
Nolgthorn posted:I'm not familiar with some of the solutions mentioned but when faced with kitchen-sink equipped, or bloated libraries I always prefer to just write it purpose built. This kind of dogmatism is cancer to projects. The correct and way to evaluate implementing a solution: "Library A does implement the functionality we need, but the layer it occupies in our project is particularly security-sensitive. After evaluating Library A we've determined that it is too complex to thoroughly audit with our available resources. On the other hand, the functionality we require is just complex enough that we can't ensure to a high-enough level of confidence with our available resources that we won't introduce our own vulnerabilities. Given the track record of Library A we've decided that the course leading to the least likelihood of a security incident is to implement Library A instead of rolling our own." Insert all the other domains outside of security...performance, maintenance, etc. This is the kind of analysis that gets glossed over by many or most of the developers who insist on rolling their own. They're just cargo-culting. In this specific case, where we're talking about ways to host content, your comment is exactly the opposite of what the original user should be doing. You're not going to implement security, performance, or features better than, netlify/DO/AWS.
|
|
#
?
Aug 28, 2019 21:46
|
|
|
Yeah exactly, especially for hosting solutions and the like. I do draw a line in the sand for UI component libraries that seem like they fit the requirements but that you'd have to spend excessive effort bending to your will. That said, some things are never worth rolling yourself - date/timezone code, csv/json/xml/html parsers, and other things in the same spiritual vein. I'm not going to go roll my own moment.js or d3.js for instance. But usually in those cases, if a popular library doesn't fit the use case, you're probably doing something wrong.
|
|
#
?
Aug 28, 2019 22:17
|
|
|
Ruggan posted:I do draw a line in the sand for UI component libraries that seem like they fit the requirements but that you'd have to spend excessive effort bending to your will. Yeah, it's often too easy up-front to just get going with something someone else has built but further into your project you start running into the friction of adapting a foreign API to your own project's way of doing things. Though, weighing your expected costs of rolling your own vs the expected costs of bending the library to your will is the same sort of analysis I described. Yeah, adapting a foreign API to your projects way of doing things is often fraught. But so is implementing a complete set of components. If your required number of components is small then you might go with rolling your own. But then you've got to also weigh inevitable feature creep that causes you to need more and more components. Anyway, not saying you do or don't need a third-party component library, just that it's the same sort of analysis as the security example I give above. Sometimes they make sense and sometimes they don't.
|
|
#
?
Aug 28, 2019 22:54
|
|
|
I almost never meet developers that roll their own. I meet exclusively developers that insist that if a module exists it should be installed immediately and used no matter what it is and that a node_modules directory being thousands of libs large is totally fine. Moment isn't my favourite date library, but a date library is sufficiently complex and already purpose built, especially useful if you're working with a lot of dates so go ahead and use one.
|
|
#
?
Aug 28, 2019 22:58
|
|
|
I have a crazy problem that I can't figure out. I have a simple site built on a SquareSpace template. In Chrome, on Mac OS or Windows, we have a site with *one specific page only* where the links won't load on initial load. The second you: grab the page window and move it, resize it, or just plain refresh it - they all of a sudden spring into action. But never on initial load. Edge and Safari work fine. It's *just* on Chrome. What the hell could be going on?
|
|
#
?
Aug 28, 2019 23:13
|
|
|
BonoMan posted:I have a crazy problem that I can't figure out. Anything in the console (hit F12, Console tab)? Any ad-blockers or other plugins going?
|
|
#
?
Aug 28, 2019 23:18
|
|
|
HexiDave posted:Anything in the console (hit F12, Console tab)? Any ad-blockers or other plugins going? Nope. Seems to be the same across everyone's computers here and at home. Only on Chrome. Even mobile chrome (when viewed as desktop) does it. Of course in mobile mode it auto resizes the page so that kicks the links into active mode.
|
|
#
?
Aug 28, 2019 23:26
|
|
|
BonoMan posted:Nope. Seems to be the same across everyone's computers here and at home. Only on Chrome. Even mobile chrome (when viewed as desktop) does it. Of course in mobile mode it auto resizes the page so that kicks the links into active mode. Have you tried making a copy of that page and testing it? If it's the same after a copy, start disassembling the copy to see if something on it is busted. Or maybe the page is haunted.
|
|
#
?
Aug 28, 2019 23:39
|
|
|
Nolgthorn posted:I almost never meet developers that roll their own. I meet exclusively developers that insist that if a module exists it should be installed immediately and used no matter what it is and that a node_modules directory being thousands of libs large is totally fine. Oh, well then doing the exact opposite is the appropriate strategy.
|
|
#
?
Aug 29, 2019 03:14
|
|
|
The Web Design & Development Megathread: node_modules are like pokemon - gotta install em all
|
|
#
?
Aug 29, 2019 03:44
|
|
|
Ruggan posted:The Web Design & Development Megathread: node_modules are like pokemon - gotta install em all Literally what this page I was looking at earlier this evening says https://medium.com/the-vue-way/my-favorite-vue-js-nuxt-js-packages-for-2019-639dbbfe699e
|
|
#
?
Aug 29, 2019 04:05
|
|
|
BonoMan posted:I have a crazy problem that I can't figure out. Sounds like a resource is not loading so the page is still loading. I would check network resources first to see if is the case. Maybe change the event that trigger these links generation. It may also be a css problem if the links are not generated.
|
|
#
?
Aug 29, 2019 07:59
|
|
|
I'm having trouble achieving a specific responsive layout using just CSS. Here's what I want, with the mobile layout on the left and larger devices on the right. I haven't been able to make any progress on this using 'display: flexbo'x, and would rather stay away from 'display: grid' because of compatibility issues. I thought I had a solution involving 'flex-direction: column' and 'flex-wrap: wrap' in combination with a class to force the flex container into a new column combined with the 'order: ' property to create the order of 1-3-column wrap-2, but had no success making a column-wrapping class. Please save me, CSS wizards!
|
|
#
?
Aug 29, 2019 11:02
|
|
|
some guy i guess posted:I'm having trouble achieving a specific responsive layout using just CSS. Here's what I want, with the mobile layout on the left and larger devices on the right. This is exactly the problem that `display: grid` solves, and it has very good compatibility nowadays. What devices are you worried about?
|
|
#
?
Aug 29, 2019 11:05
|
|
|
Just an example of how easy it is to do with grid:code:
|
|
#
?
Aug 29, 2019 11:09
|
|
|
sunaurus posted:What devices are you worried about? IE. The website is targeted at academics (including old people plus people browsing from ancient university IT systems stuck on IE), and I've read that even with prefixing, IE still stumbles on some grid properties. I feel like forcing the small amount of IE users to the single-column mobile layout and using grid for the rest may be the best option now. I really, really like using grid in my own projects but this is for a client and I'm concerned about compatibility.
|
|
#
?
Aug 29, 2019 11:41
|
|
|
Do you have the actual analytics of the browser break down or is it heresay? Not that I'm doubting you, I've just personally been on projects where big efforts to support IE were made then when we looked at analytics the IE users were <1%.
|
|
#
?
Aug 29, 2019 12:13
|
|
|
No analytics unfortunately, the site is for a small business with no existing web presence. The tiny percentage of IE users are just gonna have to deal with a single-column layout  .
|
|
#
?
Aug 29, 2019 12:22
|
|
|
Data Graham posted:Literally what this page I was looking at earlier this evening says https://medium.com/the-vue-way/my-favorite-vue-js-nuxt-js-packages-for-2019-639dbbfe699e Evergreen response: https://twitter.com/garybernhardt/status/1034519171986423809
|
|
#
?
Aug 29, 2019 12:24
|
|
|
some guy i guess posted:No analytics unfortunately, the site is for a small business with no existing web presence. The tiny percentage of IE users are just gonna have to deal with a single-column layout IE11 (and to some degree) 10 actually have prefixed grid support, so if you have a basic grid layout, it's very likely it's adding a couple extra lines of -ms-grid stuff for full support for them as well.
|
|
#
?
Aug 29, 2019 13:02
|
|
|
I'm totally blanking on the right way to solve a problem here. I want to display a modal of a specified aspect ratio that fills up as much room as possible, but I also want it to be locked to the viewport so that it always fits on screen. So for example, if it was a 16:9 modal then on a 21:9 screen I would need to leave some space on the left and right, but on a 4:3 screen it would leave some space on the top and bottom. I created a simple codesandbox to display the problem: https://codesandbox.io/s/sparkling-paper-crj5n If you drag the browser pane so that it's wider than 16:9 you can see the issue, the box just continues to grow, whereas I'd like it to max out at 100% height. Can this be done with CSS or am I going to need to clock the window size with JS and do some calculations to get it where I want it? edit: I think Facebook's photo modal is almost exactly what I'm trying to build, and it looks like they use JS to achieve that so maybe that's my solution prom candy fucked around with this message at 16:17 on Aug 29, 2019 |
|
#
?
Aug 29, 2019 15:39
|
|
|
What about something like this? https://codesandbox.io/s/hopeful-darkness-quk3d
|
|
#
?
Aug 29, 2019 16:49
|
|
|
double post
|
|
#
?
Aug 29, 2019 16:50
|
|
|
Oh drat, didn't even think of using vh/vw! That's a pretty nice solution, gonna see if I can get that to work for me before I go down the JS road, thanks!
|
|
#
?
Aug 29, 2019 17:04
|
|
|
RobertKerans posted:Evergreen response: https://twitter.com/garybernhardt/status/1034519171986423809 That's wrong. They're both liabilities and assets. They're liabilities because they introduce maintenance (and other) costs/risks. They're assets because they enable you to do things you couldn't do with available resources before. Unnecessary dependencies are another story.
|
|
#
?
Aug 29, 2019 20:10
|
|
|
Hi, I have a question regarding mobile cameras on the web: I have a web application (simple, 2 react components, nothing fancy) that's accessing the browser's webcam with the following constraints: code:The orientation of the device doesn't matter, it's always 480x640 by the time it gets to the server. Has anyone encountered something like this?
|
|
#
?
Aug 29, 2019 21:36
|
|
|
Dependencies in my personal projects are badass. Dependencies at my professional job are almost always a problem. I can update my personal app to use hooks, context and whatever other cool poo poo is in react 16.9 and have an easy time doing it. If a module becomes a problem, I can usually replace it pretty well. My development time is greatly reduced and it's almost always a lengthy series of wins that greatly outweigh any losses. But no client is going to request we spend time upgrading our dependency versions without delivering new features. And so we don't, since upgrading versions has breaking changes that need to be addressed and that time needs to be spent on client requests instead. And so now the react dev tools chrome extension breaks one of our applications because it uses react 14.9.
|
|
#
?
Aug 29, 2019 21:49
|
|
|
Vincent Valentine posted:Dependencies in my personal projects are badass. Now imagine if when you were developing those projects you had to implement react from scratch!
|
|
#
?
Aug 29, 2019 22:53
|
|
|
Thermopyle posted:Now imagine if when you were developing those projects you had to implement react from scratch! B but the size of the node_modules directory!
|
|
#
?
Aug 29, 2019 23:18
|
|
|
FWIW, it's almost always a huge hassle on my personal projects if I set them aside for a year and come back to them. On frontend projects in particular, I'll spend a week updating all of the dependencies and resolving conflicts and changing my code as required. That's excluding if I want to keep up with paradigm changes like class-based components to function components to hooks.
|
|
#
?
Aug 29, 2019 23:25
|
|
|
No see if I start my project late enough in internet history, all the modules I need will become Done and I won’t have to worry about keeping them up to date anymore
|
|
#
?
Aug 29, 2019 23:47
|
|
|
Data Graham posted:No see if I start my project late enough in internet history, all the modules I need will become Done and I won’t have to worry about keeping them up to date anymore That's what I always tell clients when they ask why their project isn't done.
|
|
#
?
Aug 30, 2019 00:35
|
|
|
Vincent Valentine posted:But no client is going to request we spend time upgrading our dependency versions without delivering new features. Your clients don't care about CVEs?
|
|
#
?
Aug 30, 2019 02:15
|
|
|
You would think that, but no. We have a big list of huge clients, and only one was concerned and only with one module (jQuery 1.1). It's extremely embarrassing all around.
|
|
#
?
Aug 30, 2019 03:31
|
|
|
Dang folks it’s almost like there are occasions that using third party libraries are appropriate and times when they aren’t.
|
|
#
?
Aug 30, 2019 04:22
|
|
|
I was not happy when I found one dev was writting code using syntax from the last version of the language. Syntax that adds nothing, just make code more sucint. It always make me angry when dependencies are added for no reason. Dependencies have a cost, so they must give some benefict back to make sense
|
|
#
?
Aug 30, 2019 08:00
|
|
|
Thermopyle posted:That's wrong. No, he's being flippant, but he is right: dependencies are always liabilities, it is just whether the trade-off implicit in relying on them is worthwhile. A particular dependency should always reduce the complexity in some way, but ideally it wouldn't be there. Every dependency adds something uncontrolled [and with its own API, and if you're unlucky its own special build rules, etc] to the overall system. Cue "why not write everything in assembly then" or something to that effect, but that would be reductive, there's a baseline. If I move up a few layers of abstraction: saying that you wouldn't want to have to write the equivalent of React every time is true. But that's also a bit of a non-sequitur, because the application is often going to be a React application, that's the baseline, you build from that
|
|
#
?
Aug 30, 2019 08:44
|
|
|
RobertKerans posted:dependencies are always liabilities, it is just whether the trade-off implicit in relying on them is worthwhile. A particular dependency should always reduce the complexity in some way, but ideally it wouldn't be there. Every dependency adds something uncontrolled [and with its own API, and if you're unlucky its own special build rules, etc] to the overall system. Yes, that's what I said.
|
|
#
?
Aug 30, 2019 18:56
|
|
|
|
| # ? Jun 5, 2024 11:38 |
|
|
Thermopyle posted:On frontend projects in particular, I'll spend a week updating all of the dependencies and resolving conflicts and changing my code as required. That's excluding if I want to keep up with paradigm changes like class-based components to function components to hooks. I spent all day updating two of our internal websites dependencies and rewriting all the react class components to function components with hooks. Still not quite done - need to test and expect to find some issues. But I’ll be happy when it’s done.
|
|
#
?
Aug 31, 2019 01:36
|
|