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.

Troll picks:

Curtis Yarvin a.k.a. Mencius Moldbug (https://en.wikipedia.org/wiki/Curtis_Yarvin)

Xah Lee (http://xahlee.org/)

Michael O'Church (https://michaelochurch.wordpress.com/)

Bryan Edds (https://medium.com/@bryanedds)

CAT-V (http://harmful.cat-v.org/software/)

Suckless (http://suckless.org/philosophy)

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.

Something very similar already exists: https://github.com/pretenderjs/pretender

I don't think it's a good idea in general to mock server responses because they are subject to change while the mocks don't, better to just run the server and make a real request.

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 :)

That makes Web 1.0 sound bad. AWS seems to be using Angular and is full of UI quirks and bugs that would have been impossible without JS. HTML forms work predictably, reliably, and with a high degree of affordance.

>something React-like as part of the web standards.

Hell no. High-level APIs should remain in user space, they are too often optimized for short term thinking, prone to breakage, and inefficient.

Most of the current DOM specification has been around since 1998-2000, and the spec hasn't made a single breaking change. Standards committees have an obligation to not break the foundations of the web, framework authors can do whatever.

And what about those McKinsey consultants, surely their work can be automated as well? :)

It is funny that the managerial class thinks that they are safe from automation.

Should qualify this as Web Developer tools. Nearly all of the things here would be irrelevant to systems programmers.

May I ask why one would want to switch from a well respected engineering profession to one which literally kids can do? Outside of the HN bubble where there's lots of VC-funded Internet startup employees, webdev is a joke, and I think you see why now.

Stupid question: what does Omniref do that can't be done with source code comments? Comments are readable by anyone in any editor and do not require external tools. They are co-located to the relevant lines of code by being part of the source, and are as portable as the code itself. My first impression is that it is a solution seeking a problem.

Why should anyone use this, instead of just using a Redis client, the `cluster` module, and a WebSocket server directly? It's only 251 lines of code as of writing, which is partly spent on trivia such as a linked list implementation, a string hashing function, and some console messages. There is a whopping total of 23 lines of test code for the linked list implementation.

Also, did you really hardcode credentials to some hosted Redis instance somewhere? https://github.com/team-emt/razorframe/blob/e35004f7f2915275... (I'd rewrite git history if I were you)

It is important to note that Zuckerberg did not claim any original contributions, nor does he name any of the non-Facebook libraries used, denying the acknowledgement of others' work which he relied upon. For all we know, he used some off-the-shelf libraries for face recognition, language processing, and speech recognition, while having little to no understanding of how they actually work. This is what a lamer does, not a hacker.

There is a huge gap in public perception of the competence of the elite in the tech industry. People will get the wrong impression that Zuckerberg is an expert on any of these topics. It reminds me of the antagonist of Ex Machina who is portrayed as CEO of a giant software company, AI expert, and robotics engineer, all in one person.

Uber is a douchebag company, who knew? On a serious note, there is no obligation for any user no matter how big to contribute anything upstream in open source. If that were the case, we would be in big debt to the maintainers of the Linux kernel, GNU, OpenSSL, and so much more.

It probably makes sense in Google's own ecosystem of apps, but as an aesthetic style it seems to be intentionally bland and tasteless.

Clickbait title for the HN crowd, I sense that articles like these are analogous to the old which color to paint the bikeshed debate.

Front-end libraries and frameworks should be trivial because front-end web development is largely trivial, it's the ecosystem around it that has bloated in complexity, including Vue.js and React.

Take a standard API that is already simple enough to understand and use (DOM), and re-package it for people who wish to call themselves "software engineers" to justify the time they spend on making simple things work in a complicated fashion. If you disagree that front-end complexity is getting way out of hand, just read the source code of any modern single-page app including its dependencies.

I think that code written by amateurs cobbling together vanilla JS is generally faster in development and performance, more easily understood, and easier to maintain than code written by a professional web developer using whatever framework. The early web itself was largely cobbled together by hobbyists, and so should it continue to be.

The industry disagrees with me, that's fine. I'm aware there are many reasons why my views are the exception not the norm. I just hope that something far better supercedes this era of web development, which would require social and cultural shifts to occur.

This looks a lot like another JS library that was posted here previously: http://monkberry.js.org/

Both compile templates to DOM manipulation code.

I think HTTP-based APIs are closer to a service than an library with a public interface, even though the term API can be used interchangeably for both: https://schema.org/Service

This looks really great for discoverability that works within the web platform already, without the need for inventing a new format [0].

However, I'm not sure if this goes far enough. There exist some formats for describing what APIs can do in natural language, though I'm not convinced that they're really that useful [1][2].

[0] http://apisjson.org [1] http://alps.io [2] http://restdesc.org

According to MDN, `@supports` is part of the CSS3 spec, defined in 2012. In 2016, it's time to start using it. Web development in a nutshell.