daliwali

I've done very little marketing, and I am effectively a nobody without a huge following or elite credentials unlike some of the people behind the most popular frameworks. It would be completely unfair to judge me based on popularity and making negative assumptions about my experience, rather than merit.

In fact I refuse to market my pet project as if it is something to be bought and sold. or to assign it a valuation based on how many big companies are using it.

You don't need to rehash the marketing pitch of React here. It's the same old "virtual DOM fast, real DOM slow" that I've heard countless times from fanboys and repeated ad infinitum in any discussion about React.

What's missing is that you can make complex web apps without any of these things, or the abstractions used can be something completely different. The reasons you stated just sound like ex-post facto rationalizations of what they did after they built it.

>The complexity of how to render some stuff into the screen is not [my problem].

But it is. You are depending on some complex third party code to do your job, how you want to punt responsibility to someone else is irrelevant. Web developers aren't owning up to the sorry state of front-end web development, because everyone says "it's not my problem", ask Facebook/Google/whatever.

Correct and proper have little meaning if at all in web development, they're usually dictated by the biggest companies and most popular bloggers. Moreover, these definitions are constantly in flux (no pun intended). Nobody cares if your web app correctly follows the proper conventions of your framework. Front-end web developers seem to focus more on navel-gazing about the "developer experience" than results.

It is a dogma that React has an "extremely simple" public interface. It's got two different flavors of "components", "lifecycle hooks", "synthetic events", "prop types", and more that I'm missing.

Why do you assume that vanilla JS code is terrible? Is it because the average developer can not be trusted to write competent code without the conventions of a framework? If one cannot write competent code without being completely dependent on frameworks, I wouldn't trust them to write code at all.

I'm not saying, "don't use an abstraction on top of vanilla DOM code".

Better performance just isn't a valid reason to use a DOM abstraction, it's a non-argument.

You literally said, "complexity is not my problem". You are the problem.

This is how projects end up with millions of lines of black box dependencies. This is why `node_modules` folders that are hundreds of megabytes exist.

Take a look at benchmarks [0] and tell me, if any framework performs faster than vanilla JS. They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks.

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

Using class names was just an example, people may get the wrong impression that has anything to do with the variable name. It could have been made more explicit, but I wanted to be as terse as possible:

    <h1 class="name" data-bind="name"></h1>

It was also a design goal not to introduce a templating syntax, so `{{}}` brackets are out of the question.

These are marketing buzzwords that can be said about every single web framework, effectively thought-terminating cliches. Every fanboy says their preferred framework is the simplest, fastest, most scalable and most testable.

In the car analogy the improved performance of modern cars have more to do with mechanical engineering than software. And the analogy falls apart when you consider that modern web frameworks are invariably slower or roughly equal in performance to its vanilla JS counterpart, but never faster.

I think the conventional dogma that one must resort to a framework for a large web app is wrong.

Your assumption that simpler is more "hacky" or less efficient, just isn't true. One can use built-in constructs like for loops in vanilla JS to update multiple DOM nodes at once, this yields the most optimal performance. Or one could use React/Redux and setup an action and a reducer and action creator and action type constant and... you see where this is going.

I think it's a UML activity diagram, which is in fact a flow chart.

Your analogy isn't apt, a better analogy would be judging a car to be difficult to maintain by looking at the listings of all the embedded software. I know a guy who restored a 1960's VW Beetle to working condition with minimal expertise, the same couldn't be done for modern cars without a full machine shop that specialized in that make.

Fancy selling points like "unidirectional data flow" don't actually mean anything. Each fanboy has their own variant of this, like "transclusions", "immutables", "dependency injection", etc. These are all phrases I've heard that don't translate to tangible results.

Why does the third party library need to be so complex? And why should there be complexity in the first place?

There was a previous discussion on how do you know when someone is addicted to over-engineering, and looking at this giant UML diagram, I think this might be the case.

The amount of complexity I'm willing to accept is proportional to the the difficulty of the problem. In this case it's manipulating web pages, which shouldn't be too hard. This isn't a knock on React in particular, but it seems all the major vendors are competing on complexity. React has "fibers", Ember has a "virtual machine", Angular has their own overblown architecture (I don't know anything about it, and don't want to).

Now that the DOM API is implemented in a standards-compliant way across most browsers, it should be the perfect time to use it. I don't like the current mess that is front-end web development, and more of the status quo isn't going to get any simpler, quite the opposite.

Shameless plug for my own DOM utility: http://simulacra.js.org

Yes, they likely have reverse proxies that cache static content. But this won't work well for any sort of dynamic content, i.e. apps that require login, when data changes in real-time, etc.

Most JS server-side rendering never approaches anywhere near string concatenation performance, and I've tried. Whatever abstraction you use has to resemble string concatenation without doing much else, and it's really, really hard to not do much else. That's why embedded JS templates (EJS) is so fast, it just concatenates strings with some logic built-in to the template.

The string building approach is the fastest, and it's the benchmark to beat. Any other abstraction is just piling more work on top and is generally just a more inefficient way to output HTML. The most lightweight pseudo-DOM implementations are still going to be significantly slower than string concatenation, and I have benchmarks to back up that claim [0].

Realistically, a server-side rendered JS app is also going to run most of the code that runs in the client per page load, so you would also have to consider initialization costs as well. I've had to work on one that took 100+ ms to render a static page (without accounting for network latency), which a static file server could render the same page orders of magnitude faster.

Long story short, most of the newer, non-string based JS server-side rendering does not consider performance a factor and consequently, perform pretty terribly. There are band-aid fixes such as putting a reverse proxy in front or running on super fast hardware, but it's like putting a band-aid on a bullet wound.

[0] https://github.com/daliwali/simulacra/blob/master/benchmark/...

>a machine that picks fruit when it's ripe

How does the machine recognize fruit? It must have some training data set to classify what is fruit and what is not, and which are ripe. Humans may be "experts" at simple stuff like this. One cannot easily generalize it to a machine that also harvests potatoes, without providing "expert" knowledge about potatoes.

The term "AI" is so overused that it can mean anything. Expert systems are considered "AI" for that matter. They may not necessarily use the most computationally expensive methods like neural networks, but "AI" doesn't prescribe any specific technique.

Expert Systems of the past had user interfaces, though crude ones such as Java applets and basic HTML forms. UI evolves too fast and new means of HCI emerged like VR/AR, IoT, etc. Most likely the human interaction will have to be made by humans, but the more fundamental advancements can and will be automated. Being a "front-end engineer" on whatever platform, be it web, mobile, embedded, seems to be a pretty stable career in the future, at least for now.

Vertical AI = Expert System, just an updated rebranding from 1980s to now. An expert system may be defined as:

>a piece of software which uses databases of expert knowledge to offer advice or make decisions.

The methods of inference have improved from predicate logic to statistics and "machine learning" now that computers have gotten much faster.

(I'm bootstrapping an expert system myself)

Ask them to make some simple yet non-trivial feature, like a contact form on a web page.

The overengineer will introduce a build system, several functional programming utilities, an HTTP client wrapper library, a DOM abstraction library, and maybe a full blown framework.

The competent developer will write a <form> element with inputs.

Thanks for the suggestion, but for a good reason, I couldn't be bothered to use some external service to do it, since it will be replaced with the actual product. Replacing that stupid mailto link is just another motivation to ship something :)

For marketing-tech, sure it's a great model, but getting out an MVP as fast as possible doesn't always make sense. Sometimes it takes an order of magnitude more effort to get to "minimum" or "viable" depending on the product. On the contrary, a lot of developer's side projects just feel like things that any reasonably skilled developer could build given a few days.

The question of finding customers, is exactly the same as finding who is demanding software to solve business problems (i.e. not current software devs).

I started doing this recently by quitting my job, and I currently have no income.

There is this assumption that one must build a minimum viable product that has to be released as quickly as possible, so much that it's become startup mantra. It's no surprise that a lot of these products seem to be technically shallow, everyone is reaching for low hanging fruit.

I feel rather alone trying to do something that I think hasn't been done before, or if it had, wasn't executed well. I don't think I could possibly commit to it without having strong motivation, which I struggled with while having a full-time job.

The biggest technical/social challenge I have is to make something that a non-technical user could easily get right away and make something with it. I think the automation of web dev is an inevitability, and frameworks were just a historical blip on this path. The same thing is happening to web design. http://hypereum.com

There's nothing in this guide that couldn't be found on 1000s of other introductory blog posts. This is just "What to Use With React 2017". I find it almost disturbing that front-end jobs around the world have adopted a set of opinionated tools that are so needlessly complex and churn at an amazing rate, and devs themselves have such a cavalier attitude about it. The self-congratulatory praise is deafening.

I used both and still prefer Browserify. No configuration required, it just does what you want. Also its source code is quite short and easy to grok.

The pedants on Hacker News understood what the OP meant, yet nitpick on his use of "programmer".

I agree that there is too much window dressing on the web, an aesthetic defined by gratuitous graphic elements and distractions. The only purpose it serves is to project an image, it is marketing.

It used to be that pretty designs are seen as more trustworthy, but there has been a backlash. The superficial optimism of modern web design is becoming less and less effective, and it's taking more effort to pull it off.

My theory is that they have little incentive to improve performance. All of your professional network is there, and it's not like there's another website with nearly as many people on it for that purpose. So you will use it no matter how crappy the performance may be, because that won't negatively affect their revenue nearly as much as an e-commerce website.

This may be a stupid question but I glanced over the marketing website and didn't really understand how logs are stored.

- Are you storing each log event as a row in Postgres?

- How do you rotate logs, what happens when logs get indefinitely large?

- Can logs be exported to some common format for offline analysis?

I have a rather unpopular opinion that JS libraries get popular for reasons unrelated to merit, such as corporate backing (React), appeal to beginners (jQuery), and adding syntax sugar that has no value to end-users (Underscore/Lodash, Babel). They are symptomatic of organizational problems related to herding programmers at scale.

To beat the average, by definition you can't just do what everyone else is doing and expect outstanding results. If your problem is unique there won't be a library for it. If you find or create a hidden gem, it's your secret weapon, you are its user and responsible for it.