That's not just "AST transform system", Sweet.js provides a way to extend grammar with new productions. That allows to introduce new syntax constructs.
You're absolutely right; Babel's parser is very much hand-coded, and adding syntax requires deep knowledge of the internals. Not impossible, but not for the faint of heart. My dreams of having the safe navigation operator from Coffeescript (a?.b?.c) must yet remain unfulfilled...
The Law of Demeter doesn't always apply neatly, especially when you're introspecting JSON sent over the wire and you don't have a "class" with object oriented behavior for each sub object (at best, they're strongly typed). And the runtime overhead AND verbosity of a function may not be ideal, with the string parsing required in lodash and the awkward syntax of the curried function. Something that compiles natively in a DRY way to a && a.b ... would be used widely imo.
We're still working on some edge cases that will result in frames dropped. There will soon be a way to prioritize frame rate over duration precision and visa versa. Stay tuned!
Hmm not sure what problem this was trying to solve since client side router has been a solved one for a long time. And this is not looking close to express w/o middleware, which page.js does.
Not sure if this is needed. A Promise is basically an async representation of a transaction where "cancel" can mean a slew of things. Even w/ `fetch`, what's supposed to happen when you cancel? (connection abort? resource modification reverse?) Cancel should just be a `rejection`, because the Promise's purpose (update a remote resource) wasn't fulfilled
Think about an autocomplete search. Every additional letter should abort the prior ajax call and fire a new one. Right now I'm hammering my server because I want to use fetch().
The request is already in flight, it's too late - you can't abort those packets from getting to your server, you can only send new ones (which maybe instruct the server to disregard your search or something).
The correct way to accomplish what you want is to either throttle or debounce your searching such that you reduce the amount of requests made in the first place.
Doesn't matter that you can't cancel in flight packets:
1) because clients throttle connections. Suppose a user wants to navigate, you may need to be able to cancel in flight requests or the next page load might be significantly delayed.
2) file uploads can have potentially gigs of packets that haven't been sent yet, which you definitely need to be able to cancel.
canceling GET is the simplest use case, XMLHttpRequest/fetch is already able to abort. POST/PUT/DELETE, however, modifies remote resources which cannot be easily "canceled" (it might corrupt server state and/or transaction might even have to extend to client being able to fully "resolve" the Promise?)
> POST/PUT/DELETE, however, modifies remote resources which cannot be easily "canceled" (it might corrupt server state and/or transaction might even have to extend to client being able to fully "resolve" the Promise?)
If those can corrupt state then you're already at the complete mercy of the network... which is never a good idea regardless of whether this proposal is accepted or not.
yup, so why bloat up the spec? Introducing a 3rd option that represents a non-deterministic remote state isn't entirely helpful IMO. Having the ability to abort the connection should be enough (which is a rejection).
Hm? My point was that the spec doesn't fundamentally change anything wrt. the things you mentioned, so it should be evaluated on other merits (or lack thereof).
Doing ad-hoc hacks around the lack of cancellation seems like a pretty big practical issue to me[1], so I'd certainly like to see something like this spec in the standard.
(Note: something like, not necessarily exactly this. I haven't thought about it deeply enough to be able to properly evaluate the spec.)
[1] Happens all the time when doing simple Ajax-on-futures where you really just want to ignore any result if the operation gets canceled in the UI before the response arrives.
- Overall project structure seems a bit unorganized IMO (no centralized build process, gulpfile inside subfolder). Overall this makes it fairly hard to dive right into the project. It might be my lack of experience in PHP project structure.
- I think pulling in a server & a db might be an overkill. Local storage will do the job perfectly.
- Mix of tabs & spaces is also very messy.
- Styling is pretty sloppy too I believe. No clear organization/reusability in the stylesheets.
- Vendor scripts/generated scripts should not be committed to the repo IMO. There're already bower & CDNjs & a bunch of other services.
- Your JS is also very module/singleton-based although some of them are clearly object-oriented. Also seems to be a mix of jQuery usage & DOM directly, why not 1?
I think what they're looking for is a couple of simple JS that's easily tested, maintained & expanded which IMO is more important for senior candidates. Less senior ones can always bang this out quickly but senior ones care way more about other attributes of a project than just getting it done asap.
> - Overall project structure seems a bit unorganized IMO (no centralized build process, gulpfile inside subfolder). Overall this makes it fairly hard to dive right into the project. It might be my lack of experience in PHP project structure.
This was what I noticed the most - and I can easily see this as a big part in the discussion, since seniors should lead and bootstrap projects.
I'd have expected something like ./server and ./client and a README toplevel, client eventually having a public folder which can be served as-is (i.e. doesn't contain any build/dependency management files), potentially with a second public-minified around. Instead I end up with a src-folder hidden like 3 folders deep and another one toplevel for asymmetry.
Beyond that, the folders in the php app follow the package-by-kind antipattern. There is no value in grouping all controllers in one place. There's value in grouping all the highscore handling in one place, though.
We're looking for a full-stack engineer to work on our high visibility music products. This is not your average "jQuery monkey" position, you'll be working on cutting-edge high traffic Javascript/Python applications, where reliability and high performance are key. The person should be responsible for architectural software decisions, as well as software implementation in a team environment. The environment is dynamic with focus on creative thinking and usage of open source to solve complex problems and business needs.
Our stack:
- Python Django
- Gunicorn
- memcached
- Chef
- HTML/CSS/JS and the latest greatest stuff Web can offer.
If you're interested, shoot my your resume AND github at longho@clearchannel.com
