|
We are about to do a rewrite of a load-bearing system that's about 17 years old. Sometimes you have to pull the trigger. Also, the worst people you can assign to that job are hotheads that like shiny things, as you will end up at the same place you started, only in a newer technology. It helps with hiring for a while, I guess.
|
#
¿
Mar 1, 2019 03:11
|
|
|
|
| # ¿ May 18, 2024 08:31 |
|
|
Haven't used React, and I use Vue daily at work. It was super easy to learn. I think a lot of concepts transfer to React, but there's more explicit stuff and less convention/magic thank with Vue. Neither will be a mistake.
|
|
#
¿
Mar 7, 2019 03:20
|
|
|
Yup, this. Most of modern front end is just ES6/7 stuff and APIs that is transferable knowledge as both frameworks have the same underlying principles. As there will be a new shiny framework any day now, no need to tie yourself to a specific one. Solid knowledge of the core language will allow you to easily hop between the flavors of the day.
|
|
#
¿
Mar 7, 2019 04:59
|
|
|
So, just today I was evaluating a code sample from one of the candidates, and I encountered a "possible infinite loop in render function" in a Vue app. Turns out the person was mutating the state in the template, that was then being looped over in the same template. Don't do that. I'm amazed I never saw that error before. Btw, I don't agree that majority of web dev is Vue/React/Angular. I've seen so much recent jQuery that it brings sadness to my bitter, old heart.
|
|
#
¿
Mar 8, 2019 01:23
|
|
|
Why is it a bad idea?
|
|
#
¿
Mar 10, 2019 12:48
|
|
|
It's possible to have a career in we dev without touching jQuery. If you work at an agency (new projects/one-offs where you choose the stack) or a startup (recent code, again you choose the stack). The moment you start consulting or join a company with a large, pre-existing codebase, the probability of encountering it starts approaching 1. edit: nothing against jQuery. It saved my butt many a time in my early career. I'm mostly against its misuse in the wild, but that can be said about anything. Oh, and monadic composition that doesn't enforce monadic laws, but that's another story... gbut fucked around with this message at 15:45 on Mar 10, 2019 |
|
#
¿
Mar 10, 2019 15:39
|
|
|
Either strategy is valid. I like versioning filename just because it avoids the complexity, and is ok for long-lived assets. I suggest a proper versioning instead of "..._new"  For short-lived, iterated-over assets, cache invalidation is probably a better option.
|
|
#
¿
Mar 11, 2019 16:02
|
|
|
Third-ing this. ^
|
|
#
¿
Mar 11, 2019 20:36
|
|
|
Those look just like different entry points that use the same shared components. You could have an entry point for page1, page1,... and one that incorporates those elements in the main app.js. similar with router and state: split into modules, and instantiate in a very simple way, attach modules, and you can do that for individual pages as well as the main app. Not sure if I'm missing something.
|
|
#
¿
Mar 12, 2019 22:41
|
|
|
Well, you should use an image processing service like imagx (or roll your own out). Even WordPress auro-resizes photos. On the other hand, system designed so even idiots can use it, etc.
|
|
#
¿
Mar 25, 2019 17:05
|
|
|
Dominoes posted:I'm focusing strictly on advantages of Rust; you could as easily write a list of disadvantages. TypeScript just pretends to have one.
|
|
#
¿
Mar 27, 2019 01:29
|
|
|
We use Vue almost exclusively at my work, and yes, it's easier to learn (as I'm told by people more proficient in React than me). We are also starting to build projects in React too now, as we ran into some issues in the past with Vue's strong opinions, and also to expand the accessible pool of front end devs, as per the comment above. More people know React, by far.
|
|
#
¿
Mar 29, 2019 02:43
|
|
|
Another thing you might want to consider is SVG for knob components.
|
|
#
¿
Apr 10, 2019 17:28
|
|
|
ESL here, so I used "knob" as a generic "synthesiser interface thingamajig" word, but yeah. Rotating knobs via mouse / trackpad suck and you should not do that skeumorphic crap. E: what I meant, if you are making a complicated interface component, SVG might be more flexible than HTML, but also easier to do than canvas.
|
|
#
¿
Apr 10, 2019 18:45
|
|
|
Only if GraphQL or similar API that allows you to define the response scope. If you don't have control over the API output, I'm not sure if you could pull something like that easily with a large set of large records. Chunking would be better in that case.
|
|
#
¿
Apr 16, 2019 18:34
|
|
|
Seconding (thirding?) this. Never, ever, have competing sources of truth if you can avoid it. Your future self will thank you. Love thy future self.
|
|
#
¿
Apr 18, 2019 06:45
|
|
|
I would rather just become a carpenter than go back to building SPAs without a nice framework.
|
|
#
¿
Apr 21, 2019 22:46
|
|
|
The benefits are readability and reusability at the very least.
|
|
#
¿
Apr 22, 2019 22:16
|
|
|
Your first example (arrow one) would return undefined. Just fyi.
|
|
#
¿
Apr 23, 2019 21:03
|
|
|
That's one my my big issues with TS. You can't cleanly rely on libraries (you can on some) and God forbid you have to convert existing JS codebase. Feels like it would be easier to rewrite from scratch, but that's rarely feasible.
|
|
#
¿
Apr 24, 2019 15:42
|
|
|
We did Browstack for a while, but now it's just a steaming shitpile of randomly failing VMs. Looking for alternative solution, as we have a ton of TestCafe tests nobody wants to rewrite. E: we'll probably just do headless homegrown in the meantime.
|
|
#
¿
Apr 25, 2019 22:14
|
|
|
You'd probably want a computer property that gives you totalTrue based on what children report. Also, if you override isTrue on parent component with each child event, you won't be able to count how many are true. So, data isTrue should be an (empty at first) array. You should probably rename it to childrenResponses or something. Then on the event callback, don't override, but just push the value into the array totalTrue computed property then can filter out false responses from that array, and returna the length You can than easily count totalFalse, and totalResponses the same way, just by adjusting the filter. (Filter out true-s, or do not filter, respectively) Having a computed property makes it easy to bind to a display component of sort, and keeps it declarative and reactive. E: mobile typos and clarity gbut fucked around with this message at 21:37 on May 4, 2019 |
|
#
¿
May 4, 2019 21:35
|
|
|
Why not just overlay in the browser? https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/timeupdate_event Use that to drive/time the overlay. Re-rendering the video looks like an overkill to me.
|
|
#
¿
May 17, 2019 19:59
|
|
|
Canvas, definitely, if you're aiming for pixel perfect. It's super easy to work with, or you can use something like p5.js if you want power with even more ease.
|
|
#
¿
May 18, 2019 20:48
|
|
|
https://twitter.com/markdalgleish/status/1144223814256979968?s=19
|
|
#
¿
Jun 27, 2019 15:45
|
|
|
Yeah, pick one that looks easier to you, and you'll be able to transfer vast majority of that knowledge to the other one later on. They are not that different.
|
|
#
¿
Jul 6, 2019 19:38
|
|
|
Careful Drums posted:Those aren't great devs If you can't skim the code and understand the hig-level context, the dev is implementing the "job security" pattern.
|
|
#
¿
Jul 12, 2019 17:38
|
|
|
You haven't lived if your haven't used SOAP.
|
|
#
¿
Jul 12, 2019 22:11
|
|
|
We just recently started switching to UTC for "timestamps." Instead, you know, "whatever the client's browser provided, but also without the timezone specified." The company has been developing software for decades (±12h). 
|
|
#
¿
Jul 14, 2019 02:39
|
|
|
Abandoned it after 6 months or random vm fails, mostly for recent mobile but windows too. e: to add more info, we used it in our CD pipeline for a year and couldn't rely on it. We switched to headless in the end. We ran a barrage of test that would take about half an hour when running on a dozen different platforms, and having them randomly drop out or hang crawled our deployments to a halt. 
gbut fucked around with this message at 15:57 on Jul 22, 2019 |
|
#
¿
Jul 22, 2019 15:51
|
|
|
Congratulations! I've been struggling with a similar issue as I come from design background and have been relegated to backend in the last few years. "Senior engineer" "value" crap and all that. Hoping to get back into frontend, but it will be hard to find something better where I live.
|
|
#
¿
Aug 14, 2019 21:50
|
|
|
I think the front end is a bit of a poo poo-show right now, with all the opinions, frameworks and build systems out there, especially compared to the stuff available when I started playing with it in the previous century. I still love it because I'm a visual person, and would rather tackle that than build yet another CRUD app ("let's not call it that") or a "data pipeline" (lambda that pushes to s3) or some similar low-effort crap that is valued far more then the initial impression of (and the first point of contact with) the actual product user. I've been building interfaces my whole life, minus a few years at the beginning. I feel underutilized and my passion ignored. Yup, I'm one of those jaded graybeards longingly peeking over the fence.
|
|
#
¿
Aug 15, 2019 09:59
|
|
|
Or thi.ng.
|
|
#
¿
Aug 16, 2019 21:08
|
|
|
Undoubtedly. It's visible, and you can be called out for crap in the front end. The difference between good backend and bad backend is hardly noticable to the business/client.
|
|
#
¿
Aug 22, 2019 09:05
|
|
|
Well, yes and no. That "backend react" drives the UI. So, IMHO, it is tightly coupled with the notion of front end. Almost every react component has a visual representation, and data modeling is a second citizen there, in contrast to the "real backend". But I get your reasoning. It just sounds to me more like "frontend isn't for Dreamweaver newbies any more, but a full environment for serious work" instead of your suggested dichotomy. e: to clarify: we can finally do some serious UI work.
|
|
#
¿
Aug 22, 2019 16:47
|
|
|
Well, if you're gonna make components purely functional, you have to extract the state *somewhere*. Kidding aside, yeah, that's not good in many cases.
|
|
#
¿
Sep 14, 2019 03:57
|
|
|
No wonder they wanted to double check his diploma. What a bold claim.
|
|
#
¿
Oct 7, 2019 19:11
|
|
|
"just code it in HTML 4.01. it allows custom attributes."
|
|
#
¿
Nov 26, 2019 16:06
|
|
|
Lol at moment being called a "small library". We halved the payload of one of our apps by removing moment that somebody introduced to create a single date instance.
|
|
#
¿
Nov 26, 2019 21:04
|
|
|
|
| # ¿ May 18, 2024 08:31 |
|
|
I'm _this_ close to initiating a ban on moment at my work. If I can't trust you to use Vuex properly, and you end up with a action chains that take me back to old-timey callback hells, why should I trust your choice to use moment.js? No, Jerry. You don't need the ability to calculate time spans with consideration of Rio de Janeiro summer time in November of 1963, just so the customer can enter their loving birth date. Moment.js is a cancer. If you are not doing something specifically related to tricky time conversions, you should be able to rely on browser localizations. They've gotten pretty good by now. And for the love of all that is good, use UTC when storing it. Don't let the DB do more transformations. You know what they say: when you fiddle with the data, you can only lose information, not add to it.
|
|
#
¿
Dec 28, 2019 17:48
|
|