291–300 of 304 posts
Earlier quoted context omitted.
Same company, you just have to choose where to spend your resource, and from the analysis it looks like the operations and management side isn't where GitLab chooses to spend it's money.
So you think they should pull their front-end dev team to do operations instead? I doubt that would go down so well.
Earlier quoted context omitted.
So you think they should pull their front-end dev team to do operations instead? I doubt that would go down so well.
No, I think they should hire more people to do operations.
You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…
For complex pages, AJAX is going to pay off in the long run. It's a matter of whether you can avoid having to implement and debug your entire app 2-3 times in order to get that behavior. That's the (mostly undelivered) promise of Node.
But at this rate web assembly may server code written in more robust languages to find its way into the client and take market share. As someone who grew up on the advantages of static code analysis, I look forward to getting some of that power back.
Earlier quoted context omitted.
When a react component tree has more than 3 level height, react component's lifecycle callbacks start getting crazy unmanageable. Mounting, unmounting, rendering, props receiving, updating etc, these callbacks' calling orders open to bad rendering practice(e.g. unnecessary render, unexpected calls), that's why people avoid putting logics in there. It claims to be self-contained but parent-child communication breaks i…
> It claims to be self-contained but parent-child communication breaks it in several ways I think you'll find that most react developers advise against doing parent-child communication in react components for all but the simplest cases. Does it involve writing higher order components? Probably. Curious, why aren't you a big fan of them?
A concrete example is responsive table components with the help of HOC, says `react-dimensions` (sorry author, I have to mention here but there is nothing specifically wrong with it), why do I need it as a separate component? Oh flexibility and reusability but when I tried wrapping 2 or 3 table libraries with it, it sucks at rendering on desktop, even worse on mobile! I gave up on performance issue. Ah that doesn't mean the HOC technique itself is bad, but from my experience it is.
Earlier quoted context omitted.
When a react component tree has more than 3 level height, react component's lifecycle callbacks start getting crazy unmanageable. Mounting, unmounting, rendering, props receiving, updating etc, these callbacks' calling orders open to bad rendering practice(e.g. unnecessary render, unexpected calls), that's why people avoid putting logics in there. It claims to be self-contained but parent-child communication breaks i…
I know what you mean with regard to event handlers being passed down to children and children of children and so on and the complexity that can bring. I haven't used redux, but I understand it as being an attempt to simplify that kind of problem. I haven't written any higher order components myself, unless you consider parameterizing event handlers in props to be higher order.
Earlier quoted context omitted.
There are two types of two-way binding. 1. Bad Two Binding i.e. Two way binding between components. Vue2 and most of the UI frameworks shun this. 2. Good two way binding i.e. Form model binding. Because form input can actually come from two sources (user input and javascript). this is naturally two-way and this is why frameworks continue to keep it.
I think the second one isn't really a valid example. There are very few situations where you both want to have state mutations discard what the user has already entered and reflect user-provided state in real time. In other words even if it's supposedly "two-way" you don't actually want multiple inputs to share the same model and you likely don't want to represent the data the same way the form control needs to repre…
Naive one way binding is useless as well.
>two-way binding of the actual form fields becomes an implementation detail.
Kinda. In fact in Vue two-binding is a syntax sugar for one way binding and on change events.
The difference between them, is one requires less lines of code and is less powerful.
If you do need react-style form input, then you can do it that way.
Earlier quoted context omitted.
Refactoring into functions/components doesn't magically make a complex ternary tree go away. It helps the body of each branch be less noisy but the ternary tree will still be there. You're talking about taking something like `foo && bar || baz && quux` and turning it into `isSomeCondition()`, but that's a pretty obvious refactor in any templating system. I'm talking about things like return ( { x.type === 'foo' ? : x…
Without understanding what x.type is, I'd be inclined to write that without any ternary operator at all using plain old if statements with each returning JSX markup. I try to keep logic in JSX to simple ternary operators and loops at most. JSX is really just shorthand for DOM.div() for me. I imagine the code structure looks pretty similar to actually using DOM.div though. I'm not seeing how programmatically creating…
Earlier quoted context omitted.
Without understanding what x.type is, I'd be inclined to write that without any ternary operator at all using plain old if statements with each returning JSX markup. I try to keep logic in JSX to simple ternary operators and loops at most. JSX is really just shorthand for DOM.div() for me. I imagine the code structure looks pretty similar to actually using DOM.div though. I'm not seeing how programmatically creating…
Yep. I very much prefer to keep all the actual _logic_ outside the JSX structure, and storing all conditional stuff in temp variables. I have an example of my preferred approach at https://gist.github.com/markerikson/47fff93c92286db72b22bab5... .
Earlier quoted context omitted.
We have no plans to move to another Ruby implementation, primarily because Ruby itself is not yet a bottleneck for us.
Is it something you'd consider? Even if it's not a performance bottleneck right now it's probably worth it to reduce server costs (more efficient Ruby implementation = fewer servers required to run GitLab.com). Could be looking at serious gains, 3x over CRuby looks to be a fairly reasonable goal when using RubyTruffle (slow startup times can be mitigated against with SubstrateVM), and if that's not an option due to i…
1. Replace Ruby implementation
2. ???
3. Everything is 3x faster
Whatever an implementation or product claims, it's just not possible. While we could benefit from not having a GIL (something Truffle has if I'm not mistaken), it's not a free trade-off. For example:
* JRuby typically requires quite a bit more memory compared to CRuby, the same probably applies to Truffle
* Dependencies might have to be replaced if they're written in C. I personally don't buy Truffle being able to support all extensions. It's super fucking hard. I spent a few years working on Rubinius and had the unfortunate experience of having to deal with C extensions a lot. Supporting these properly is really, really difficult.
* JRuby might not work on all platforms we support. For example, we support Raspberry Pi's and the likes and it's not clear if JRuby would work there
Most importantly of all: a large portion of our slowness is due to badly written SQL queries, code that hammers the database way too often, and our Git operations. None of this would be solved by switching to a different Ruby implementation. The only way to solve this is to:
1. Solve the code
2. Educate developers so they don't make the same mistakes
3. Add linting rules and the likes so our CI environment catches any mistakes (where possible)
Earlier quoted context omitted.
I'm a C# guy and even I would say the JSX is far more readable there. I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case.
I don't mind if people prefer JSX its just a shocking cost - rewriting language ASTs, build tools and IDEs for something that rhymes with html but is really only a couple of characters away from standard language constructs. > I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case JSX is literally an extra level of abstraction. You are not writing html but calling…
You would have to write the transpiler anyway, since on a larger team if you're working with a designer, you would probably get HTML from them and soon get tired of manually translating it to function calls.
I'd bet this is how JSX got started in the first place.