|
I know a good handful of backend guys who'd like to make some entry into the frontend purely because its such a 'fun' space to be in right now. I guess a lot of them will have to get over making GBS threads themselves about JS or chasing a pipe dream like Blazor.
|
# ? Aug 15, 2019 08:23 |
|
|
# ? Jun 8, 2024 21:18 |
|
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 |
|
Front-end is insanely fun right now. It's never been easier to build super cool interfaces.
|
# ? Aug 15, 2019 13:46 |
|
Ape Fist posted:I know a good handful of backend guys who'd like to make some entry into the frontend purely because its such a 'fun' space to be in right now. I guess a lot of them will have to get over making GBS threads themselves about JS or chasing a pipe dream like Blazor. This is me, and I am wholeheartedly taking on the task of unlearning some of my ancient thoughts around JS etc. But Blazor is definitely a cool product and I don't know why you would call it a pipe dream when it's barely even out yet. Just seems dogmatic in the opposite direction.
|
# ? Aug 15, 2019 14:28 |
|
Front-end is definitely super fun these days, but I do still find it overwhelming, probably because I’m comparing it to what front-end was like when I first started dabbling in web design/development - back then, Ajax was the new hotness. Still though, all this fancy new poo poo enables vastly better and more intuitive interfaces. gbut posted: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. Thanks! And good luck! In my case, I was still on front-end, but in a diminished framework monkey role that more or less shut me out of the design process for no reason I could discern but still had me churning out UI components that I just made to spec. Being pushed to the backend would have been far less insulting to me, to be honest. There’s probably something better out there. I was kept at my soon-to-be former job by depression and horrible imposter syndrome and believed I couldn’t do any better (and that there wasn’t any better) and was trapped. But then my new job has me exactly where I want to be in terms of balancing design and development and pays a crapton more. Always be looking and networking.
|
# ? Aug 15, 2019 15:08 |
|
Ape Fist posted:or chasing a pipe dream like Blazor. I want Blazor to happen so bad. Microsoft is committed to making it a realy thing but that doesn't guarantee large scale adoption. I really ought to be making prototypes of our business apps with it to find out it's feasability.
|
# ? Aug 15, 2019 15:28 |
|
My TL called Blazor 'ASP Forms re-invented' so I'm guessing I'll have to get a new job to use it for real
|
# ? Aug 15, 2019 16:20 |
|
As someone who was on a team building out web-apps with Silverlight back in 2010, let me just say I'm wary of web-based Microsoft UI frameworks. Blazor looks p cool though, hadn't heard of it until now.
|
# ? Aug 15, 2019 16:31 |
|
Doh004 posted:As someone who was on a team building out web-apps with Silverlight back in 2010, let me just say I'm wary of web-based Microsoft UI frameworks. imo the only thing that sunk silverlight was that it was a proprietary browser extension. Blazor is built on top of the WebAssembly standard so we can at least say it won't have that problem.
|
# ? Aug 15, 2019 17:18 |
|
Careful Drums posted:imo the only thing that sunk silverlight was that it was a proprietary browser extension. Blazor is built on top of the WebAssembly standard so we can at least say it won't have that problem. Famous last words
|
# ? Aug 15, 2019 18:34 |
|
Doh004 posted:Famous last words That's not to say it won't have other problems.
|
# ? Aug 15, 2019 18:41 |
|
a hot gujju bhabhi posted:This is me, and I am wholeheartedly taking on the task of unlearning some of my ancient thoughts around JS etc. But Blazor is definitely a cool product and I don't know why you would call it a pipe dream when it's barely even out yet. Just seems dogmatic in the opposite direction. I'm just pulling your balls tbh. Blazor looks fine but I'm generally worried about it being implemented well. Every asp.net developer thinks they're a full stack developer and that interpretation of full stack is basically "4.5.6 comes bundled with jquery so I guess I'll learn jquery I'm full stack now." Blazor strikes me as actually kind of just asp.net developers being stubborn about never having to leave their house.
|
# ? Aug 15, 2019 19:59 |
|
Ape Fist posted:I'm just pulling your balls tbh. Blazor looks fine but I'm generally worried about it being implemented well. Every asp.net developer thinks they're a full stack developer and that interpretation of full stack is basically "4.5.6 comes bundled with jquery so I guess I'll learn jquery I'm full stack now." Blazor strikes me as actually kind of just asp.net developers being stubborn about never having to leave their house. It's a good house For real though, most of the shops I've worked in are comprised of devs who work primarily in .NET and only learn enough HTML/CSS/JS to get the web designer off their balls. Changes are hacked together with as little JavaScript knowledge as possible. If those devs could build their UIs with .NET they'd be able to build and maintain UIs much more effectively.
|
# ? Aug 15, 2019 20:02 |
|
Front end is a mess right now and it's always been a mess and will always be a mess as long as the browser is around the difference now though is that in that mess there are quite a few tools to build with that are 1) stable with proven longevity 2) backed by great communities 3) fun as heck to use - the "ha ha new javascript framework every week" era is dead, Svelte is probably going to eventually lead to some big shifts but for a while it's going to be React and Vue and Angular as the big things...like it's been for the past few years.
|
# ? Aug 15, 2019 21:44 |
After having lived through the "large apps built in jQuery" era, and the awkwardness that followed (backbone, angujarjs), I thank the stars that the current popular tools are so good. Choosing one is all a matter of taste nowadays rather than having to choose the lesser evil.
|
|
# ? Aug 15, 2019 22:14 |
|
lunar detritus posted:After having lived through the "large apps built in jQuery" era, and the awkwardness that followed (backbone, angujarjs), I thank the stars that the current popular tools are so good. Choosing one is all a matter of taste nowadays rather than having to choose the lesser evil. back in the day, people talked about jQuery and angularjs and google closure and all that crap as if it weren't all totally ridiculous bullshit. i remember going to web development meetups and actually hearing fresh out of college junior engineers talk with straight faces about how good that crap was, and to this day if people talk about a web development tool as if it's any good, I automatically get very suspicious about their experience level - even though the modern tools actually don't suck.
|
# ? Aug 15, 2019 22:35 |
|
Bruegels Fuckbooks posted:to this day if people talk about a web development tool as if it's any good, I automatically get very suspicious about their experience level - even though the modern tools actually don't suck. Man, me too. To be fair, probably a large percentage of people saying web dev tool X is good are inexperienced, if only because frontend web dev seems to be where a lot of new developers start out.
|
# ? Aug 15, 2019 23:56 |
|
Speaking of modern web dev tools, react dev tools 4 just got release. Lots of cool new features: https://github.com/facebook/react/blob/master/packages/react-devtools/CHANGELOG.md#400-august-15-2019
|
# ? Aug 16, 2019 00:02 |
|
Thermopyle posted:Speaking of modern web dev tools, react dev tools 4 just got release. Lots of cool new features: Speaking of React: I decided that I should learn it too, to not be left too far behind. And I did my little app in it. The app accesses the webcam on the client and sends the video to the server (using MediaRecorder via websocket at the moment) and gets back the things that were recognized in the movie and displays them overlaid on the webcam stream. I am studying now if WebRTC would help even if I don't have a P2P connection, just client-server. Anyway, React: I have experience with Angular 1.x and 6.x, Vue latest versions, jQuery back in the dark ages and I must say that React has not impressed me. It works, it does the crap it does, but ... meh. Really? The hype is way overblown.
|
# ? Aug 16, 2019 00:15 |
|
With modern Angular and Vue experience, I don't think React is offering anything especially compelling except maybe Hooks. I really like React Hooks. I think React got as much traction as it did because it was the first one of the latest generation of frameworks to really sink in to the hivemind and it has been continuously improved on.
|
# ? Aug 16, 2019 00:27 |
|
I'll happily develop with Vue or React. Less so with Angular, but it's ok. All three of them are in another loving league compared to what came before.
|
# ? Aug 16, 2019 00:50 |
|
Anyone used Victory or any other react-friendly data-vis libraries? I’m trying to make print to pdf docs (data driven documents for customer executive teams using their organization’s data) with data vis in a react app and I’m wondering if I’m going to have to roll my own D3 solution or if there are some real robust libraries out there. I specifically need things like circular gauges, custom placement labels, temperature fill style horizontal gauges with additional indicators for top quartile, etc. I can deviate from the design if I need to, but it needs to be in the same spirit.
|
# ? Aug 16, 2019 01:14 |
|
If you need truly custom visualizations (and not just variations on the types of charts that charting libraries can provide), you might just want to stick with D3 instead of trying to bend charts from charting libraries to your will (I had a recent bad experience trying to make an out-of-the-box library solution be something it wasn't meant to be so maybe there's a bit of bias). I've poked around in both Victory and React-Vis and I didn't find their chart selections particularly great - gorgeous charts, but only so many types (didn't see any fill gauge-like things). Also I suppose I should note that I've only ever used D3 itself for data visualizations so I don't actually have any direct experience using charting libraries. As for using D3 in React, I'm partial to the implementations where you have D3 handle its own rendering directly to the DOM (and also its own transitions and animations) and wrap it in a React component. Apparently the useEffect() hook thingy lets you do it this way very easily (I've not gotten into React Hooks yet but am going to learn soon).
|
# ? Aug 16, 2019 03:22 |
|
I'm in the process of publishing my first NPM TypeScript package for work, and I'm looking for some mentorship here. After spending some days configuring things, I think I've got a solid solution, but I'm asking for some help because we have some interesting caveats. 1. We're using lerna to give us a monorepo. We currently have one not-to-be-published package (the main website), and one other package (the base API calls - let's call it APIPackage. This is the one we're publishing.) 2. the website relies on the APIPackage since our website is also making the API calls, so it's important to be able to hot-reload updates to my APIPackage's src so that the website can listen for changes. And then be able to build and publish changes once a week. I want to know if this sounds sane in APIPackage project: 1. First use the TypeScript compiler to generate d.ts files so that they can be imported by other people into their TS projects 2. Secondly, use Babel 7 to transpile to ES5 in UMD module format into a directory called lib, so they can be imported like so: * import { blah } 'from APIPackage/lib/someModule' 3. Use Webpack to ONLY bundle the .js files in the dist folder into a index.min.js file in the root 5. Use a webpack plugin to bundle the d.ts files as well. 6. Finally publish the dist folder, index.min.js and the index.d.ts files (along with package.json and other defaults) to NPM * OR do I not publish the dist folder and just force people to import from the bundled index.min.js???? teen phone cutie fucked around with this message at 03:50 on Aug 16, 2019 |
# ? Aug 16, 2019 03:45 |
|
I don't have experience with teh other big frameworks but React is fun and the things built on it work fairly well. I enjoyed loving around with gatsby for a weekend to make a portfolio page.
|
# ? Aug 16, 2019 06:10 |
|
React is the Final Fantasy 7 of Front End Frameworks. It's good, hell it's great. But it was also the right thing at the right time and other things might have come along in the meantime which are doing things better and more efficiently.
|
# ? Aug 16, 2019 06:20 |
|
Wrong thread.
RC Cola fucked around with this message at 12:53 on Aug 16, 2019 |
# ? Aug 16, 2019 12:50 |
|
I really like React right now but I don't think you should ever get too emotionally attached to a library or framework. Something better is always going to come along and if you're not open to moving on you can get stuck with an outdated skillset.
|
# ? Aug 16, 2019 13:22 |
|
Ape Fist posted:React is the Final Fantasy 7 of Front End Frameworks. It's good, hell it's great. But it was also the right thing at the right time and other things might have come along in the meantime which are doing things better and more efficiently. drat is React that good? I've really only hosed around with AngularJS and Angular (and Polymer but that was a poo poo show). I don't want to support React because it's from FaceBook, but if it's that killer then I guess if you can't beat 'em join 'em
|
# ? Aug 16, 2019 15:25 |
|
Careful Drums posted:drat is React that good? I've really only hosed around with AngularJS and Angular (and Polymer but that was a poo poo show). I don't want to support React because it's from FaceBook, but if it's that killer then I guess if you can't beat 'em join 'em Just be careful, it might kill your girlfriend
|
# ? Aug 16, 2019 15:31 |
|
Queen Victorian posted:If you need truly custom visualizations (and not just variations on the types of charts that charting libraries can provide), you might just want to stick with D3 instead of trying to bend charts from charting libraries to your will (I had a recent bad experience trying to make an out-of-the-box library solution be something it wasn't meant to be so maybe there's a bit of bias). I've poked around in both Victory and React-Vis and I didn't find their chart selections particularly great - gorgeous charts, but only so many types (didn't see any fill gauge-like things). Also I suppose I should note that I've only ever used D3 itself for data visualizations so I don't actually have any direct experience using charting libraries. Thanks for the response. Like you said, the charting libraries have pretty charts, but I do worry I'll be wasting a ton of time bending them to my will. I'm not uncomfortable with writing D3 code, I've just struggled in the past in getting D3 and React to share the DOM nicely. Most of the solutions I've heard of in the past involve avoiding ~30% of D3's functions (the ones that touch the DOM) and leave that to React. This is the first time I've heard of encapsulating the code in a function component and using a useEffect hook. That actually... makes a lot of sense. I'm probably going to give that a try. Nudging me towards thinking about D3 + React in a post-hooks world was just what I needed!
|
# ? Aug 16, 2019 15:41 |
|
Still waiting for Chrome to fix whatever year+ long issue that WebWorkers do not support modules. After that pops out I hope to see more realistic versions of React and whatever that offload everything from the renderer thread. Comlink makes that really quite nice, but wanting supporting multiple threading models still becomes a bit ugly: (1) process in the renderer, (2) process in a WebWorker or SharedWorker, and (3) work in a nested WebWorker. I've given up on #1 and work with combinations of #2 or #3 depending how many cores the browser reports the platform supports.
|
# ? Aug 16, 2019 19:56 |
Careful Drums posted:drat is React that good? I've really only hosed around with AngularJS and Angular (and Polymer but that was a poo poo show). I don't want to support React because it's from FaceBook, but if it's that killer then I guess if you can't beat 'em join 'em lol at boycotting facebook by using a google product
|
|
# ? Aug 16, 2019 20:01 |
|
lunar detritus posted:lol at boycotting facebook by using a google product The irony isn't lost on me. I just keep ending up working with companies that use Angular. If that wasn't the case I probably wouldn't know any Angular. The most moral framework, clearly, is Ember.
|
# ? Aug 16, 2019 21:04 |
|
Or thi.ng.
|
# ? Aug 16, 2019 21:08 |
|
Ruggan posted:Nudging me towards thinking about D3 + React in a post-hooks world was just what I needed! Awesome! Hope you get some good visualizations working. I’ll probably spend some of the week off I have between jobs brushing up on D3 and also playing around with useRef() + useEffect() React wrappers (had previously been tinkering with classes and lifecycle methods to pull it off, which was pretty cumbersome). I also didn’t like a lot of the “React first” D3 integration strategies I read about that have React do all of the DOM touching (except for brushes and axis transitions and other things the virtual DOM can’t handle) because they muddy the division of DOM handling and also make D3 more difficult to deal with because it’s all chopped up and no longer resembles the D3 in the documentation or examples or most SO threads. But then again, those sorts of solutions are generally pushed by people who learned React first and might not know D3 as well, so naturally they want React front and center. (At least a couple articles I came across were openly disdainful of D3, like “ew gross D3 touches the DOM like some sort of backwards savage this must be remedied”) The D3-first crowd is much more into the solutions that have D3 operating at full capacity without some framework getting in its way. There are fewer of these articles because there are just way more React people out there writing about React-centric solutions.
|
# ? Aug 16, 2019 21:42 |
|
Careful Drums posted:drat is React that good? I've really only hosed around with AngularJS and Angular (and Polymer but that was a poo poo show). I don't want to support React because it's from FaceBook, but if it's that killer then I guess if you can't beat 'em join 'em The real draw to react is the support network. Great tools, great examples, active community. There are other component based frameworks that are just as good, if not better, but they don't have react dev tools and a thesis written about every possible little issue you could have.
|
# ? Aug 16, 2019 21:47 |
|
Yeah, if you run into an issue with React, Dan Abramov has probably written an essay about it.
|
# ? Aug 16, 2019 22:17 |
|
And you can then ask him about it on Twitter and he'll explain it even further.
|
# ? Aug 17, 2019 13:53 |
|
|
# ? Jun 8, 2024 21:18 |
|
I'm trying to deploy my React site with a react-router BrowserRouter on S3 but having issues. I'm very new to using Amazon AWS as anything but a VPS. To start I put a staging version of my React site on an S3 bucket and of course it works fine if I go to https://my-dumb-site-dev.us-east-2.amazonaws.com/index.html and click around but doesn't work if I go to a deeper URL, it 404s which makes sense. Do I need to use CloudFront? On the VPS I would just use a try_files or rewrite directive in nginx to serve up index.html and pass the rest of the URI into my app for the BrowserRouter to pick up.
|
# ? Aug 17, 2019 19:37 |