|
Helicity posted:This is simply not true for sites that rely on traffic for revenue. Assuming all your assets are cached, you still have increased page download time from decorator bloat, extra time spent parsing/lexing the HTML, time parsing/evaluating the framework JS, not to mention actual render time. Again, take a look at your own web site's flame charts and you might be surprised how much performance you're leaving on the table. That is a performance goal that has to be determined on a per project basis. Some may need to be fully loaded and executed within less than a second, and some a 2-3 second load may be tolerable. Obviously yes, if every millisecond counts, you need to minimize overhead. But I don't think that matters as much as you are implying, especially if the user experience is managed properly. People aren't going to notice the extra time nearly as much if assets are loaded and displayed in a sensible order.
|
#
?
Feb 1, 2016 17:20
|
|
|
|
| # ? May 23, 2024 10:14 |
|
|
Skandranon posted:That is a performance goal that has to be determined on a per project basis. Some may need to be fully loaded and executed within less than a second, and some a 2-3 second load may be tolerable. Obviously yes, if every millisecond counts, you need to minimize overhead. But I don't think that matters as much as you are implying, especially if the user experience is managed properly. People aren't going to notice the extra time nearly as much if assets are loaded and displayed in a sensible order.
|
|
#
?
Feb 1, 2016 17:25
|
|
|
Also, you can render with React without all the React tags if you wish. That leaves the door open while still getting client performance.
|
|
#
?
Feb 1, 2016 18:23
|
|
|
what do you mean by the term "decorator" here?
|
|
#
?
Feb 1, 2016 18:26
|
|
|
Skandranon posted:That is a performance goal that has to be determined on a per project basis. Some may need to be fully loaded and executed within less than a second, and some a 2-3 second load may be tolerable. Obviously yes, if every millisecond counts, you need to minimize overhead. But I don't think that matters as much as you are implying, especially if the user experience is managed properly. People aren't going to notice the extra time nearly as much if assets are loaded and displayed in a sensible order. I specified sites that rely on traffic for revenue. My point was that it wasn't "free" to just use React on the client and that people might be shocked at how much overhead there is. Everyone assumes HTML/CSS/JS parsing is zero cost or inconsequential - people notice 1 second, and I've seen delays pretty close to that. There is no such thing as tolerating a 1 second delay for no real benefit just because some devs like using React on the front-end when your organization spends shitloads of time and money removing those 1 second delays at every other place in the process. Ideally, everyone would care about optimizing pages, but I can see why it isn't critical for many things. It sounds like our front-end use-cases are different, but that doesn't invalidate my concerns.
|
|
#
?
Feb 1, 2016 18:32
|
|
|
Helicity posted:I specified sites that rely on traffic for revenue. My point was that it wasn't "free" to just use React on the client and that people might be shocked at how much overhead there is. Everyone assumes HTML/CSS/JS parsing is zero cost or inconsequential - people notice 1 second, and I've seen delays pretty close to that. There is no such thing as tolerating a 1 second delay for no real benefit just because some devs like using React on the front-end when your organization spends shitloads of time and money removing those 1 second delays at every other place in the process. Ideally, everyone would care about optimizing pages, but I can see why it isn't critical for many things. It sounds like our front-end use-cases are different, but that doesn't invalidate my concerns. I don't think EVERYONE assumes it is a 0 cost. If they are, they are being foolish. Frameworks like Angular and React provide a tradeoff of execution speed for reduced development time/maintenance, which is the same story of moving from assembler to C#. Most of the time it is the right thing to do, as developers are expensive, and computers get predictably faster and cheaper. However, for special cases (graphics processing, news sites), maybe it makes sense to code as close to the metal as possible. I am well aware of the various performance issues with Angular, I spend a lot of time resolving them. Optimizing pages is good, but not always worth it. We don't worry about using bytes for our loop counters instead of unsigned integers because memory is cheap, even if it would be more efficient, because in most cases it's a waste of time.
|
|
#
?
Feb 1, 2016 18:44
|
|
|
caiman posted:I'm beginning to hit a pain point with my React project and am wondering if Flux is the solution. I'm still pretty unfamiliar with Flux, so my question here is basically "is this what Flux is meant to solve?" My issue is with the ever growing complexity of passing props down a long chain of components. And then sometimes I have a method in a child that needs to be called from its parent, which I know can be done but isn't recommended. So I begin second guessing my choice of which component should hold a particular state, but moving it will alter the way I call it elsewhere... and my head starts to hurt. Seconding using Redux instead of a Flux implementation. I think there's a bunch of links to other resources (the key one being that egghead video in the first reply to you) posted in the last couple days in here or the JS thread. Lumpy fucked around with this message at 19:00 on Feb 1, 2016 |
|
#
?
Feb 1, 2016 18:58
|
|
|
Maluco Marinero posted:Also, you can render with React without all the React tags if you wish. That leaves the door open while still getting client performance. Gul Banana posted:what do you mean by the term "decorator" here? I think we are referring to the difference between renderComponentToString and renderComponentToStaticMarkup: https://github.com/facebook/react/issues/1296 I would be interested in reading a blog post with benchmarks on this... I would assume (without any evidence to back this up, mind you) that the decorators make the page load faster because you don't have to touch the DOM as much during page load. But then again, that assumes you're using React.js and perhaps eliminating it is the true speed-up.
|
|
#
?
Feb 2, 2016 00:17
|
|
|
Anyone still using Knockout.js? If not, maybe someone who has in the past can offer some insight: I have an object with two boolean values. I need to represent these values across three radio buttons, one for each boolean value + 1 for both being selected. If both booleans have a value of "true", only the third radio should be checked. This use case doesn't match up with the default way Knockout and radio input binding works. This seems like something that a pattern of some kind (knock out binding handler or component maybe?) could handle, I just don't have the experience with knockout to diagnose a appropriate the solution quickly or accurately. What are my best options in a scenario like this? My ability to influence changes on the data model is very slim, so I dont think that's an option.
|
|
#
?
Feb 3, 2016 20:52
|
|
|
Sounds like you want a writable computed observable http://knockoutjs.com/documentation/computed-writable.html Never used one myself but it looks fairly straightforward. E: or just use two checkboxes because I can't imagine that being less clear :P
|
|
#
?
Feb 3, 2016 21:23
|
|
|
Helicity posted:Everyone assumes HTML/CSS/JS parsing is zero cost or inconsequential. I don't think this is even close to true.
|
|
#
?
Feb 4, 2016 00:34
|
|
|
The Wizard of Poz posted:I don't think this is even close to true. Take a guess how many milliseconds your site takes to parse HTML, CSS, and JS independently. Then compare to actual stats from dev tools. Most people I've shown that to were a little surprised, especially when they were using the latest and greatest Webpack/Bower/Gulp enabled collection of stuff. This conversation started because someone asked if React was being used for non-SPA things. I mentioned one example I was personally familiar with and some anecdotal evidence (with unneeded hyperbole) that some people didn't realize how much slower React was making the page in contrast to the minimal benefit they gained from using it in a fairly stateless situation. Our New Relic alerts go off when server response times go from 80ms to 120ms, so I was assuming that 900ms added to a specific page's load time might be cause for concern for other people in the front-end development world. I encourage you to share your own experiences with low latency issues and how you've combated them, and I'll work on minimizing hyperbole.
|
|
#
?
Feb 4, 2016 02:30
|
|
|
Helicity posted:Take a guess how many milliseconds your site takes to parse HTML, CSS, and JS independently. Then compare to actual stats from dev tools. Most people I've shown that to were a little surprised, especially when they were using the latest and greatest Webpack/Bower/Gulp enabled collection of stuff. Some people you know being a little surprised by the extent of the performance impact is not the same as "everyone assumes there is zero impact or that its inconsequential". Edit: to clarify, I accept your point that JS/CSS/HTML parsing is often not given enough attention when it comes to maximising performance. I take umbrage to the idea that you are somehow the only web developer who realises JS/CSS/HTML takes any time at all to parse, I don't think your peers are that moronic. Your hyperbole was needlessly insulting. putin is a cunt fucked around with this message at 02:44 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 02:41
|
|
|
The Wizard of Poz posted:Some people you know being a little surprised by the extent of the performance impact is not the same as "everyone assumes there is zero impact or that its inconsequential". I think he's mainly upset with some people he works with who are advocating heavy usage of 'thing they like', regardless of the costs, while his product specifically has performance goals.
|
|
#
?
Feb 4, 2016 03:00
|
|
|
Munkeymon posted:E: or just use two checkboxes because I can't imagine that being less clear :P After talking it over with our BA this is what we went with, though I did get the writeable computed observable to work before switching it over, so thanks for the TWO bits of good advice!
|
|
#
?
Feb 4, 2016 14:37
|
|
|
Goons who are familiar with Bootstrap, I need your help. I am trying to create a form and am having a weird alignment issue on the 2nd line as seen here:  And here is the code for the form section. http://pastebin.com/DQvUyPib Now you may notice on the misaligned row I have 2 cols for the first part and 9 for the second, only giving me 11 total, which would explain the misalignment. Here is the part that is bothering me. If I increase the 2nd div to 10 columns it goes to the next line instead of being inline. Any insight or help would be appreciated as I am completely new to bootstrap and doing this for a course. edit: I recreated the whole form from scratch and it looks like everything is working now. ModeSix fucked around with this message at 01:30 on Feb 10, 2016 |
|
#
?
Feb 10, 2016 00:38
|
|
|
You put a column inside a column. Get rid of this outer div:code:
|
|
#
?
Feb 10, 2016 00:43
|
|
|
Sedro posted:You put a column inside a column. Get rid of this outer div: When I remove that it then puts the Time and Date on separate lines. I need them to be on the same line. Edit: It also doesn't fix the original alignment issue. ModeSix fucked around with this message at 00:52 on Feb 10, 2016 |
|
#
?
Feb 10, 2016 00:48
|
|
|
You have a second problem. You can only put a column inside a row (or a form-group acting as a row)code:
|
|
#
?
Feb 10, 2016 01:41
|
|
|
I ended up scrapping what I had and completely remaking the form and it worked perfectly.
|
|
#
?
Feb 10, 2016 02:11
|
|
|
So, trying to wrap my head around React + Redux. Take a look at this very, very basic example I put together: https://jsbin.com/xapeza/7/edit?js,output Is this an acceptable design pattern? It seems sketchy to manually trigger forceUpdate() when one of the tenants of React is that components are supposed to just automatically respond to changes in state. I'm aware of react-redux, but I'm not quite sold on its purpose. Is it just to help connect Redux and React and avoid manually doing forceUpdate()? Does React's efficient diff engine mean that forceUpdate() isn't actually very costly?
|
|
#
?
Feb 12, 2016 03:19
|
|
|
Anony Mouse posted:So, trying to wrap my head around React + Redux. I don't know anything about Redux so this advice could be terrible and no help but that seems almost right but not quite there. It looks like stores in redux let you subscribe to them, so I would recommend having a listener in 'APP' to subscribe to your store and on an update set the state of 'APP' to the new value of the store, and have your render method use the value from 'this.state.yourBeanCounterThingy'. The flow goes: on an update set a new state for the class, state is updated so react calls the render method again, render method uses the new value of state automatically and returns the updated elements, the rest is history. Your props should only be stuff that will be changed to your class outside of it*, and your state should be stuff changed inside of it, since calling setState will re-render it automatically. *What I mean is if you pass in a value in props like [yourPropsName]='poop' then when [yourPropsName] is updated outside of the class react handles the updating of the class you're passing the prop in to.
|
|
#
?
Feb 12, 2016 03:27
|
|
|
Anony Mouse posted:So, trying to wrap my head around React + Redux. Yes it connects the two together via functions that you create describing how to map the store's state to your component's props. I highly recommend Dan Abramov's egghead.io Redux videos which go through several methods of connecting React and Redux.
|
|
#
?
Feb 12, 2016 03:33
|
|
|
Anony Mouse posted:So, trying to wrap my head around React + Redux. Saying the same thing as the other guys: don't' use forceUpdate, but subscribe to the store and set props based on it. React-redux makes this super easy and watch the egghead videos as they will show you how it all works from a 'here's how we could do it... Refactor a bit to a better way, oh, and we can improve this here and look, you just wrote react-redux!"
|
|
#
?
Feb 12, 2016 06:50
|
|
|
Update on the new job: I was severely overthinking everything as you all thought. I've spent the week learning an awesome language supported by cutting-edge technologies among a fantastic team. So far I've fixed a few bugs and started on my first solo component; the feeling after seeing my first pull request pass QA was amazing. Learning a gently caress load and still can't believe I now get paid to do one of the things I enjoy most, considering I just spent the last four years paying (to learn how) to do so. Thanks again everyone, your words and all the resources provided have been a huge help.
|
|
#
?
Feb 12, 2016 07:27
|
|
|
Came across this article today and thought it would be of interest: "Learn React without React" https://medium.com/@sharifsbeat/learn-the-concepts-part-1-418952d968cb#.kjirx7mxl
|
|
#
?
Feb 12, 2016 18:15
|
|
|
Lumpy posted:Came across this article today and thought it would be of interest: "Learn React without React" https://medium.com/@sharifsbeat/learn-the-concepts-part-1-418952d968cb#.kjirx7mxl It's a very good counterpoint to that recent "it took me ten days to build a simple app using every tool I can think of, life is terrible" article I read recently on medium. People miss that the big pick ups from react isn't a one size fits all the tool that will fix everything for you, it's a good library for building interfaces that has a very good architectural point to make. Knowing why react is structured the way it is is so much more helpful than knowing how to use the actual react framework/library.
|
|
#
?
Feb 12, 2016 18:49
|
|
|
piratepilates posted:It's a very good counterpoint to that recent "it took me ten days to build a simple app using every tool I can think of, life is terrible" article I read recently on medium. Developers (and on a larger scale - companies which employ them) tend to miss this about everything. I have heard "well that's what we bought so that's what we're going with" more times than I can count. Or even: "we have a project coming up - we'd like it written in nodeJS with a mongo backend." "uh....what's the project?" "we don't know yet - but those are the tools we want used."  People get weirdly dogmatic about all sort of code-related things. From "this library is the best" to "the opening brace should be on the same line as the function declaration."
|
|
#
?
Feb 12, 2016 19:00
|
|
|
Lumpy posted:Came across this article today and thought it would be of interest: "Learn React without React" https://medium.com/@sharifsbeat/learn-the-concepts-part-1-418952d968cb#.kjirx7mxl Bookmarking this one. I wish I had something like this when I was first starting out as I always learn faster and better when I've got this sort of overview information. Also, I never got the stuff you were sending me. Maybe check into that for me?
|
|
#
?
Feb 12, 2016 19:01
|
|
|
Thermopyle posted:Bookmarking this one. I wish I had something like this when I was first starting out as I always learn faster and better when I've got this sort of overview information. As of the other thing: Whoops! On it...
|
|
#
?
Feb 12, 2016 19:09
|
|
|
HaB posted:"the opening brace should be on the same line as the function declaration." Real talk: this is the only thing that developers should be dogmatic about in the sense that code style should be codified and not change between projects.
|
|
#
?
Feb 12, 2016 21:59
|
|
|
Blinkz0rz posted:Real talk: this is the only thing that developers should be dogmatic about in the sense that code style should be codified and not change between projects. On long running projects changing styles just become one of those things you have to deal with though. Code styles change over time for a multitude of reasons; chief among them programmer growth and different people working on the codebase. karms fucked around with this message at 23:13 on Feb 12, 2016 |
|
#
?
Feb 12, 2016 23:11
|
|
|
You should statically analyze your code style and accept nothing less than 100% adherence with automated tools handling enforcement. If you do that, it's trivial to change coding style between projects.
|
|
#
?
Feb 13, 2016 01:33
|
|
|
Blinkz0rz posted:Real talk: this is the only thing that developers should be dogmatic about in the sense that code style should be codified and not change between projects. Eh. If I can read it without having to stare at it, I'm usually fine. Plus it's easy enough now to automate formatting on a check-in or a linter run. Style changes over time for longer projects. I'm not gonna quibble over it unless it's legit unreadable. I used to work with a guy who wrote C# without putting spaces around = signs. I don't think I've ever seen a style quirk more annoying. Look: code:Doesn't look that bad for a line or two but after a page full you just go "fuuuuuck" and s/=/ = /
|
|
#
?
Feb 13, 2016 04:14
|
|
|
I have a question for people who know Angular. I'm trying to access some data and sub-data from a controller. I can access the main data no problem, but inside there is a sub-section with sub-sections. (I'm not even sure how to explain it, so try to understand that mess). Here is how I am trying to do it. code:How can I access dish.comments.rating for example, because what I have is not working. As a note this is what I am getting for output:  Notice it has 7 rows but I only have 5 pieces of data and it's not actually displaying the value in the controller data. ModeSix fucked around with this message at 20:19 on Feb 14, 2016 |
|
#
?
Feb 14, 2016 20:03
|
|
|
Your ng-repeat should be "comment in dishDetailCtrl.dish.comments"
|
|
#
?
Feb 14, 2016 20:38
|
|
|
ModeSix posted:I have a question for people who know Angular. The 7 rows are from each of the 7 properties you have on your dish object (Name, Image, Category, Label, Price, Description, Comments).
|
|
#
?
Feb 14, 2016 20:53
|
|
|
Summit posted:Your ng-repeat should be "comment in dishDetailCtrl.dish.comments" I figured that out after reading through a bunch of things on Stackoverflow. Seems strange to me to have to double specify the comments part, but now I know. Skandranon posted:The 7 rows are from each of the 7 properties you have on your dish object (Name, Image, Category, Label, Price, Description, Comments). Yeah, I figured that out when it started spitting the data out in different ways when I was messing with it. Thanks both for pointing these out to me. 
|
|
#
?
Feb 14, 2016 21:01
|
|
|
ModeSix posted:I figured that out after reading through a bunch of things on Stackoverflow. Seems strange to me to have to double specify the comments part, but now I know. It's not strange, you're not thinking right on how ng-repeat works. The first part of "comments in dishDetailCtrl.dish" is just giving the name you want to the iterator. Similar to a "foreach (string x in names)" loop, the name of the iterator need not have any connection to the collection. You could have said "aaaaaa in dishDetailCtrl.dish" and the results are the same. Your problem is in telling Angular what to iterate over. In the first case, (dish), it ends up just repeating over each property in dish, (of which there are 7), and trying to print out the rating property on each of those objects (which is always undefined). In the second case, (dish.comments), you iterate over each item in the dish.comments array, and print out the rating property on each of them (which does exist).
|
|
#
?
Feb 14, 2016 21:20
|
|
|
|
| # ? May 23, 2024 10:14 |
|
|
Note that I changed your iterator to "comment" (singular). So it's not doubly specified. 
Summit fucked around with this message at 02:22 on Feb 15, 2016 |
|
#
?
Feb 15, 2016 00:50
|
|