sapeien

jQuery has had the reputation of being very antiquated for a while. The problem that it set out to solve no longer exists. The same will be true of what you mentioned above.

Now there are tools that solve problems that arise from other tools, it is getting very meta. An ecosystem like this cannot last indefinitely.

The current front-end web stack today is not the answer, I think that is not so controversial except to the most die-hard fanboys. Most of the contents in this handbook are going to be worthless in a year.

Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.

Agree with this. I think that many of the people named here may be more talented at marketing their ideas and themselves within certain developer communities. Their work may seem popular and exciting, but are lost in abstract thought and have little to no connection to the real world. Rarely will you hear about the programmers who write software for the things people rely on every day, these are the unsung heroes.

Looks pretty impressive at first glance, but it seems that most of its features come from dependencies such as PouchDB, RxJS, JSON Schema, crypto-js, and more. The built version is 1.3 MB, minified file is 520 KB, or 140 KB gzipped.

I found the "key compression" feature to be an amusing micro-optimization. It truncates names of keys, making DB migrations tricky. There are better ways to save more bytes, namely by using an actual compression algorithm.

I didn't say that Facebook's reference implementation is the only one (it is in fact the most popular based on downloads), everyone else is performing free labor for Facebook. The point is that they can make any change they want to the spec for themselves and imposing their will, bypassing standards processes because there are none.

>fetching all of the data for a screen in a mobile app in a single round trip without coupling your backend to your UI - and second, the focus on tooling and developer experience

There is no reason why one can't do this with existing web technologies as an additional feature. There was no reason to ignore what already exists and works for the web at large.

I think you should disclose that you are founder of Meteor and have a vested interest in GraphQL. So when is the Facebook acquisition?

I don't buy into the GraphQL hype. Actually it is a rehash of older technologies like RDF & SparQL, but marketed to a newer generation who didn't know that old things exist. I'd wager that the 20-something "engineers" who designed it didn't give a shit about prior art either.

I'm sure that Facebook employees think it solves a lot of problems for them. But I'm not convinced that a single vendor technology is going to be viable on the web. Web standards come about through standardization processes, with multiple stakeholders reviewing and revising drafts. Facebook one day puts up the GraphQL spec out of nowhere and defines the "standard" by themselves, based on their own implementation.

A little history: Facebook tried to subvert HTML with FBML, a proprietary markup language designed for use within the Facebook ecosystem. Long story short, it didn't work out. The various SDKs and APIs by Facebook have been notoriously unstable.

People tend to excel at short-term thinking, kudos to Facebook for that, and lack the foresight for long-term thinking, except for a few visionaries. The architecture of the web has lasted a few decades already, it will outlast a single vendor specification.

I think the nuances of the offering are not entirely clear from the marketing website, so here's what I've interpreted.

The product itself seems to be a Node.js framework that glues together various modules, including popular ones such as Express, Mongoose, & Socket.io. How they monetize it is via consulting and hosting, which they offer a fixed price for "unlimited" bandwidth and storage (very unclear how they may throttle this). The pricing is also exceptionally poor, a fast HTTP implementation may respond to 250k requests per second vs a month, and 5 GB of storage for $50 a month...

They seem to not have any sort of release strategy and the readme states to clone their repository. It would require pulling from their repo to update it as a dependency. There are also absolutely no tests, so you don't know if the latest commit is working or contains some work in progress or not. The signup process seems to be needlessly difficult, one needs to manually craft an HTTP request to some endpoint with some payload.

The "AI to build exceptional apps" pitch is vague. I can think of some possible cases such as automatic indexing based on querying patterns, but this is just speculative. I wouldn't trust it unless I know what it does.

Actually the site loads about 4.3 MB of compressed data over the network, or 6.5 MB uncompressed.

Edit: out of curiosity, I looked at the package.json of their open source project, there are 51 top-level dependencies. After installing, there's 140 MB of dependencies, or about 800k lines of JS.

Quality is fractal.

I haven't heard of Fabric before. Fabric seems to have an ambiguous name and their marketing website is equally ambiguous. Something to do with mobile app analytics? I find this trend in developer tool marketing to be appalling.

1) Doesn't always work if you want to target embedded systems or need performance, and all you know are scripting languages with huge overhead like Ruby, JS, Python, etc. Some languages really are better than others.

2) Could say avoid distributed computing if your problem is not distributed. This is more about being a blind follower of the latest hype.

3 & 4) Complicated DevOps are a bad idea in general. Stuff that seems to simplify things on the surface like Docker are actually hiding tons of complexity underneath.

5) To most people, Agile = JIRA = Sprints = Scrum. It's corporate mentality codified, so it's no surprise that a lot of startups avoid it.

What's wrong with good old notepad.exe and *.txt files? Notepad (nano, ed, other lightweight editors) has a quality that this doesn't: unstructured text. When writing I don't want to think about metadata, I just want to write, not think about titles, tags, etc. One could probably infer a title based on the first line. I think forcing structured data input is the wrong approach and it is better to use NLP or other methods of inference.

On a technical level, this seems to be a desktop web app which is overkill for a simple text editor. Compare its performance to notepad.exe which ran fine on machines from decades ago.

It depends on what you already know, I think embedded development with systems level languages and hardware know-how is a very durable skill.

On the other hand, some fields like web development have peaked a while ago, I would argue that 2012 was the high watermark. I think it's a very precarious choice of career right now. It has been steadily going downhill since the introduction of trendy front-end frameworks that don't offer any value to the end user (including React, Angular, et al). The culture stopped being about making usable and accessible interfaces for people, and more about "component architecture", "server-side rendering", "tree shaking", that solve problems created by the very tools they are using.

That isn't to say that web development is dead, but I think that the future will be more specialized around certain features of the platform such as WebAssembly, WebRTC, WebGL, Web Audio, et al. And these will be more readily picked up by people with more durable skills, than those who only know the most popular front-end framework.

Fun fact: Jeff Bezos from Amazon was an early investor in Mashape :)