allover

15 ms·

121.
by allover 8y ago
> If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? Sadly it seems that's mainly been cargo-culted. It's not the case that Rea
122.
by allover 8y ago
> these typical slow react experiences Again, this is a really bad generalisation you're making. It is ludicrous to attribute the types of slowness you're talking about to React. > Compare that to Googles search for example
123.
by allover 8y ago
> Twitter lite: Where is that? https://mobile.twitter.com > AirBnB ... Maybe not the best example. I think they still have a lot of legacy cruft they need to fix. I still think their homepage/search UX is pretty good.
124.
by allover 8y ago
Twitter Lite and Airbnb are obvious examples not behind a login. I'm sure there are countless good examples in this list: https://github.com/facebook/react/wiki/Sites-Using-React But React and other SPA
125.
by allover 8y ago
I think sadly a lot of it is just FUD. Refer to the comments about npm I'm addressing elsewhere in this thread. They're just ill-informed, or deliberately throwing shade.
126.
by allover 8y ago
> Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5. No it doesn't. Since npm 5, npm is lockfile-by-default, you don't get updates unless you ask for them.
127.
by allover 8y ago
npm does maintain a lockfile for you by default since npm 5, if that's what you mean. There really is no reason to be encountering surprise sub-dependency changes with npm.
128.
by allover 8y ago
Why? Do you think users would really notice the difference between React Native and native?
129.
by allover 8y ago
> That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix. That just sounds like a poor und
130.
by allover 8y ago
> Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. That was all I was responding to. I definitely learned some cool stuff
131.
by allover 8y ago
> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be
132.
by allover 8y ago
The go team recognise there's a fundamental problem with it, otherwise they wouldn't have created dep and vgo [1] [1] https://github.com/golang/go/issues/24301
133.
by allover 8y ago
Stating the obvious, but that's the fault of whoever decided to do it in Angular and didn't understand the trade-offs of single page apps. If an app can be just as easily (or more easily) implemented server-side with no 'rele
134.
by allover 8y ago
> But what happens when you inevitably need to step outside the boundaries set by create-react-app? Been working on a real-world c-r-a based project for 8 months and this is yet to happen. And the upgrade process has been a dream (update
135.
by allover 8y ago
And I 100% disagree. If you're new to React I strongly recommend sticking with classes and embracing React's 'component' model which is one of its strengths and which Redux + trying to use only stateless functional compo
136.
by allover 8y ago
> Is it just for front-end developers? 1 out of 15 examples (the Docker one) don't involve HTML or JS. (And backend JS devs are generally pro-JS so likely aren't using NoScript either). Do you use NoScript? Maybe you do and you
137.
by allover 8y ago
In general, one should consider the audience of the content, not NoScript users, in this case. > JS is a big security/privacy risk. No, 3rd party JS (and 3rd party cookies, JS regardless) allow you to be tracked. And ad-blockers dea
138.
by allover 8y ago
No probs :) DI is something I battled to understand for a while!
139.
by allover 8y ago
The audience for this site is front-end developers. Front-end developers don't tend to view the web with NoScript. Just like 99% of users don't view the web with NoScript.
140.
by allover 8y ago
Yes, that is DI too, you can think of it something like 'injecting a shared singleton service', and yes the passing into a constructor is the basic approach you might call 'manual DI'. And yep modules can let you avoid t
141.
by allover 8y ago
Well one way you avoid the need for DI is that if you are only using DI to allow you to swap out real collaborators for fakes in your tests ... to instead simply mock module imports in your tests, (to mock those collaborators). This is comm
142.
by allover 9y ago
How so? JS is backwards compatible in the extreme, because browsers. New features does not equal unstable.
143.
by allover 9y ago
> Hows that? There's a balance and you missed it both times
144.
by allover 9y ago
GPP asked a general question, they weren't referring to the UI in the article.
145.
by allover 9y ago
[deleted]
146.
by allover 9y ago
> Experience? [...] > And it’s only a matter of time untill that piles up enough to justify using native UI from the start. That's a little hyperbolic and counter to my experience.
147.
by allover 9y ago
> Is it really so hard to write a native GUI for three OSes if you must? Yes. What makes you think otherwise?
148.
by allover 9y ago
> Overwriting tags should honestly not be possible, ever. Node / NPM did that (I think) with one of their versions too. Or was it a npm package? npm did away with `publish -f` (which would allow that) 4 years ago [1]. [1] http:&#x2
149.
by allover 9y ago
That's the fault of Medium, not the author. Are you going to post this comment on every Medium post?
150.
by allover 9y ago
> Good guidance badly executed. Could you not think of a nicer way to word this, given that you consider the guidance 'good', and presumably understand a lot of work went into it?

More ›