akamaozu

For as long as I can remember, I've strongly felt you don't need a JS framework; you're better off learning JavaScript and gaining a better understanding of the language.

This is, like the author says, factually true, but a conversation I recently had gave me a different perspective on the matter.

The real problem a framework solves is communication.

You can build your own state machine, router, dom abstraction and whatever else we use these days, but we would require huge ramp-up time to get productive in every new codebase.

What are your thoughts on event-driven architecture when you don't need to cross network boundaries.

An example is inter-process communication.

Front-end is not as hard as people want it to appear.

Unfortunately the shiniest of tools in this space don't teach you the things you need to know to appreciate how straightforward it is.

#1. Perception: CSS is hard. Here are five JS tools, two bundlers and a build tool you can't write css without.

Reality: Don't cascade styles unless you absolutely need to.

#2. Perception: You don't know JavaScript if you're not writing ES6 / ES2015.

Reality: Browsers don't know ES6 / ES2015.

#3. Perception: Client-side rendering first. Use brand-name framework.

Reality: Server-side rendering first. Enhance with JavaScript.

---

Backend is not as easy as people want it to appear.

The backend is way more complicated in reality, but the tooling makes everything so straightforward you may not appreciate just how hard the problems you need to solve are.

#1. Perception: Deployment === Git push.

Reality: Perception plus Continuous Integration and automated backups that work.

#2. Perception: Infrastructure === PaaS.

Reality: Perception plus distributed computing, because there's only so much vertical scaling you can do before horizontal is a better choice on your pocket. Then you'll need an orchestrating layer to manage all those boxes / instances.

---

All is not what it appears to be.

When in doubt, use the simplest version of what is available to you.

Unfortunately the simplest of backend options won't take you as far as the simplest of front-end options.

Serendipity

I'm curious why it was limited to first 35,000 words instead of using all available material and weighing the result by number of tracks / albums or number of years the source material spans.

The issue often isn't a financial institution to go through; it's the logistics challenge in using an electronic cash system in the first place.

Case in point:

Some fervent Christians don't have a problem with gay marriage.

Nobody meets God's standard; feels pointless to wage war on anyone else who doesn't when we don't either.

A whole country a cancer to humanity?

I suspect this sort of generalization is what caused the student visa problem in the first place.

Link to the post about the graphics library please?

Maybe not so much whiny ranting as it's really just stuck in seeing the world from a particular perspective.

Otherwise, fully agree with you.

This is a promising subject, but the writer's very specific focus on Jewish-Arabic relations and connections made VC funding (and to a lesser extent even Cyanogen the product and the company) an after-thought.

- WordPress

- Node.js

- MySQL

- Redis

- RabbitMQ

- React.js

- npm

- Browserify

Two really important pieces in my toolkit I made (and probably am the only person using them) are:

- cjs-noticeboard

A javascript pubsub implementation I use client and server-side.

https://github.com/Akamaozu/cjs-noticeboard

- cjs-task

Take a task and easily chop it up into smaller distinct steps.

https://github.com/Akamaozu/cjs-task

Been pretty bad at properly explaining why I use these tools i made myself. I'll put in more effort into doing that soon.

What are your thoughts on having different node processes dedicated to specific tasks?

Eg. One hosts the http server and a second as a worker?

That way you don't jampack one loop with everything your application needs to do.

Thank you for writing this.

I think the biggest contributor to JS fatigue is almost every tutorial pointing its readers to tool up in a number of ways just to get started.

It becomes very difficult for anyone new to the language to imagine being useful or taken seriously if they can't use these tools.

Good detailed piece, but I think it could have used more details about Enchant's decisions rather than just summarizing what options are out there.

For instance, you mention two async communication strategies (message broker and webhooks), but not which you picked and why.

In the case of complex workflows, you picked decentralized interactions, but you don't walk us through an example of how it works for you, what challenges you face and why it's a better fit than the problems using a centralized orchestrator.

Amazing idea!

How do you plan to make money with it though?

Really like the simple breakdown of the concept and a relatable example.

Would gladly read more of these.

> What if the only difference between the web and desktop apps are that the desktop app can open local files while the web app downloads them?

This was the exact problem I needed to solve that led to my first Electron app.

Needed to recursively crawl a directory and generate a report on all pdfs found and the total pages in each pdf.

It seemed silly to learn a new language and ui kit when I could glue together some wen technology over a weekend and make it happen.

http://designbymobi.us/how-i-built-my-first-desktop-app-in-3...

Sounds like you're really unhappy about the lack of type safety, but using the opportunity to vent about other irrelevant chips on your shoulder.

npm install works millions of times (If not tens of millions of times) daily. If there was a 30% failure rate, it Weeknd be way more apparent.

Obligatory left-pad mention too. Forgive me for not taking the bait. Which brings us back to type safety.

I agree type safety eliminates a certain class of errors, but here's two things to keep in mind:

1. Are type errors the most prevalent type of errors that "bring disaster"?

2. Is it possible to build great systems without type safety?

See: http://learnyousomeerlang.com/types-or-lack-thereof

This.

Previous devs were doing expensive things whenever we received webhooks. This meant we DoS'd ourselves every time a sizable amount of webhooks came our way.

Set up a tiny server on Heroku that received the webhooks and put them on a queue. A worker with a configurable concurrency level later forwards the events on the queue .

Dropped from four digit 502s and 504s weekly to virtually none.

This is awesome!

Really pretty visualization - so interesting to see the distribution of where my lines of code are.

Copying generator.js into every project got tiresome, so I modified it to work from the same directory as lib.

Why do people never use regular words when describing functional programming concepts?

This was initially promising but, like every other "let me explain functional programming" write-ups, reduced to inscrutable babble before we make any headway.

Case in point: author starts talking about monadic composition before explaining what a monad is!

What would be helpful is avoiding functional programming terms, explaining concepts in everyday English (or non-FP terms) then labeling those concepts after the fact.

Maybe instead of functional composition, call it an array of functions that pass their return value to the next function in the array. Or a promise.

Would be interested to know what to do when you work in a feature factory and want to turn the place around

Being able to easily install packages from your offline cache is a really great feature because work doesn't always happen where / when you have a reliable internet connection.

I think Yarn is more fragmentation we don't need in the JS community, but this post actually makes a very strong case for using it.

I might move the skills section before education or experience.

It would help whoever is looking at it quickly determine if you have any experience with the technology they currently use (or will be interested in using).

Diablo II is the greatest.

Not sure why you need function keys to play it though.

When one doesn't know what they don't know, where do they intuitively begin learning when given the firehose of data that is the internet?

Out of curiosity, what's stopping me from using this to sign up for services and having this app mahically keeping their emails out of my inbox, but neatly filed away for when I need it?

I'd like a readability-scraped version of the articles in my rss feed.

Thanks so much for this!

I don't write erlang but I'm really interested in the underlying principles for building really resilient systems.

This is a great way to see the individual pieces and their purposes, making it easy to learn from the erlang community without actually being in it.

I don't understand the desire to make it seem like you know everything.

If you learn something from someone, is it that much trouble to give them credit for expanding your horizon?

If this mindset is recursive down your organization's hierarchy, doesn't it create a scenario where a legitimate critique never gets heard because people don't question the decision of a higher ranked employee because there is the impression that they know more than you?

Seems like you and your employer are worse off, but your ego remains intact.