|
death cob for cutie posted:Context: I teach/write curriculum for a web development bootcamp that teaches three languages/stacks/frameworks/whatever: Python with Flask, JS with Node/Express/React and Java using Spring. All I really personally do is Python programming; I'm a "web developer" in that I only gently caress up writing basic JS like, half the time. Students get the Python course first and it's really intended primarily to get them used to the basics of webdev (what is a "server", what does a database do, what does it mean to receive requests and return responses, etc.) while also accepting the fact that most of the students will have been writing any kind of code for about like, four weeks total. A key part of this is that the Python section in particular is not explicitly a "hey this is Real-World" experience, but it's really to make sure they get their footing as newbie programmers before we start throwing more at them. I have a friend who's going through a program right now and they started off with vanilla JS. I think that's probably the place to start before dropping them into a framework and making them deal with package management, compilation, etc. The built in browser APIs are pretty good these days. Fetching data from a server and updating part of the DOM isn't hard to do at all in vanilla. If you specifically want to teach a framework then you should teach React because presumably people are taking this course to get jobs and that's where the jobs are.
|
#
?
Mar 3, 2023 21:14
|
|
|
|
| # ? May 20, 2024 09:06 |
|
|
Roadie posted:If you don't want the complexity, don't use server components? If you just want to stick to client-side stuff, there's nothing new needed other than the de facto standard around .client.js / import 'client-only';. But in Next at least, you really need to use server components unless you're only pulling data from public sources. And adding `use client` to the top of each component is tedious. And intentionally deliberately adding a line to hamper a site's performance just because it's an agreed upon convention is never going to be long-term solution. quote:The rest of it is complicated because server-rendering specific layers of the component tree and mushing them together with client-rendered components while treating all of it as a single set of nodes for the user and doing it performantly enough that you're still coming out ahead in user experience even after eating the round-trip time is complicated. I agree it's complicated but newer frameworks have done a better job hiding it or abstracting it away. Trying to retrofit it to a framework with React's level of maturity is just making things more clunky.
|
|
#
?
Mar 3, 2023 21:16
|
|
|
teen phone cutie posted:it's a shame that all the packages in Vue had to also upgrade to Vue3 to be able to leverage it in your consuming app. i'm sure it's in a much better spot now, but Vue3 meant nothing to us at my company a few years ago because we were reliant on libraries like Vuetify which was going to take a long time to migrate to Vue3 themselves. Yeah my last big vue project was heavily reliant on Bootstrap-Vue, which was needs-suiting but had to be ditched this time around. I trialled quasar but didn't like the experience. Switched over entirely to Tailwind-UI plus FormKit for the latest stuff, and found myself appreciating the paradigms. Looks like vuetify and bootstrap-vue are both ready to go with 3 now, only three years late. It's such a crapshoot picking a new stack for a complicated project when your old tools are sunsetting, especially when the new kids on the block seem to be gaining significant traction. On another note, is anyone else doing client REST API code generation for typesafety? I'm currently building all my axios calls from a swagger schema using Orval and it seems to be working pretty well, but all anyone talks about is tRPC and GraphQL. Wondering if I took a wrong turn somewhere.
|
|
#
?
Mar 3, 2023 21:50
|
|
|
Spime Wrangler posted:On another note, is anyone else doing client REST API code generation for typesafety? I'm currently building all my axios calls from a swagger schema using Orval and it seems to be working pretty well, but all anyone talks about is tRPC and GraphQL. Wondering if I took a wrong turn somewhere. If I was starting something from scratch I would use tRPC but I think what you're doing is pretty common and cool. GraphQL sucks.
|
|
#
?
Mar 3, 2023 22:19
|
|
|
Yeah tRPC is super intriguing but I've got about 8 years invested in using django/DRF and chasing frontend trends is enough of a full time job i'm not sure I'm ready for typescript on the server. Nice to have at least part of the project built on something bedrock-stable. Sometimes wish I was ready for the new poo poo, though!
|
|
#
?
Mar 3, 2023 22:38
|
|
|
Spime Wrangler posted:Yeah tRPC is super intriguing but I've got about 8 years invested in using django/DRF and chasing frontend trends is enough of a full time job i'm not sure I'm ready for typescript on the server. Nice to have at least part of the project built on something bedrock-stable. Yeah I've got like 15 years in Rails and I'm ready to be Typescript everywhere at this point. Next gig hopefully.
|
|
#
?
Mar 3, 2023 23:12
|
|
|
A job I did in 2019 said "we use Vue and Nuxt.js here, have fun" and plopped some new projects on my lap to figure out from scratch. I invested all the spare non-work time I had in figuring that out since then, doggedly, knowing that no matter what I picked it would probably end up being no less irrelevant.
|
|
#
?
Mar 4, 2023 00:27
|
|
|
I've never heard of tRPC so now I have a new thing to research. Thanks thread! I thought GraphQL was what everyone was going to be using.
|
|
#
?
Mar 4, 2023 00:51
|
|
|
GraphQL is good for arbitrary external access APIs because you can effectively trim down payloads on the fly, but if you control both sides of the operation and everything updates in sync it's just unnecessary overhead.
|
|
#
?
Mar 4, 2023 00:54
|
|
|
tRPC has gotten popular enough that people are trying to reimplement the tRPC developer experience for GraphQL servers now.
|
|
#
?
Mar 4, 2023 06:33
|
|
|
Because I'm lazy and didn't read the documentation, does tRPC require your front and back end be in he same repo?
|
|
#
?
Mar 5, 2023 00:57
|
|
|
I'm an engineering manager at a large enterprise, but in a mobile native app capacity. I think long term I need to know web dev things. I never touched JS in my life. What's a good resource to make maybe a react site with some sorta backend and deployment on AWS? I think it would be good for me to learn these things.
|
|
#
?
Mar 5, 2023 02:25
|
|
|
I'm apologizing in advance, because this is going to be mean, but I kind of need help. One of you must be old enough to know how to manually set up an rss feed right? My site is programmed in plain PHP, and I upload the files myself, but I don't know how to do RSS.
|
|
#
?
Mar 5, 2023 04:22
|
|
|
Boba Pearl posted:I'm apologizing in advance, because this is going to be mean, but I kind of need help. If you're looping through blog/news posts and displaying them in HTML via PHP in something like index.php, just do that in a new file called rss.php, but output XML that follows the RSS spec instead of HTML
|
|
#
?
Mar 5, 2023 04:41
|
|
|
Last Chance posted:If you're looping through blog/news posts and displaying them in HTML via PHP in something like index.php, just do that in a new file called rss.php, but output XML that follows the RSS spec instead of HTML
|
|
#
?
Mar 5, 2023 05:26
|
|
|
Lumpy posted:Because I'm lazy and didn't read the documentation, does tRPC require your front and back end be in he same repo? I think that's what it's meant for yeah, otherwise you'd basically need to do codegen of some sort to have the typesafety. There is trpc-openai if you want to be able to use your tRPC backend like a REST API too though.
|
|
#
?
Mar 5, 2023 05:53
|
|
|
Lumpy posted:Because I'm lazy and didn't read the documentation, does tRPC require your front and back end be in he same repo? Ima Computer fucked around with this message at 12:27 on Mar 5, 2023 |
|
#
?
Mar 5, 2023 12:23
|
|
|
if i'm GETing a bunch of images in Node so i can send their width and height (for purposes of setting them inline on the <img /> tag) to the browser, is there any way to prevent having to download them a second time in the browser? if i sent them as base64 from Node to browser JS, would that get me a performance boost or is it better to just leave it as is? edit: the reason i'm requesting the images in Node is that i'm trying to prevent layout shift when the images load - these images are user submitted, so i don't know the widths and heights teen phone cutie fucked around with this message at 23:37 on Mar 5, 2023 |
|
#
?
Mar 5, 2023 23:35
|
|
|
I don't know the answer to that, but if you don't care about preserving the exact aspect ratio of the images you could solve this issue by putting the images inside of a div, giving the div a specific aspect ratio and setting the image to object-fit: cover. That way all of your images display nicely and their actual dimensions are meaningless. Not sure if this is applicable for you, but I've had good luck with this for the sort of situation you're describing in the past. https://jsfiddle.net/h9Lz8bas/
|
|
#
?
Mar 6, 2023 18:50
|
|
|
kedo posted:I don't know the answer to that, but if you don't care about preserving the exact aspect ratio of the images you could solve this issue by putting the images inside of a div, giving the div a specific aspect ratio and setting the image to object-fit: cover. That way all of your images display nicely and their actual dimensions are meaningless. Not sure if this is applicable for you, but I've had good luck with this for the sort of situation you're describing in the past. unfortunately not - the images need to be exactly as they were uploaded
|
|
#
?
Mar 6, 2023 22:42
|
|
|
teen phone cutie posted:if i'm GETing a bunch of images in Node so i can send their width and height (for purposes of setting them inline on the <img /> tag) to the browser, is there any way to prevent having to download them a second time in the browser? if i sent them as base64 from Node to browser JS, would that get me a performance boost or is it better to just leave it as is? Base64 can be useful for very small images but past a certain point it'll be worse. There's no way to avoid downloading them again because the first download goes to your server and the second download goes to the user's machine. If you want to speed up the node endpoint you could set up some kind of cache so that you only need to get the image's width and height the first time they're requested, and on subsequent requests for the same image URL it would just pull it from the cache instead. Or if the uploads are coming through your system you could store the width and height when you save the image instead of when it's requested.
|
|
#
?
Mar 6, 2023 23:08
|
|
|
prom candy posted:If you want to speed up the node endpoint you could set up some kind of cache so that you only need to get the image's width and height the first time they're requested yep - i also had this idea and implemented it. it actually didn't really save me much time at all since all the image requests are happening in parallel and by the the time the same image is requested a second time and it aborts to read from the cache instead, the request has already been made. i could not make them parallel, but i feel like that would just be slower prom candy posted:and on subsequent requests for the same image URL it would just pull it from the cache instead. Or if the uploads are coming through your system you could store the width and height when you save the image instead of when it's requested i was also thinking of this. this might be what i try next e: FWIW, it's like a 1/10 of a second to request the images i need, but i'd like to get that time back if possible lol
|
|
#
?
Mar 6, 2023 23:17
|
|
|
teen phone cutie posted:yep - i also had this idea and implemented it. it actually didn't really save me much time at all since all the image requests are happening in parallel and by the the time the same image is requested a second time and it aborts to read from the cache instead, the request has already been made. i could not make them parallel, but i feel like that would just be slower The point of the cache is you save time when a different user comes along and requests the same page with the same images. It's not about saving time on the very first load. The thing is, if your site gets any sort of real-world usage, the very first load is a tiny minority of the total number of requests - it doesn't really matter if it takes a little bit longer.
|
|
#
?
Mar 7, 2023 00:12
|
|
|
teen phone cutie posted:yep - i also had this idea and implemented it. it actually didn't really save me much time at all since all the image requests are happening in parallel and by the the time the same image is requested a second time and it aborts to read from the cache instead, the request has already been made. i could not make them parallel, but i feel like that would just be slower does every user get different images? I mean saving it in a persistent cache, like Redis for example
|
|
#
?
Mar 7, 2023 02:35
|
|
|
oh yes, no by cache i was talking a memoized function. Redis is a good call actually i'll look into that
|
|
#
?
Mar 7, 2023 03:30
|
|
|
Where should I be looking for jobs, especially remote work? I've tried LinkedIn, Indeed, all those major sites, but I'm getting no hits. I get a lot of messages and emails saying "Are you available for an interview tomorrow at [insert time here]?" and then when I reply that I am, I get radio silence. Is that usual these days? Why even ask if they have no intention of following up? I know Jan/Feb is a rough time for web dev jobs, it's why I'm trying to break out of freelancing, but these time wasters are absurd.
|
|
#
?
Mar 7, 2023 22:21
|
|
|
Is there a way to fight back against the time wasters? Like, if someone contacts you and you respond with interest that's a half contract that they will ask you a follow up of some sort. This is basic social stuff. Can we reprimand whichever agency is hiring these people? Or, get off LinkedIn which is a spam network. I did ages ago, people just pay to be able to send out mass messages. Take them less seriously I suppose..
|
|
#
?
Mar 8, 2023 19:03
|
|
|
Nolgthorn posted:Is there a way to fight back against the time wasters? Like, if someone contacts you and you respond with interest that's a half contract that they will ask you a follow up of some sort. This is basic social stuff. Can we reprimand whichever agency is hiring these people? Yeah I'm getting off LinkedIn. It's solely a place for people to brag about their accomplishments, most of which are awards people made up solely to be able to brag about on LinkedIn. I just started reaching out to marketing agencies and such directly, I'll see if that gets me anywhere.
|
|
#
?
Mar 8, 2023 19:12
|
|
|
i wish i was able to get off linkedin, but honestly nothing beats in right now in terms of searching for jobs. i think indeed is basically useless at this point
|
|
#
?
Mar 8, 2023 19:21
|
|
|
I got my current job through LinkedIn. It's an ok place.
|
|
#
?
Mar 8, 2023 21:04
|
|
|
same
|
|
#
?
Mar 8, 2023 22:21
|
|
|
I guess when I'm looking for work I scour job boards and send applications. I never took anything seriously that I received from linkedin, it was always just tentatively related to what I was doing now. Almost always something I did 5 years ago.
|
|
#
?
Mar 9, 2023 00:21
|
|
|
Linkedin is about the same as any other job board, to be honest. There are a lot of listings. Some of them are for good companies, and some of them are for lovely companies. Some might be a good fit for you, and some aren't a good fit. Heck, half the time when I've looked at Linkedin vs [insert other board here], half of the jobs are included on both boards. Now recruiters on Linkedin are a whole 'nother ball of wax and are universally obnoxious and terrible in my experience.
|
|
#
?
Mar 9, 2023 15:25
|
|
|
Yeah when it has come to individual job postings for full time roles I've had LinkedIn perform adequately there. Actually went far with two separate interview processes and those experiences were fine, but declined the roles because it wasn't worth moving from my current job. Certainly had some rejections or no responses that made my head scratch but like have you ever met recruiters or the managers of talent pipelines? Scum of the Earth.
|
|
#
?
Mar 9, 2023 15:56
|
|
|
React Server Components seem like an absolute cluster gently caress to me. The programming model seems really complex for not much gain. Maybe I'm just losing my edge.
|
|
#
?
Mar 10, 2023 00:47
|
|
|
And meanwhile Sveltekit is doing cool poo poo like this https://svelte.dev/blog/zero-config-type-safety They've definitely got me peering over the fence
|
|
#
?
Mar 10, 2023 18:01
|
|
|
teen phone cutie posted:i wish i was able to get off linkedin, but honestly nothing beats in right now in terms of searching for jobs. i think indeed is basically useless at this point When I quit my job in September I was cold applying on Indeed and ZipRecruiter, but now I'm spending more time daily on LinkedIn than I've ever spent in my life. It's got most everything you need in one place, and the people that reach out thankfully aren't ghosting me. A good LinkedIn profile is just as valuable as a good resumé. I did get one guy from Colombia message me and offer to apply to jobs for me and then do my job when I got hired for a cut of the paycheck. I'm not into fraud so I said no. If you are looking for a job board that doesn't suck, I recommend Otta.
|
|
#
?
Mar 11, 2023 04:41
|
|
|
prom candy posted:And meanwhile Sveltekit is doing cool poo poo like this https://svelte.dev/blog/zero-config-type-safety I've been looking at Sveltekit as well. I've really liked NextJS for a couple of projects, but I'm intrigued..
|
|
#
?
Mar 11, 2023 05:31
|
|
|
prom candy posted:And meanwhile Sveltekit is doing cool poo poo like this https://svelte.dev/blog/zero-config-type-safety I half expect the agency I work at to switch our default web stack from Next to Sveltekit within the next year. We're contriving side projects to let us give Svelte a spin and I'm reeeeeally concerned about server components.
|
|
#
?
Mar 11, 2023 18:51
|
|
|
|
| # ? May 20, 2024 09:06 |
|
|
fsif posted:I half expect the agency I work at to switch our default web stack from Next to Sveltekit within the next year. We're contriving side projects to let us give Svelte a spin and I'm reeeeeally concerned about server components. Glad I'm not the only one. There are still some great ways to use React (Remix, Astro) but Svelte is pretty nice to work with. The Typescript support is getting better. I wish they'd allow multiple components in the same file though.
|
|
#
?
Mar 11, 2023 20:14
|
|