daliwali

>Also is there any protection against pathological requests? (e.g. if there are loops in the object graph, can I build an arbitrarily deep GraphQL query that will take an arbitrarily long time to complete?)

I've seen some GraphQL servers in the wild that will respond to any query, so it's entirely possible to make abusive queries to bring a server down.

Some attempt to estimate the query complexity, and deny requests based on how long the server thinks it might take. Others, such as Facebook themselves, whitelist which queries are allowed (I have no affiliation with Facebook, this is just what I've heard).

That's what a vocabulary is for. schema.org[0] has something semantically equivalent to a user, a person.

[0] http://schema.org/Person

That common framework should be the web platform itself, not the various scripts on top. Hyper-specialization leads to risk of extinction.

>because they like it

Imagine going to a doctor and getting a prescription because "they like it".

>there is a wealth of knowledge on the internet about how to fix every little problem

Let's hope they're using the same version you're using.

>because it allows them to be productive with their peers

Productivity without a framework must be impossible...

>they learn something new

They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.

It's expedient for many reasons to use a major framework, but it doesn't mean there are no drawbacks.

There are learning curves, inner platform effect (have to do the framework way of doing things), major breaking changes and outdated information, opinionated authors you may not agree with, huge dependencies for users to download, performance bottlenecks and gotchas arising from not using the framework properly or even the framework itself is slow. These things are basically guaranteed.

Sorry, I should have qualified it as Single Page Applications, not web apps in general. Still, hard to find a front-end job that isn't about SPA anyways.

No one is stopping you from implementing a URL like: `/feed?include=users`, which is easier on the eyes than the GraphQL equivalent. But clients generally aren't aware of the `include` query or what it does unless it's advertised from the server. There's URI templates (RFC 6570) which let you advertise it as `/feed{?include}`, but few clients understand URI templates. With GraphQL, it's part of the spec, but you must know that the server follows the spec anyways.

Formal specs[0][1][2][3] have existed for years, not necessarily from the W3C.

All of them suffer from a chicken or egg problem. Without servers following specs, there won't be clients. Without spec-based clients, servers will continue to serve ad hoc formats.

Actually it is kind of a miracle that the web was standardized around HTML and not thousands of competing markup formats. We have JSON as a defacto standard for a machine format, but it lacks semantics, which is where JSON-LD comes into play.

I have not actually seen an API using JSON-LD in the wild, but it looks promising and is a W3C recommendation. The spec says nothing about building APIs and it looks kind of ugly with all of its @ prefixes, which is where Micro API[2] comes into play.

[0] http://stateless.co/hal_specification.html

[1] http://www.hydra-cg.com/

[2] http://micro-api.org/

[3] I did not include JSON API, since it does not make hypermedia a requirement.

Alan Kay was right, programming is pop culture.

It's increasingly harder to find non-legacy single page apps that aren't using React or Angular (Vue and Ember are distantly trailing behind). Corollary: it's increasingly harder to find jobs for anything other than React or Angular.

After technology du jour becomes popular, people will use it not because it's good or even necessary, but because it will ensure their employment. And then the rationalizations sink in afterwards.

For what it's worth, I boosted my SAT score by 400 points (2100 out of 2400) just by being more aware of the tricks used on those tests. My weakest subject was writing, but not because I am a bad writer, my handwriting is garbage.

It's just like taking IQ tests over again, once you know what to expect, you can game the system a bit by memorizing patterns. Scores on any standardized testing should be taken with a grain of salt.

>JWT might be the one case in all of practical computing where you might be better off rolling your own crypto token standard than adopting the existing standard.

This isn't the first time I heard this claim, but I've also read that vulnerabilities were related to libraries and implementations, not the standard itself. Is it true?

To me, I don't see the benefit of passing meaningful information via JWT, and it might even pose a risk.

>simple bearer tokens

I guess you mean cryptographically secure random byte strings?

I think that the main issue is the client must send what is essentially the plaintext password on every request, meaning the client also must store the password. It might be short-lived, might not, but is a security risk to keep the password around on the client side for the duration of the session.

No, the entire API really is one function. The events and animation helpers can be implemented by the user in a few lines of code, they are not at all required. There is nothing stopping you from adding event listeners or CSS classes without these conveniences. Putting rather trivial functionality in the same level as the only core function would be highly misleading. I would rather completely remove the helper functions, than to satisfy pedants who complain, "but there's two completely optional functions so it's not just one!!1"

Talking about overcoming "impostor syndrome" is a great way to humble-brag, because it makes the assumption that the person is already competent enough to feel inadequate. If you ask software developers to assess themselves, most will think they are above average. This leads to an echo chamber where only "competent" people reply, and the way that the question is phrased suggests this as well.

This is by the way, a thinly veiled insult. Citing Dunning-Kruger effect is just a way to call someone an idiot who thinks they are competent.

Nobody looks at objective benchmarks. My own DOM utility is faster than React.js, and in fact it is not such a difficult feat, there are a few DOM utilities which are faster, also authored by relative nobodies.

I don't worry about catering to IE8 users, neither do most websites, and that number is vanishingly small. I'm also not interested in competing on complexity, which is what happens when one preemptively builds for edge cases.

I will probably never work on a web app that has a wider reach than Facebook. Setting up arbitrary personal goals for success like working on "one of the busiest social sites in the world" and even achieving that won't make me any happier. How much is enough? I've already proven that I beat Facebook at the DOM performance game, and still I'm the Dunning-Kruger idiot.

Sorry, but avoiding templating syntax was really a hard design goal. It may not be a tool for everyone.

The reason is that every templating language I've used either is or becomes a Turing-complete language by itself.

This has been revised. There is now a separate entry point for helpers, to make it obvious to people who don't read docs, that it is separate functionality:

    var helpers = require('simulacra/helpers')
    var bindEvents = helpers.bindEvents
    var animate = helpers.animate

There is no practical difference. It is just for those who read code but lack reading comprehension skills.

>Astronaut-architects

Facebook can come out with a project that's over 40k lines of code, and it is "extremely simple". But no, it is me with my little 5kb function who is the "astronaut-architect".

>It's 2017

I don't care what year it is, you act like the current frameworks are the only viable options in the future. Hint: they aren't.

Why would I take comments from disembodied strangers on the Internet on a personal level, or "develop personally" from people replying only to copy and paste verbatim from marketing, doesn't make sense.

All I did was write the only critical comment in this thread. Everyone else who replied to the OP contributed, "great job, thanks A+".

Developers are generally not rational people who critically analyze the pros and cons of the technologies that they use. Honestly neither am I, I don't make decisions based solely on objective measures or benchmarks for that matter.

That is why it's called "most loved" and not "best tool to use", it's based on emotions. And this hardly has any relevance unless you're invested in the developer tools market.

There is actually only one function, that is the one returned from `require('simulacra')`, the others are merely conveniences that are common enough, and `retainElement` is a symbol, not a function.

To demarcate this separation better I have considered moving the optional convenience functions into a separate module, which might help clear things up.

Edit: actually it seems that you were being dishonest when quoting me, this is what it says, you cut it off short:

>Its entire API surface area is a single function (with some optional helpers and symbols)

That makes it pretty clear that the core functionality is a single function.

I'm not sure I understand what you mean by additional mapping.

Here's all that's needed in the template:

    <div class="city"><span class="name"></span> has <span class="population"></span> residents</div>

And the mapping would be:

   [ 'city': [ '.city', { name: '.name', population: '.population' } ] ]

If you don't want to manually define a mapping, you could do it automatically by assuming that some attribute like `data-bind` corresponds to a binding, but Simulacra.js doesn't make assumptions like that.

Minimalist, modern web browsers exist. A good example of this is surf [0], which is based on WebKit and is <50kb of C. That's less than half the size of React source. It obviously doesn't have all the features that Firefox or Chrome might have, but demonstrates that browsers don't have to be bloated.

[0] http://surf.suckless.org/

Simulacra.js is a single function (!), not much of a library, and very far from being a framework.

That describes the DBMon benchmark [0] pretty accurately. It has a hundred "components" (rows), each with several subcomponents that re-render based on state changes.

Actually it is less interesting and indicative of mainly one aspect of web app performance, that is re-rendering. The JS Framework Benchmark gives one a more holistic overview that includes bulk insertion, deletion, swapping, events, startup time, etc.

On this benchmark, Simulacra.js outperforms React by a wider margin.

[0] https://mathieuancelin.github.io/js-repaint-perfs/

You missed the first sentence:

>A paragraph of well thought out text will be ignored.

I don't feel that it is necessary to have to explain in depth why having such a complex architecture for doing a simple task such as manipulating web pages is a bad thing. It would be like having to explain a joke. Moreover, such a critique would hardly be specific to React, but rather all of the current mainstream front-end web frameworks.

I'm well aware that there must be an element and a selector for that element. But this is exactly how CSS works as well, it's separation of concerns. Only recently have inline styles become trendy, much to my dismay.

The total absence of templating syntax is a deliberate decision. It enables one to start from an HTML mock-up or static page, and build interactivity on top of that without changing any HTML.

>I'll bet that React will be a whole bunch faster than whatever DOM reconciliation library you build up from scraps of vanilla JS

You don't have to bet, you can verify the results yourself. Look here at these benchmarks [0] and compare, Simulacra.js is 22-42% faster than React v15 (depending on whether you also use Redux or MobX). My "scraps of vanilla JS" performs faster! Vanilla without frameworks/libraries is and always will be king of the performance game, though.

[0] http://www.stefankrause.net/js-frameworks-benchmark6/webdriv...

If shaming isn't the purpose of downvoting, or the soft suppression of controversial opinions, then I don't know what is.

A paragraph of well thought out text will be ignored. A critical remark on the web framework du jour will be carefully deconstructed, rebutted, and shamed. Funny how that works.