Hacker Newsnew | comments | show | ask | jobs | submit | Wintamute's comments login

Indeed, well said. Seems just as plausible, if not more so, that the anxiety is a symptom of poor familial aptitude for mathematics than the cause itself. But that's a thoughtcrime these days, so best not mention it ...

But until we know something provable about genetics and mathematical aptitude this line of thought is just hand-waving. You still don't know any better than anybody else why somebody is having a hard time with math.

That's why I said it seems "just as plausible" as the alternative. Its the article that's making the more definitive statements, not me. Besides, I think there's a reasonable amount of science that makes the argument for genetics over nurture quite compelling, but 20 years of malpractice and misdirection in the social sciences obfuscated that.

Ah, but it's only a thoughtcrime if you don't say it, and people call you an idiot for just thinking that.

A lot of the latest thinking in (non-JS) CSS suggests that violating DRY is an excellent idea. Copy and pasting CSS rules is cheap, but maintaining and adapting a large complex CSS project that's blowing up in a team's face can be very expensive.

I imagine a common architecture for universal apps will be to just use some sort of thin Node.js app to perform the actual app rendering, and have it communicate with a separate API app written in whatever language is most appropriate. Static files could either be served by the Node.js app, or even a different source.

And these days ES6/ES7 makes Javascript very palatable indeed. Check it out :-)

-----


That's exactly how you do it :)

You have one 'Universal Application', and then you have two small entry points: - server.js is a small (express) server to send a HTTP response to the client (server bootstrapping) - client.js renders a page and the mounts it onto a DOM node.

To get around the issues of database access, it makes it a lot easier to put all of that into an API that can be accessed by the server and the client.

Here's a very small project I build (and am continuing to build) to learn about this architecture https://github.com/joshhunt/reactapus

-----


For a non-signed in session I can see some advantage in improving the swiftness of implementing supporting changes on the server for the client developers. For signed in sessions, you can't get around the database and an API update for it when the client needs some new feature or access so in the signed in case; I think the benefits of this nodejs part would be diminished.

-----


I'm not sure if I quite understand your comment.

You can still use authentication with an API... You don't need direct access to the database to do that.

-----


Aha yes, I like the look of your project ... nice work! I've got something fairly similar going on.

https://github.com/madebycomrades/autokitty-react

-----


Oh that's awesome. I'm still trying to learn and understand the Flux/Redux pattern, my project is essentially rewritten from this https://github.com/erikras/react-redux-universal-hot-example

Your project looks like it will be a very helpful resource for learning. Thanks for the link.

-----


Why spend energy producing and transporting heavy water and plastic bottles with this pre-mixed Soylent? Everyone already has plentiful water and receptacles at home. Seems like a retrograde step, unless I'm missing something?

-----


From what I've read (I think in the most recent Ars Technica article on it, not counting today's 2.0 one), soylent has to sit for a while in the fridge after you make it or it's absolutely awful.

-----


True. I'm on my first batch of 1.5 right now. The instructions are pretty clear about it needing to be cold. Room-temperature, the Soylent mix is pretty gnarly (think chalk), but once properly chilled it pretty much tastes like nothing.

-----


People will pay a premium for convenience.

Also the convenience could allow them to sell these as individual drinks in grocery stores and convenience stores.

-----


Soylent has a better texture after hydrating for some time.

-----


It also goes bad in 3-4 days, even refrigerated.

-----


That probably won't happen to the bottles, since they can make them sterile. When you mix it yourself you let microbes from the air get in.

-----


What an awful title to the first insight "women are winning". Its that sort of clickbaity, reductionist and divisive language that's turning gender relations in tech into such a warzone. Where's the data for all-women teams vs. all-men teams? Only then could you draw such a conclusion, if you even wanted to in the first place. Total garbage, and damaging to gender relations to boot. A more constructive (and appropriate, given the data) conclusion would be "we work better as a mixed team".

-----


I agree that it's essential and nourishing to understand the basics, but I feel that familiarity with the basics and expertise with these tools represents a minimum baseline standard for professional frontend development, especially when working in teams on medium/large web apps. Granted it's not easy to get up to speed with all of it, but many fields in programming and CS are not easy either. As browsers become increasingly standardised and stable and web languages grow up (ES6+) we'll be able to do increasingly sophisticated things, and frontend web development will attract more serious programmers ... we're seeing that now with the interest in React and functional JS, there's a lot of cross pollination between JS and the Clojure/Haskell communities which until now have remained in their ivory towers. Modern/professional frontend development won't and indeed shouldn't be something you can still just get done with Notepad and a few <script> tags.

-----


Well, one thing about JavaScript is that it's a very flexible language in itself without any additions. It's similar to something like Scheme. And good Schemers can accomplish a lot of cool stuff with the proverbial Notepad. I'd rather hire someone with no clue about Gulp or npm but who understands all of JavaScript and knows how to do stuff in the simplest possible way, than someone who's mastered all of these tools and can't do anything without a framework. Forgive my bluntness. I disagree with the premise that sophistication requires complexity. I prefer to see it the other way around. Maybe I'm growing older. When I see a complex build tool replaced with three lines of bash, that makes me happy. And when I notice someone has given a bit of thought to making a simple solution based on fundamental needs instead of installing all kinds of stuff, like the commenter who mentioned downloading 200 MB of code just to initialize a project...

-----


> When I see a complex build tool replaced with three lines of bash, that makes me happy

Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascript may well run into complexity problems too as it re-implements features for which simple, well-tested and widely-used open source modules are available. Our desire for simplicity will lead us variously towards either of these extremes, and our experience tells us how to tread. We want our projects to be "simple", but that doesn't mean they're going to be "easy". The barrier to entry for frontend development is increasing in terms of developer capability, but that doesn't mean complexity is increasing, or that well architected projects that use modern tooling aren't simple.

-----


Yeah, I think it's a continuous tension in software development, and for various reasons I have a hunch that it's useful to kind of try to nudge the JavaScript world towards the appreciation of basic, stupid, non-fancy simplicity. Actually that's true for way more than JavaScript. I felt the same thing very strongly the last time I installed desktop Ubuntu... I can sometimes get slightly obnoxious in my nudging, because "moving parts" complexity irritates me on a visceral level. Which can lead to NIH syndrome... By the way, Nick Bostrom uses the term "infrastructure profusion" to describe a particular nightmare scenario of AI, and I think it's evocative, so I've started to think of human intelligence as prone to this profusion, too. A perfect example would be something like if you had problems with your multiple JavaScript build tools and so you started a new build tool project to coordinate all your other build tools... Call it something cool, like "Leviathan"!

-----


I think we'll see the emergence of some of these next-gen tools once ES6+ has started to bed in. ES6 modules are much more receptive to static analysis than ES5 code.

-----


Maybe... but maybe it will be like that: https://xkcd.com/927/

-----


Hmm. There is truth to some of this, but like everything moderation is key. Use your experience to pick new tech that meaningfully improves UX, DX, maintainability or some other metric without creating problems. It does exist. Likewise, don't be the boringest of boring developers because you'll miss out on key innovations and your product will suffer. Unless, that is, you want to make a name for yourself as Supreme Leader of BFEDs for career advancement purposes, in which case host a clickbaity blog about it and argue from a highly polarized position ... oh, wait

-----


Slack, Spotify, Atom, React Native ... I think desktop/native apps implemented using web tech have come on leaps and bounds recently. They started off clunky, but are now starting to feel like native software imo.

-----


Most of the time the object you'll be awaiting will be a promise.

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: