|
Hed posted:I'm trying to deploy my React site with a react-router BrowserRouter on S3 but having issues. With any SPA that has routing you need some kind of rewrite to specify that all requests should go to /index.html, I've never done it on S3 but maybe this? https://medium.com/@ervib/how-to-set-up-react-router-and-deploy-to-amazon-s3-d3dffa6ae43 (halfway down it has some setting where you can get it to serve index.html as the error document)
|
#
?
Aug 17, 2019 20:15
|
|
|
|
| # ? Jun 1, 2024 21:41 |
|
|
Thank you for the response, I had actually been looking at that! Also meant to thank you for the API response, I did a similar thing last week to wire up all my endpoints. I got it working but it was silly, the S3 bucket access address is slightly different from the "use as static hosting" address, almost subtly so. Going to https://my-dumb-site-dev.s3-website.us-east-2.amazonaws.com/butts/extreme does everything as expected.
|
|
#
?
Aug 17, 2019 21:18
|
|
|
please post the real link to your extreme butts website tia
|
|
#
?
Aug 17, 2019 22:09
|
|
|
Vincent Valentine posted:The real draw to react is the support network. Great tools, great examples, active community. This is why React will continue to be a key web technology for many years. Also, they don't just rest on their laurels. Since its creation React has underwent fundamental changes while providing clear transition paths. It's a Good Project.
|
|
#
?
Aug 19, 2019 19:55
|
|
|
I'd say it's also fundamentally different from how FB has handled a lot of its other open source projects before. React is good.
|
|
#
?
Aug 19, 2019 20:00
|
|
|
Speaking of Facebook projects, what’s the latest on npm vs yarn? It seems to have just settled into two stable camps but I may be out of the loop.
|
|
#
?
Aug 20, 2019 13:05
|
|
|
smackfu posted:Speaking of Facebook projects, what’s the latest on npm vs yarn? It seems to have just settled into two stable camps but I may be out of the loop. Weird. We were just having this discussion at work. So the gap between the 2 has closed considerably. Yarn is now only slightly faster. But the biggest advantage I found to yarn is: the install is deterministic, and npm's is not. In other words, if 2 devs on 2 different machines use yarn, their node_modules folders will be identical. There is no guarantee of that with npm. I know I have encountered Weird poo poo™️ that was only solved by blowing away node_modules and re-running npm. I can't recall ever having to do that with yarn. YMMV, as always.
|
|
#
?
Aug 20, 2019 13:34
|
|
|
I think npm has also solved that issue with package-lock.json, no? I switched to yarn because of that though and I just never switched back.
|
|
#
?
Aug 20, 2019 13:46
|
|
|
HaB posted:Weird. We were just having this discussion at work. npm has done deterministic installs for at least a couple of years now. I've got a pretty large mix of projects I'm involved in using both package managers and it's not terribly uncommon that wiping out node_modules fixes weird poo poo...for both yarn and npm. For new projects I just use npm nowadays. It's basically on par with yarn as far as I'm concerned and I'm less likely to accidentally type yarn when I actually should've typed npm...it's not terribly uncommon for me to do the reverse on yarn-using projects. I think that's because every doc out there mentions using npm but less of them mention npm and yarn and hardly any mention only yarn. Thermopyle fucked around with this message at 15:23 on Aug 20, 2019 |
|
#
?
Aug 20, 2019 15:20
|
|
|
I've been happy with npm and using package-lock. I actually haven't heard anyone near me say they use yarn anymore.
|
|
#
?
Aug 21, 2019 01:12
|
|
|
yeah I just started using yarn a couple years back and never could be assed to look into switching back.
|
|
#
?
Aug 21, 2019 01:47
|
|
|
code:
|
|
#
?
Aug 21, 2019 01:51
|
|
|
Someone at work made a "It has been {numDays} since the last npm fiasco" app after the Bitcoin mining thing, clearly as a joke rather than actual criticism, but the fact that it was a joke everyone understood is enough to be uncomfortable. We all did and continue to use npm, but still. There never seems to be equivalent drama with yarn. Is that just luck, or does yarn handle permissions and things differently?
|
|
#
?
Aug 21, 2019 02:16
|
|
|
Vincent Valentine posted:Someone at work made a "It has been {numDays} since the last npm fiasco" app after the Bitcoin mining thing, clearly as a joke rather than actual criticism, but the fact that it was a joke everyone understood is enough to be uncomfortable. We all did and continue to use npm, but still. There never seems to be equivalent drama with yarn. yarn is exactly as vulnerable to this poo poo as npm the package installer...they both install packages from the npm package repository. People were installing the same bitcoin miners with yarn as they were with npm.
|
|
#
?
Aug 21, 2019 02:24
|
|
|
Yeah, that's fair. I have to admit I know gently caress all about it, other than going "ahh yeah that's the other npm" when I see it during documentation.
|
|
#
?
Aug 21, 2019 02:42
|
|
|
Vincent Valentine posted:Yeah, that's fair. I have to admit I know gently caress all about it, other than going "ahh yeah that's the other npm" when I see it during documentation. Yarn is the same packages, just a different implementation of how you get them from the internet into your codebase. Honestly, npm is a joke. The fact that we didn't laugh npm out of existence after the left-pad incident is enough to to indict the whole system.
|
|
#
?
Aug 21, 2019 13:59
|
|
|
What's the alternative though? The worst part about that fiasco isn't that someone was able to unpublish their poo poo, it was that npm the organization handed control of someone else's names to a larger org.
|
|
#
?
Aug 21, 2019 14:22
|
|
|
Yeah, that's the hard part. To the best of my knowledge, there isn't yet a practical alternative. It's just so cost-effective to use open-source packaging at the price of some security and reliability instead of writing everything from scratch.
|
|
#
?
Aug 21, 2019 14:31
|
|
|
Frameworks and webpack are grave sins of modern front-end development. Thanks for coming to my TED talk.
|
|
#
?
Aug 21, 2019 18:03
|
|
|
Like most grave sins they feel fuckin good
|
|
#
?
Aug 21, 2019 18:06
|
|
|
Github Packages looks pretty promising, but there will so much loud screaming about Microsoft if it starts catching on
|
|
#
?
Aug 21, 2019 18:13
|
|
|
How deep down the rabbit hole do you have to be to believe that any of this feels good? Everything is extremely buggy and created to facilitate the overengineering of user interfaces. Frameworks solve a non-problem, and only end up making the process more complicated than it has to be, which naturally introduces more chances for poo poo to break. But the real offender is tools like webpack that are written with amateur-level quality. Recently I experienced the "good" feeling of webpack randomly optimizing a variable away, despite it being passed as an argument 5 lines after declaration. Logging the variable to the console prevented this behavior. What a loving amazing tool. The only thing that feels "good" about this ecosystem is cunning zoomers swindling hiring managers by writing 1 line modules and hitting npm publish, then moving on to sucking dry the pockets of dumbass SV investors who pay for dogshit gimmick webapps that run on megabytes of dependencies. It's not hard to deserialize an HTML document in vanilla JS. Jquery even has a function specifically for that. You don't need a 400MB framework to conditionally render complex element chains. Nor do you need one to manage interface state in a clean and concise manner.
|
|
#
?
Aug 21, 2019 18:41
|
|
|
I'm going to continue to use GraphQL in any front-end project I can shove it in and I'm going to enjoy it.
|
|
#
?
Aug 21, 2019 18:50
|
|
|
This proliferation of How!! reregs is a disturbing phenomenon.
|
|
#
?
Aug 21, 2019 19:41
|
|
|
Why won't you morons just write 5000 line long CSS and vanilla JS files like you used too!!!!!!!
|
|
#
?
Aug 21, 2019 20:16
|
|
|
Dont Touch ME posted:How deep down the rabbit hole do you have to be to believe that any of this feels good? Everything is extremely buggy and created to facilitate the overengineering of user interfaces. Frameworks solve a non-problem, and only end up making the process more complicated than it has to be, which naturally introduces more chances for poo poo to break. But the real offender is tools like webpack that are written with amateur-level quality. Recently I experienced the "good" feeling of webpack randomly optimizing a variable away, despite it being passed as an argument 5 lines after declaration. Logging the variable to the console prevented this behavior. What a loving amazing tool. please tell me you don't get paid to work in this industry in 2019
|
|
#
?
Aug 21, 2019 21:29
|
|
|
prom candy posted:please tell me you don't get paid to work in this industry in 2019 trolls be trollin
|
|
#
?
Aug 21, 2019 21:32
|
|
|
prom candy posted:please tell me you don't get paid to work in this industry in 2019 Good news, how's been complaining in the oldie thread that he can't get a job!
|
|
#
?
Aug 21, 2019 21:36
|
|
|
https://www.youtube.com/watch?v=hYAuR5bkIlQ
|
|
#
?
Aug 21, 2019 22:09
|
|
|
Dont Touch ME posted:How deep down the rabbit hole do you have to be to believe that any of this feels good? Everything is extremely buggy and created to facilitate the overengineering of user interfaces. Frameworks solve a non-problem, and only end up making the process more complicated than it has to be, which naturally introduces more chances for poo poo to break. But the real offender is tools like webpack that are written with amateur-level quality. Recently I experienced the "good" feeling of webpack randomly optimizing a variable away, despite it being passed as an argument 5 lines after declaration. Logging the variable to the console prevented this behavior. What a loving amazing tool. back_end_developer.log
|
|
#
?
Aug 22, 2019 00:45
|
|
|
code:
|
|
#
?
Aug 22, 2019 00:46
|
|
|
Ruggan posted:back_end_developer.log Honestly I've seen plenty of back end developers with this exact opinion and when you peel it back a few layers it basically becomes "I'm scared of Javascript."
|
|
#
?
Aug 22, 2019 07:09
|
|
|
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
|
|
|
Hey friends, I am making an app that has to scrape Wikipedia using a MERN stack. However, I get this error.  The current workaround I am doing is just using an unsecured chrome browser, but since I have the rest of the app working, I want to get it properly working. How do I go about implementing CORS into my code? Right now the scrape is happening on the front end. It just does an axios GET call and gets the following error^ I see things about adding options and am not too sure what to do with it. I tried converting scrape into the backend as a route and haven't had too much more success. It seems like that is just an added variable in trying to troubleshoot this. Any ideas? Let me know if/what code snippets I should post in here if any. This is my first time trying to use CORS, so I'm not sure of the right questions to ask.
|
|
#
?
Aug 22, 2019 12:39
|
|
|
This will probably help, basically it's a browser security thing that's purposefully difficult to work around from the front end. https://gist.github.com/jesperorb/6ca596217c8dfba237744966c2b5ab1e
|
|
#
?
Aug 22, 2019 12:57
|
|
|
Ape Fist posted:Honestly I've seen plenty of back end developers with this exact opinion and when you peel it back a few layers it basically becomes "I'm scared of Javascript." But there was a bug! In a tool! This never happens with back-end tooling ever  RC Cola posted:Hey friends, I am making an app that has to scrape Wikipedia using a MERN stack. However, I get this error. How are you injecting a script into the site? Tampermonkey will mess with CORS headers for you, so maybe consider using it to do that for you.
|
|
#
?
Aug 22, 2019 15:17
|
|
|
Munkeymon posted:But there was a bug! In a tool! This never happens with back-end tooling ever > "What is this NPM warn error? I don't trust Node/NPM and am scared of it." "It's nothing, unless its red don't worry about it." > "But its a warning, we shouldn't use it." "We're using it because its slightly out of date but its the version our build system uses and its still secure." > "If there's a warning its not secure, and we should update it." "Then we'll need to rebuild the entire front end transpiling system to accommodate that." > "So do that!" oh ok.
|
|
#
?
Aug 22, 2019 16:31
|
|
|
Oh my loving fave was that the NuGet library for Node installs node 5.6 into the solution in a local installation and has officially been depreciated and Microsoft now recommends you directly install Node on your machine from the latest long term support build but .NET developers will literally have a mental breakdown if they have to include something in their Solutions which aren't directly installable via NuGet and even if NuGet installs an extremely out of date piece of poo poo then its good enough and it'll have to do.
|
|
#
?
Aug 22, 2019 16:33
|
|
|
It's possible to have a [backend|frontend] with a fully functional and well-designed [REST API|UI], but the [backend|frontend] is still bad because the code is a poo poo show of unmaintainable spaghetti. As a full-stack guy I think there's a lot of reasons backend guys are kind of iffy on frontend: 1. For a long, long time frontend coding just was simpler than backend. 2. For a long, long time the tooling was just terrible on the frontend compared to the backend. Now it's just bad instead of terrible  .3. Frontend is a common place for programming newbies to start out, so it has an air of newbiness. 4. other stuff This reminds me of something I've been thinking about lately... I think the backend/frontend dichotomy is a little limiting of a way to think about it anyway. There's a ton of work on a (let's say) React/Redux application that has very little, if any, visible UI. Sure, all that code runs in the browser, but it likely has more in common with backend code than your frontend work. I'm not sure lumping that skillset in with the skillsets required for actual UI work is a useful way to think about it.
|
|
#
?
Aug 22, 2019 16:35
|
|
|
|
| # ? Jun 1, 2024 21:41 |
|
|
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
|
|