akamaozu

Unlikely (s)he's interested in disclosing, judging by the throwaway name.

I'm in Toronto looking for agency work as well. It's been a while since I've done some.

Really curious about the tangible gains of using ES6 over ES5.

Especially since ES6 is being converted to ES5 at the end of the day.

Works well, actually.

It's called appcache. Works in most browsers. You should look it up ;)

How best would you go about objectively convincing the executive team that it's better in the long run to invest a bit in stability now?

Very new to talking with execs and I don't know where to begin.

You're pretty opinionated for someone who doesn't seem to understand a lot of things ;)

1. Hitting refresh doesn't break everything. It resets your current state to the default. I default to the url combined with locally stored state, so you will lose text in an input field, but not much else.

2. I want a website not an app, thank you very much. I'm really just displaying text. I don't need to download an app for that when I have a perfectly good browser on every device I'd like to read from.

3. Maybe it's over complicated to you, but the same function that renders on the server is what I use to render on the client. Zero difference. It's not a choice I have to make so I can use either when I feel it's appropriate.

That's like saying if you aren't driving a Veyron you obviously don't care about speed so use a moped.

A list of steps to follow acts way more like the event model than procedural code.

The state of the world can change between steps and the next set of instructions don't apply til you meet some certain criteria or .. event, if you will.

> drive in your car on this street, turn left on Prune street, turn right on Elm street, the store will be after the second light.

Turn left on Prune street doesn't mean nothing else happened between you driving your car and reaching that street.

You could have stopped on the way to pick groceries, changed a tire, bought a snack ... you get the idea.

It doesn't mean you must drive straight to Prune or could get to the destination if you only drove straight there.

Getting to Prune street is an async call. When you reach it, regardless of how, a callback is fired and a new async task is given to you.

No idea but it's been driving me nuts. I can't read offline bedbugs their Android app is broken.

How are you currently using Readability?

I'm currently working on an unofficial interface for Readability because they aren't working on it anymore and their Android app is really broken.

The webpage needs to work offline (whole point of the project) but should be able to work without js if need be.

I create templates server-side and serve them to the client,

If js is available, it takes over and renders any further client-side interactions.

Does this sound like poor design or a valid reason to be able to render on the server and client?

I think a good example of a function you'd want in the front and back end is one that takes data and outputs a template.

Multiple ways.

Using just your database, you can store records when users complete certain actions.

Eg. When a contract is uploaded, modified, when new people are invited to collaborate over it ...

That way you simply query for user actions over a period.

I use Google Analytics to do the same thing via events. Fire events when actions take place, review the data in your dashboard.

I've wondered why the official committee doesn't have a recommended list of libraries for specific purposes.

That way I can get a curated list of great functions I can trust.

Essentially a standard library for all intents and purposes.

Interesting idea!

Never seen anything like this before.

You're a classy guy, Leo.

You're the kind of programmer I aspire to be like and be surrounded with.

Unfriendly towards new programmers? I don't see it.

This is one of the more open and accepting fields of work I can think of.

We have regular meetups where an absolute newbie can meet a very public figure in the community and have a conversation.

We have tutorials all over the internet for anyone. Guides, helpful libraries, etc.

Regardless of age, gender, religion or financial status, programmers welcome you to the community with open arms.

The problem is programmers happen to care a lot about what they do, and that manifests itself in taking a very passionate stance on what seems like trivialities to a passerby.

Take for instance spaces versus tabs for indentation. Pretty inconsequential, right? Visually it looks the same so what's the big deal?

A more experienced programmer can tell you exactly why spaces are better from personal experience. Usually coupled with much emotion too.

It just looks unfriendly / grumpy when she's arguing the merits of spaces over tabs, but I can promise you that it's not her intent to discourage people from programming.

The end goal is always more (and better) programmers. We just have a silly way of unconsciously sabotaging that effort.

> at its most basic, it's a tool that inextricably ties DOM state with JavaScript

Thank you for this!

It seems like many people get the impression that React is a really fancy template engine, which sucks.

Part of what its capable of is rendering templates, but only as a byproduct of the task you described.

There's a bunch of directories where you keep the PHP and JS files in the same directory, like this one: https://github.com/EGreg/Platform/tree/master/platform/plugi...

Any special rationale behind that approach?

I'm certain generators can be packaged up as modules.

I believe there's a functional programming package that includes lambdas.

I've seen spread used by co-workers.

Point is .. even if not 100% of these are functionality you can package and distribute, a good number of them are.

You're new to JavaScript, but you're not new to programming.

That makes all the difference in the world.

Would you recommend Haskell, Erlang or arguably Go to a newbie programmer?

JavaScript has the benefit of being one of the most accessible languages these days, thanks to it being available in browsers.

Some people's first glimpse of production code will be from view source.

The myriad of "things a real language needs" is confusing and module systems neatly package up these crucial bits of technology.

Module systems are accessible to experts. Why not put enhancements there, rather than bake them into the language with no way to retract them?

It's not about refusing to use new language features.

It's that these aren't new features; they're old features with new syntax.

That's why Babel can transpile it. It's a case of old feature new syntax.

Exactly my sentiments.

The module system is definitely needed.

For better or worse, npm's already become the defacto JavaScript package manager. It works automatically with every environment outside the browser and we're fine using whatever module system that is compatible with it in the browser. (I use Browserify)

These tricks aren't really new. We had them in ES5. The syntax may be easier to parse for experts .. people with multiple languages under their belts ... but these changes aren't really newbie friendly.

Is the new syntax worth it?

Thanks :)

We've been pretty unstructured so far.

We let the conversation guide the direction of the show, try different approaches, lengths, settings and type of guests, looking for the ways that stick so we can double down and refine them.

We definitely need to invest in better equipment and tighten the gaps in the show. Very accurate advice.

Thanks for listening and many more thanks for the feedback :)

You could use keys for each article to prevent react from rendering the whole list on update; it'd identify exactly which need updating, inserting or removal and do the minimal work to get there :)

Make sure whatever tools / kits being promoted work on the most off-the-shelf hardware. I mean Windows PCs. Everyone is so focused on Macs and Linux that they forget how exclusionary it is for the average person to jump into the hacker life.

My feelings on this matter, in a recent tweet: http://twitter.com/akamaozu/status/535987222135447552

First thing I thought when I read the description of the name. Ironic much?

Very nice and inspiring demo.

I wrote a music player from scratch with Sound Manager 2 and I realized ... this stuff isn't that hard. We can build real software in the browser.

Someone bought Winamp for a couple hundred million about 15 years ago. Today, you can throw it together in the browser and do distribution for practically free.

Long live Client-Side Javascript!