allover

37 ms·

331.
by allover 10y ago
Yeah, thought so.
332.
by allover 10y ago
If you disagree, tell me what I should use instead of Electron, that is feasible to use for a small team to have a wide platform reach, and with a community comparable to even just the 'React' part of web dev. The drive-by downvot
333.
by allover 10y ago
Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.
334.
by allover 10y ago
> Trying to shoehorn everything into "the web" 'Trying to shoehorn' is just your opinion. > Use the right tools for the job. What does that non-sequitur even mean in this context? Use a different native platform to
335.
by allover 10y ago
If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.
336.
by allover 10y ago
I'd always jump to something like (unix) `less` to do something like that. I don't see it as a failure of my main programming 'text editor' that it can't open log files, because I wouldn't even try that in Vim
337.
by allover 10y ago
His tone almost guarantees his complaint won't be take seriously. Also, just being nice is a generally good principle.
338.
by allover 10y ago
As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that tr
339.
by allover 10y ago
Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?
340.
by allover 10y ago
Yep, I used Sublime for a while, and I'm a Vim user as primary editor for the last 6 years. Planning on switching to VS Code full-time as soon as I can figure out how to add a couple of simple bindings to (custom) things I have setup i
341.
by allover 10y ago
> Is that seriously worth a >10x slow down to you? Speaking to VS Code here, I am yet to feel that '10x slow down', one bit, so yes it's absolutely worth it. (I don't hand-edit 5.62 MB XML files often).
342.
by allover 10y ago
> Wow, so when he says [...] Wrong thread? Not clear what you're referring to?
343.
by allover 10y ago
Seems fairly restrained, think I'd be livid if the popularity of my project had been leveraged by The Man to screw over my users.
344.
by allover 10y ago
> I think this is kind of a question of what it means for a language to be fast [...] It's significantly faster than most other dynamic languages. It's fast as a compilation target to the extent we can run Unreal Engine in the
345.
by allover 10y ago
> There is no absloute need for rendering server side Time to first paint? Mobile phones?
346.
by allover 10y ago
> - Bad Performance It's one of the fastest dynamic languages in existence, considerably faster than e.g. Ruby and Python > - Extremely weak type system Compared to what? It's a dynamic language. > - No generic language
347.
by allover 10y ago
That made it stand out. It might not have got to the front page of HN otherwise.
348.
by allover 10y ago
Hrm, can't really agree with the premise, I feel like the backend not being fast enough should never have been a significant reason to write an SPA.
349.
by allover 10y ago
More specific typography tips could be more useful.
350.
by allover 10y ago
The fact it's allowed at all is the problem though, and precisely why ES6 modules are superior.
351.
by allover 10y ago
> There's also ... [...] (I assume you meant to write your example in CommonJS style, because that's not valid a ES6 export, they must be top-level). Doesn't your example highlight exactly why even executing the code would
352.
by allover 10y ago
By that do you mean you can 'just parse' CommonJS modules? (If so) CommonJS allows you to dynamically alter module.exports anywhere within your module. You can't determine what those exports are just by parsing, you'd ne
353.
by allover 10y ago
ES6 modules are great because they're statically analysable, whilst CommonJS modules aren't.
354.
by allover 10y ago
Gotcha, thanks! Seems a shame that Redux-Form (and similar) are presented for more trivial solutions than yours. I don't see many forms that also need modification via 'other components', in a way in which that state can&#x27
355.
by allover 10y ago
Honest question, what is the reason for using a global store for form validation? That seems like the ideal use-case for local component state.
356.
by allover 10y ago
Right, but the problem is YAML parsers are crazy hard to implement correctly/safely. Its spec is an order-of-magnitude more complex than JSON.
357.
by allover 10y ago
Using JSON seems far more pragmatic than the mindset that gave birth to XSLT, so I don't really see the connection. JSON is widely used and understood, easy to parse and serialise to, and fundamentally simpler than most alternatives. Y
358.
by allover 10y ago
1. OP article has nothing to do with JavaScript. 2. It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering. 3. The JS community is vast and diverse - generalisations around
359.
by allover 10y ago
> you're trying to prematurely optimize against your very first impression [...] No I'm not, and I'm tired of 'the familiarity argument'. > elmx feels like it just complicates the view code with virtually no b
360.
by allover 10y ago
That's a tenuous argument. I've yet to meet a developer who thinks a trailing comma is the slightest bit ambiguous when the next character is a closing bracket.

More ›