Instead, do what you want with personal checkpoints, but refactor them into logical steps before publishing and merging (with a real merge) them.

You’ll rarely review single commits anyway. However, I’d rather have a single “giga-commit” instead of dozens of commits that are not correctly divided plus dozens of “remarks from code review” commits because what’s rebase.

Many of my colleagues view using Git not as part of their core work but an inconvenient chore.

This is just because Github and its imitators are bad software - which isn't really git's fault. git and Linux practice only commit-level review.

> Many of my colleagues view using Git not as part of their core work but an inconvenient chore.

Many people don't care about version history, and ignorance of how git works (or adherence to superstitious rulesets) on the part of the people who do care provides them cover for trashing the history.

Many people don't care about code quality or maintainability. However, these people are more likely to be prevented from trashing the codebase itself than the ones who don't care about history are from trashing the history.

Commit history is just as subject to review as the contents of diffs.

I don’t think that’s an accurate way to put it. AFAIK you just send in patch files. They create a single commit, yes, but I see it as equivalent to a PR. The rules of what can be in a single patch could be stricter than typical PRs on other projects, dunno.

> Commit history is just as subject to review as the contents of diffs.

I wish. Maybe I’ll work on a better team on the future.

you definitely don't send your branch as a single patch (unless it is small and really is best expressed as a single patch). if you did you would be asked to break it up.

you are correct to realize that e.g. "my working directory as of this timestamp when i got up from my computer" is not useful information, and should not be published. however, a diff that does too many things at once is also not useful information - you are forcing the reader to separate it themselves, possibly wrongly, every time they read the diff. very few branches in actual practical work are organically one commit long in their most useful expression.

finally, the merge to upstream is useful information, as the only source of a high-level view of the progression towards a release, and if you (i'm only guessing because of the use of the "clean history" shibboleth) avoid actual merges (with merge commits) to upstream, you're destroying important information about the integration work of the project, making the history significantly messier (from the perspective of someone reading it, which is the only perspective that matters).

(at the advanced level of writing-history-for-usefulness, you also realize that random-place-on-master branch starting points are not useful information, and learn where to start them from, but this is low-impact in comparison to not destroying branches. still, learning things like "base a bugfix on the commit that introduced the bug" are real force multipliers.)

Are we looking at the same web technologies here or are you from an alternative universe?

Despite all the mess, I have an easier time getting buttons on a screen and doing things sanely (once all the fuss is set up) compared to trying to get the ball rolling in Qt/GTK/etc (especially if you're not using Java or C++)

HTML is simply a terrible GUI base, JS is quite great nowadays and CSS would be great, but has to provide way too much of what HTML should be doing. But the web ui frameworks are just barely getting at the level of where native frameworks have been in a decade.

If by structure you mean things like hbox/vbox then no, html is not supposed to do that. HTML should only represent the semantic structure.

There are a couple of exceptions for interfaces that are genuinely unconventional, or that deal with multiple spacial dimensions, or that are primarily representing graphs and visual/audio data. But most interfaces should be representable in pure text.

This argument that "the web is only for documents" is missing the point that most applications are just interactive documents when you really break down their UI. A labeled tree is a fine way to represent user-facing state for most apps, and most apps would benefit from exposing a more semantic interface to users that was easier for them to manipulate and read programmatically.

Swing, Qt, et al do not have great answers to this problem, and definitely not superior ones than css.

but I agree in general with your statement.

Like I wouldn't want to have to deal with an interfrace like facebook in native stuff. I don't think it's impossible, but I feel like it would require a lot more up-front design and correct engineering.

You're right about XML being a medium, just kinda my memories of working with this stuff.

Yeah, its true — though you can leave an area empty where you will dynamically load one from a set of already drag’n’drop created layouts.

CSS:

    .vbox, .hbox { display: flex }
    .vbox { flex-direction: column }
    .vbox > *, .hbox > * { flex-grow: 1 }

    <div class="hbox">
      <div class="vbox">
        <button>Top left</button>
        <button>Bottom left</button>
      </div>
      <div class="vbox">
        <button>Top right</button>
        <button>Bottom right</button>
      </div>
    </div>

If I had to pick a stack to do a new web app entirely in canvas, I'd probably choose to port a ton of interface components from AS3 into PixiJS... but the point is, where have we gotten? Ten years from now we'll be writing apps the way they were written in 2010 -- inside a black box in a canvas or VM. The HTML5/JS revolution has been a sham from the start, just a way for one corporation to dismantle another with the side benefit of forcing all of us to rewrite our code from scratch in a crappier language.

Anyway, that's not very important.

What web apps never had is a visual app builder as popular as the first Visual Basic for Windows 3. We had some tools like that (example Jwt [2]) but none of them got a critical mass of users. Maybe it's difficult to match Visual Basic's success because Microsoft controlled the tool, the operating system and the language. If this is the case the only current candidate is Google, because of Chrome. They are investing on Flutter and Dart now but making them prosper on the web looks like a uphill battle. Much easier on Android.

[1] https://en.wikipedia.org/wiki/JavaFX

[2] https://en.wikipedia.org/wiki/JWt_(Java_web_toolkit)

ah, yes, the famous difficulty of getting buttons on a screen in Qt https://streamable.com/bs5fxk

By the way - Qt and GTK are super-outdated ways to do GUI in C++. Popular, but outdated.

... could you precise that more ? I'm literally just making "new project" > design view > search for the button component > drag'n'drop it ? How can it get more simple ?

(opening a text file and writing "Button {}" is definitely more complicated if we're talking about teaching to beginners)

if teaching beginners to programming sure, if teaching a programmer beginning QT development no.

as someone who teaches programming in university, that's definitely not true, less than 1 in 20 students has the reflex of looking for any kind of documentation (even after showing it to them)

As an aside, do "modern" developers still write GUI applications at all, since everything is on the web anyway these days?

I even write terminal user interfaces sometimes to interact with servers that don't have a desktop environment installed.

You want to be utilizing the features C++11, C++14 and maybe even newer versions of the standard allow you to use, to avoid unnecessary boilerplate, repetition, and arcane-ness of syntax and semantics.

Similarly, the GUI toolkit should not be based on C-like or C++98-like design patterns, when newer versions of the standard allow replacing them with more convenient patterns.

Here's one example, from the Nana C++ GUI toolkit:

  #include <nana/gui.hpp>
  #include <nana/gui/widgets/label.hpp>
  #include <nana/gui/widgets/button.hpp>

  int main() {
      nana::form form;

      nana::label label{form, "Hello, <bold blue size=16>Nana C++ Library</>"};
      label.format(true);

      nana::button button{form, "Quit"};
      button.events().click( [&form]{ form.close(); } );

      form.div("vert <><<><weight=80% text><>><><weight=24<><button><>><>");
      form["text"] << label;
      form["button"] << button;
      form.collocate();
 
      form.show();
 
      //Start to event loop process, it blocks until the form is closed.
      nana::exec();
  }

    #include <QtWidgets>

    int main(int argc, char **argv) {
      QApplication app{argc, argv};
      QWidget widg;
      QVBoxLayout form{&widg};

      QLabel label{
          R"(Hello, <span style="font-weight: 600; font-size: 16pt; color: blue;">Qt C++ Library</span>)"};

      QPushButton button{"Quit"};
      button.connect(&button, &QPushButton::clicked, [&widg] { widg.close(); });

      form.addStretch(0.1);
      form.addWidget(&label);
      form.addStretch(0.7);
      form.addWidget(&button);
      form.addStretch(0.2);

      widg.show();

      app.exec();
    }

    g++ example.cpp -I/usr/include/qt/ -I/usr/include/qt/QtWidgets -fPIC -lQt5Widgets -lQt5Core

tl;ds: now that I saw it in action, I know I can instantly ignore anyone who says that nana is a suitable replacement for Qt.

The films you watch on TV or at the cinema were not created (edited, VFX) using a web browser for a start, and the User Interfaces to those applications are pretty Graphical by anyone's definition...

Not disagreeing with what you said, but "not having anything to do with the web" isn't as clear cut as it used to be and web technologies are increasingly showing up in unexpected places.

to add on this, the reference UI toolkit for building VFX tools is Qt. Maya, DaVinci, Lightworks, Nuke... are all Qt-based.

https://vfxplatform.com/

But then the Qt UI:

* needs to be (re)compiled for each platform

* needs to be re-shipped on each change

* is not a client-server application (all runs on the client)

* has "desktop styling" by default

I think of it like democracy. It is ugly and terrible, but still better than all the other options.

Edit: The React repo is 3 million+ lines of code, written in its own niche language...

I have a theory that the people who go on about how the web ecosystem is too complicated are either 1) web developers who are nostalgic for the jQuery days (and have selective memories about those days), or 2) non-GUI developers who enjoy the theoretical virtues of a QT or a GTK but have never actually had to work on a complex GUI, and so can't appreciate the incredible benefits the web has over those other platforms.

https://github.com/facebook/react/graphs/contributors

It doesn't seem possible for this to add up to 3M lines of code?

I got pretty tired of chasing the fad explosion. Here's what I build everything with these days:

HTML, CSS, JavaScript, Go or PHP, Redis, MySQL or Postgres, Ubuntu & Nginx. Occasionally I'll make use of an ancient version of Sphinx for easy, fast search. I also sometimes mess with Vue for fun, as I happen to be fond of it, but I never find that I need it.

No frameworks. No containers. It's all mostly boring and ancient. I use DigitalOcean for about 95% of everything hosting wise (and rarely AWS). Works beautifully, everything is simple, blazing fast, light on bloat and rock solid.

The simplicity is still out there, if you don't have to care about what anybody else thinks, if you're not trying to earn a living doing web development (everything I work on is self-determined). That's a big if unfortunately. If you are trying to earn a living doing web development it's understood that chasing the latest thing isn't optional, as you can't afford to miss an inflection.

I’ve spent 14 years working for a small agency building these sorts of systems. I kept up with all the cool new stuff that’s come out and played with it but all we ever needed was 2 load balanced app servers with a single instance Postgres database and we ran some pretty chunky systems.

I’m now looking for a new position and this attitude has come up to bite me. I’ve always been dismissive of the new dangled complexity but turns out there are systems out there that churn through so much data that mongodb makes sense, and large teams of devs where splitting systems into separate services and writing reusable components is required which is where frameworks and inter process communication tools come in.

Most things exist because there is a need for them.

Currently working on a couple of trading systems (for physical objects, not financial). That's in the ecommerce sphere technically, although they're not monetary transaction based. The first one will hopefully launch in June. I might Show HN it.

Both work perfectly with the setup I described. I build in my wheelhouse though. I can build services like Stack Exchange, Quora, Wikipedia or Reddit (or most things in standard ecommerce, ecommerce platforms). I know what my stack is good at, and what it's not appropriate for. And at this point in my life I know well what I'm good at and what I enjoy, so I look for opportunities there.

I don't want to dismiss this without any arguments but please do the basic research before you choose the db for your next project.

https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/

The "promised efficiency" of any system is a complex question. The dynamic schema approach of MongoDB makes it trivial to update schema design on the fly so I am confused by "no real easy way to correct once deployed".

BTW : The recommended production setup is three nodes (one primary, two secondaries). This is what you get by default in MongoDB Atlas (you can't go smaller).

(I work for MongoDB)

If I want to gain a relative 100% increase in concurrent read/write access and transparent session failover to my application I have to procure two servers(with roughly the same performance lets put it at rawPerf=1.0 for simplicity) and a SAN/NAS with SCSI HBA and that would be it. All the necessary components will be running on those two servers and the application will have access to almost all capabilities of a single instance with a roughly twice the performance and fault tolerance. To do that in Mongo, I would have to procure 2 replica sets with 3 instances each(bare minimum to get the fault tolerance and not use arbiters which according to Mongo University is a bad idea) for the actual data and another RS for the configuration meta-data, which is another 3 instances. I will also need instances where I can run my "mongos" to route/consolidate my requests and to have fault tolerance I will need at least two of those. Now to do a break down of the different instances. From the two replica sets for data, I can use only 2 of the instances for writes and the remaining four only for consistent reads and that is only with the appropriate write concern. And while I have two instances for writes I am not guaranteed to get a consistent increase in write operations unless the data is at least somewhat evenly distributed. I will need six rawPerf 0.5 servers(assuming 0.5 rawPerf is capable to handle roughly half the data), that is a total of 3.0 so far. The configuration RS while not as demanding as the actual data RS will still require resources so I count it as roughly between 0.5-1.0 total for all three instances. And finally I have the "mongos" instances which although will not need disk space will need some CPU and the same amount of RAM as a regular instance in case the queries and not optimized, so I will have to give it 0.5 per instance. And the total amount of resources comes to 3.0+0.5+1.0=4.5. On the other hand with the Oracle RAC I would've needed 2.0.

As for the schema flexibility, from the Mongo documentation I take it that once the shard key is created it can't be changed arbitrarily. It can only be further fine-grained by adding more keys to it, however this is available from version 4.4. In order to change it cardinally, I would have to recreate the collection.

I'm sure you are well aware of all this, however I'm just stating my experience with MongoDB so far.

I am not familiar with Oracle RAC architecture but casual mention of a SAN fails to recognise the cost and complexity of even the smallest SAN. On the other hand MongoDB can run on dumb disks without a SAN or RAID required (though RAID can help with performance).

With you two node system loss of a node results in a 50% loss in performance whereas with MongoDB loss of a node will result in a secondary taking over the primary role with no loss in performance. You get what you pay for.

Setting up such clusters used to be a PITA until the advent of MongoDB Atlas. Now you can set them up with a few mouse clicks.

As regards shard keys. Yes, they are immutable, but the documents they index are not. So dynamic schema properties are preserved in a sharded cluster.

Postgre clusters can be configured in similar fashion.

I'm not saying that Mongo doesn't have it's strengths. However using the full potential of your environment requires much more planing and has a lot more pitfalls.

I was particularly discussing the implications on what the relative immutability of the shard key has on the data distribution and that it is not that easy to change.

Devops is in a similar state! There is growing consensus that "Container orchestration" is something like the right problem to solve, and people seem to like Kubernetes, but tools like Puppet, Ansible, Salt are still in heavy usage, and are still very useful, but they solve a different problem. Even within k8s there is debate about the proper container runtime (Docker has fallen out of favor for containerd). But all of this assumes total mastery of linux, ssh, bash, systemd, vim, sudo, mount, ps, and all the distribution variations.

Java is in a similar state! Widely considered "boring technology", Java (lang) 8 introduced streams and lamdas, which is a very different way to code (and hence, to think), and emphasizes functional style over object-oriented programming. Then you get to pick which Java you want (Oracle, RedHat, ?), and how you want it installed (installer, brew, unzip, docker), and now your build tool (Maven, gradle, play, ?) Then if you're making a "typical" webapp you have to choose your VCS (git, mercurial, svn, cvs), code hosting provider (github, gitlab), your starting point - Spring, Spring Boot, Dropwizard - which assumes you want REST, when in fact you may want to try GraphQL, which may lead you to nodejs, and it's complexity.

Picking system dependencies is similarly complicated. Components we can choose from - message queues (rabbitmq, kafka, activemq, ?), caches, proxies (nginx, httpd), and here we have to balance many considerations, such as "is there a widely trusted image I can configure and use as is?", and your options, and the details used to deploy them, will depend on every other decision you've made. In fact, all of these choices are made in away that affects some or all of the others, in a way that is complex and difficult to articulate. This is certainly why certain combinations get acronyms (LAMP, Jamstack, etc[0]), and why its very hard to have an intuitive picture.

[0] https://en.wikipedia.org/wiki/Solution_stack

Make that web devs, if at all. In many other places where software is written, it's closer to the opposite: Managers tend to be minimalists, and the more "adventurous" developers lobby for adopting newer libraries, or use a new language for some side-project.

Listing a stack of dependencies as a starting requirement is arguably not simple.

Simple to you personally because you’re proficient in each of these. But how long did it take for you to become proficient?

The relative simplicity is in that the stack is quite set and restricted, with no unnecessary pieces. I don't add to it just because the industry finds a new flavor of the week or something loses/gains popularity. Each part of the stack has a job to do and I don't add to it constantly or constantly turn over what's in it. That stack could remain entirely unchanged for five or more years easily. Where it can be avoided I don't use unnecessary incrementals that add dependencies or complexity (which will often resurface in the loss of reliability/predictability). I often don't use the latest versions of anything unless there's a very good reason to switch sooner than later. I might stick with Ubuntu 16.04 or 18.04 for the next decade if it were a safe thing to do from a security perspective. In that approach, I can place as much of my energy and focus on what I'm building as possible (since everything I build is mine, that's where my priority and interest is).

Web development was always a means to an end for me. It enables me to build things that I want to see exist. I don't love web development unto itself (I'm rather neutral on it), I love what it enables me to do. I grew up in the middle of nowhere Appalachia. An atheist, social liberal in a typical conservative region that was intellectually unfulfilling, uninspiring, non-ambitious, slow (it was also peaceful, green, and with very little crime). The Internet (and Web) showed up there around 1993-1994 and it was like something from another planet, my teenaged brain could see immediately what could be done with the open canvas and from then forward all I wanted to do was build on it. You're telling me there's this always expanding virtual space, seemingly infinite, and I can just build, and build, and build anything that I can think of? And it connects me up to millions (later billions) of other people? And it's not even very expensive to mess with? Holy shit, let's go.

So what I primarily care about is the thing being constructed, and I want my stack to be very reliable, fast and without many frills or unnecessary complexities. I don't want it to get in the way. I don't want to have to fight with it every time I begin a new project, I want to immediately get to building, with the stack being the 'ol reliable companion that just does its job.

If there's something far better nearby (that is reliable + low on complexity) with minimal learning curve, I'll consider it; I switched to PHP 7 very rapidly for example because the speed increase was such a considerable gain and it required very little time/effort to switch. I started utilizing Go because it was easy to learn, simple and fast (I worked with Java in the 1990s, and never wanted to go through that again); Redis is much the same story, I use it for all sorts of things (from caching to various throttling tasks) and it was pretty ridiculously easy to start using vs the enormous value I derive from it. I'd be happy to keep using my current version of Redis for the rest of this decade. I've been using Photoshop 7 since 2002 because it just works and handles ~95% of everything I need in that space (and they can't do anything to force me to upgrade).

It's also worth noting that I handle every aspect of building and operating a service in the beginning. So this adds emphasis on not shaking the stack unnecessarily, the time costs can become large fast.

I've experimented with just about every approach. Lately I've dumped all forms of social auth (the past couple of years). I won't allow FB or Twitter login, none of them deserve to be trusted with that.

I'm a big fan of try (the service) before you have to sign up, but I always find that among the most challenging aspects to get right.

I know everyone has a different opinion on auth, but I find it routine to do after all this time. The part I find most annoying is probably throttling / controlling abuse attempts vs legitimate users (balancing it well), it's tedious.

I seriously doubt you're going to do a better job at security than the AaaS systems out there. I couldn't, and no-one I know could. It's a ludicrously complex and subtle field.

If there ever was a red flag in what you're saying, this is it.

Auth isn't "scary". But it is hard. You need to know what you're doing in order to implement it from scratch. If you think it wasn't hard, odds are you did it wrong.

No, it does not.

CSS allows some mitigation of this problem.

Is this a React thing?

Waiting for the extra request(s) adds lag time, makes back/forward navigation clunky, interrupts what I was doing if I already began interacting with the page (eg. infamous relayout / unwanted scroll) and sometimes breaks snapshotting tools like archive.is.

I don't mind pages with javascripted controls, but their initial content should be included in the payload with the initial page load. Don't the frameworks have tools to help you do that?

That UI/UX is getting slower as everything is getting faster is a sad reality of the times. But I guess that's the price of faster iterations, easier developer flows and a building on top of the lates greatest framework.

The problem with that is that it pretty much requires you be running node on the back end too. If your back end is built with say PHP or Ruby, you’d need to call out to a node process, which is potentially a lot of additional complexity, time, and expertise.

An alternative is to just serve the HTML from your ruby/php and then take over in the frontend, but this is more complex and not worth it in my opinion.

This is still incredibly common for apps that are mostly server rendered but use React/Vue etc "sprinkled" through the codebase for more complex bits of UI.

Otherwise you'd be trying to implement everything once in JS and once in PHP/Ruby

I agree with your overall point 100%, but to be honest nothing in React was / is innovative except for the virtual DOM diffing, but even that is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture. React made a huge impact on web dev and deservingly so, but all of the other ideas have been implemented and used on the web before.

Of course it's great that React is bringing some of these good ideas to mainstream, but they've been there way before they have been distributed along with a VDOM algo.

Maybe there wasn't much academically innovative in React, but it certainly brought declarative, functional UI programming to the masses. Its innovation was in making that as easy and accessible as possible with a tiny API.

I feel saying React wasn't innovative is so dismissive and ignores the massive paradigm shift that's happened in web development because of it.

But I'm not even talking about academic really. There were plenty of people who didn't buy into the "MVC/jQuery/templates" thing, and we were writing apps into production for actual customers. I've never been taught academically, but I realized that writing my DOM operations as declaratively as possible made my code much easier to maintain. So I started creating and updating my DOM in JS way before React, when it was considered "heresy" by people who didn't know better. And there were plenty of programmers like me, who never got academically trained or looking up category theory. They had just shot themselves in the foot with the silly MVC stuff too many times to care anymore about what other programmers think.

For me, and people like me React was a GODSEND. We started immediately hyping it, but there was huge resistance early on to adopt it. React was a great improvement from the status quo. But then later on we realized that people started using it as a framework just like they had with "templates+jquery+backbone+whatever" and although the DOM things are a bit easier now, many people don't understand any better why or how React is good and when it's bad to use...

Its innovative in the same way as the iPhone was. All of the concepts existed before, but nobody made them practical and cheap

A concept that also has existed before, but with XState, I think a lot of developers will latch onto this paradigm.

The ability to think or plan a feature/apps states in the beginning rather than imperitavely or as an afterthought during development is really valuable. And perhaps if we're dealing with something more visual at the beginning, its easier to demonstrate what will happen if I click "X". and then it becomes easier to spec out & to involve PMs/designers and QA.

Kinda like hyping iPhones innovation without ever mentioning touch screens.

Your comment was very insightful, but I feel like you've left me on a cliffhanger. I'm someone who got into the industry right when React was reaching enterprise levels, so I missed out on what came before it. I got my job, was told to learn React, and have gone from there.

Is there any way you might be able to expand on the problems you were solving with your declarative approach, why it was useful, and how you think React should be used in modern day web development?

- application is in one state and the UI is in another state

- jQuery operations mutating the DOM causing weird edge cases after several user interactions

- the template language (handlebars, mustache etc.) was getting in the way because it lacked the expressivity of javascript

- application state was split all over the place between Models, Views and Controllers. instead, if you put as much state as possible in a single place in your application, it's much easier to just create declarative functions that take in an immutable state and output a DOM node object: `(state object) => DOMNode`

Right now I'd use React only for projects that require it as legacy or as a part of a framework. If you want to get things done quick, Next.js is pretty good framework for greenfield projects that uses React under the hood and I don't mind it being there too much. But similar things to React can be achieved with Svelte or Lit without having to ship and manage a VDOM implementation or JSX with its quirks (e.g. className).

So in summary, I'd stay away from all features of React other than VDOM, and even skip that if possible. And as a general rule, don't use any frameworks unless you can say why your project specifically really needs it. Surprisingly much can be done with basic HTML, JS and CSS. People who say "just use X" are trying to force simple answers to a field that is inherently complex and needs good judgment on which tools to use and when not to use them.

jQuery is a good tool for simple one page applications but not designed for complex web apps. It is harder to code cleanly in it as compared to React.

Because it seems to me that around the time React really gained popularity there were lots of options that did largely the same thing. Knockout, Ember etc.

Personally I only see it as the real proof that VDom could work for large applications.

After all, like you suggest, things like functional programming and monads have existed for quite some time. The thing that makes React special is how rabidly people adopted it, and continue to adopt their major updates.

Taking the example of hooks, React has hooks because it was released with a bunch other stuff in addition to the VDOM, people started using those things as a (poor) framework, shot themselves in the foot repeatedly and finally hooks had to be introduced as a fix on top of that.

Calling that band-aid "revolutionary" or cutting edge technology, kind of sounds wrong. They never would have been there and wouldn't have been needed if it weren't for the bloated original release.

But of course, even if that band-aid makes people think differently about building apps, it's all good. That's why I mentioned in the post that it's a great thing. But calling it "revolutionary" when a large fraction of programmers have been doing it that way for ages is a bit of a stretch.

Is this true? I've worked in web dev for like 6 yrs now and React has provided a significant number of concepts and technologies I'd never seen before and still dont see elsewhere.

For example, JSX. Yes, it originated in php but React was its first time being implemented in the frontend.

Also the concept of hooks and functional components. The fact that you explicitly define side-effects in the render of a function, with memoization or execution dependent on arbitrary state, is a new invention as far as I'm concerned.

One of the early criticisms of React was: “You can’t do HTML in Javascript. You shouldn’t be styling in JS! That violates the separation of concerns.” React skyrocketed productivity and allowed scaling without spaghetti. That’s why it won.

CSSZenGarden was fun, but how many companies seriously did redesigns by just swapping a style sheet? Only repeat the dogma if it makes sense....

I think React won because it had a more gradual learning curve than Angular and a didn’t drastically change between versions.

And the idea that HTML/CSS/JS are non-isolated is over-thinking it. It only applies to the world of Webapps. HTML can be published and served all day without CSS or JavaScript. And you can do a lot with HTML and CSS alone.

JSX is not magical which is what I appreciate the most about it.

The ability to type `children` alone makes a world of difference.

Transpiling, hooks and components have all been done (and done better) before React came along, but often they were laughed out as esoteric toys that have nothing to with "real programming". It's just hard to teach these concepts until you actually use them, and it's hard to get people to use these concepts unless they are included in something else that you need.

The same happened early with React, both JSX and VDOM were laughed at by many developers because "they looked stupid" to people who didn't understand them and were used to one way of doing things. MVC+jQuery+templates was the flavour of the day.

Same thing with TypeScript, FRP and so on.

Most likely, whatever concept is gaining momentum today, it's an exact or approximate copy, or in rare cases a novel remix of what has been researched 10-20 years ago, and used in production for 5 years before you heard about it on HN

These people who like to apply category theory etc. in programming have heard this mocking of their work as stupid esoteric fantasy (and then seeing them become mainstream later) so often that they literally called one of their specs "Fantasy Land" https://github.com/fantasyland/fantasy-land

There's still lot of work to be done. JavaScript doesn't even have proper immutable data structures natively, which would be a REAL low hanging fruit.

The compiler is quite mature and used by countless apps in production right now.

https://svelte.dev/

I've been using it myself and it doesn't feel academic at all. The Svelte Kit toolkit, a successor to the Sapper frameworks is also ready to use but it's not 1.0 yet so might be a bit unstable. But if you're worried about having to figure things out then you can use Sapper+Svelte or just Svelte just fine, and they're very robust and well documented.

On another note, a React component in FP is just any regular old JS function with a signature: `(state) => HTML string`. React is such a simple concept that it wouldn't have needed any sort of library, if it weren't for the performance and DOM reset issues.

They may predate React, but React made them easy.

Good luck explaining how lenses work.

Rx? it took the author of RxJava months to understand the concept. And he had the author of Rx.net there to explain stuff to him. [1]

> there's no single "React but better and made earlier".

Yes. And that is precisely the point

[1] https://twitter.com/dmitriid/status/811561007504093184

> React made a huge impact on web dev and deservingly so

The VDOM was revolutionary, no question about it. The comment I was replying to didn't even mention it.

--- start quote ---

All of these concepts are variations of what has been done before in a number of ways. Mostly by "FP academics" who "live in fantasy land", until everyone else starts using them too.

Transpiling, hooks and components have all been done (and done better) before React came along

--- end quote ---

When asked about the emphasized part, you mentioned Svelte for some reason. When called out on that, you went and listed a bunch of things, ... none of which are really better, and are quite esoteric. To the point that it took the authors of some implementations months to understand the concepts.

React (pre-hooks) could be picked up in less than a day, and just worked. Re-creating React concepts from scratch was a three-page tutorial.

Of course this would cause problems that I've described in this thread before (scroll/form state resets, performance problems etc.), so the VDOM was the missing piece of the puzzle. Overall the concept of declarative UI was incredibly simple and predated React, but the VDOM was a great thing that solved the problems people were having with declarative DOM manipulation. If React had shipped just with the VDOM implementation, it wouldn't have needed to expand into a full-fledged framework and introduce a bunch of band-aids on top it. React deservedly skyrocketed, and the VDOM was an incredible thing to introduce at the time, but every part of React is quickly becoming outdated as more FP concepts from the past are introduced into the mainstream.

So all in all, React shaked things up in a good way, and finally people are ready to move on to make their apps actually reactive and taking a serious look on things that have been "academic" before.

I don't

> I don't know what bone you have to pick with any technology other than React

I don't have a bone to pick.

> but achieving declarative DOM manipulation pre-React was as simple as

Yes, it was possibly achievable. Did anyone achieve it? You claimed that evertyhing React has was done better before React. When asked about examples, you answered first with Svelte (which appeared after React), and then with disparate technologies which are are at best esoteric and at worst extremely complex.

> That was definitely easier than learning React, and by building a component structure with vanilla javascript functions, you could have all the functionality and expressiveness of JSX without a compile step or external libraries.

You probably could, but did you? Oh, wait, you didn't. The hot tech du jour when React was released were knockout.js and backbone.js.

And, once again, the etirety of "learning React" took less than a day. And "building a component structure using vanilla javascript functions" was literally a three-page tutorial if you wanted it.

Compare this to Rx that you gave as an example of something "better than React". The author of the original Rx.Net sat by the author of RxJava, and it still took the author of RxJava several months to understand the concept. Lens, another of your examples, is esoteric even in Haskell.

But sure, "everything was done better before React came along" :-\

> React shaked things up in a good way

Indeed, it did.

Funnily enough, you start with "Transpiling, hooks and components have all been done (and done better) before React came along" and then continue with "there's no single 'React but better and made earlier'."

I did. It's kind of funny to hear that you cannot even entertain the idea that people actually did declarative UIs before React with plain old vanilla JS, because that was my bread and butter back in the day. That's precisely how I did frontend until React came along, and so did many others. We sometimes sprinkled in some CoffeeScript to get nicer function syntax, before () => {} and babel existed, but it wasn't necessary if we wanted to avoid a compile step.

Just because some frameworks were prevalent at the time didn't mean that everyone used them. Large portion of seasoned developers rejected all frameworks and still do today. They had shot themselves in the foot with MVC/"trying to do everything" -frameworks enough times to learn that not all answers come from a single framework that encompasses your whole application. This is nothing new or esoteric, and still today a good lesson to learn for new developers. Instead many people continue to use "the standard" framework, fighting against it when it fails to fit the domain logic of their app, and waiting for a new framework to arrive to save the day. Frameworks have gotten much more flexible about this today, but React wasn't anything revolutionary on the framework side of things.

It's not as simple as "React bad/React good". A framework/library can be good in certain aspects and bad in others. I loved React when it came out, because of the VDOM. Wasn't a fan of everything else though, and especially not a fan of how it was used as "the new standard framework to tightly couple your application into". This is not a contradiction, it's just non black-and-white thinking.

What devs can implement on their own beyond frameworks, and what frameworks mean to how the community as a whole operates.

"Defaults matter."

for context, I wrote the first web frp+vdom and helped inspire the creation of rxLinq and related systems, and we even did a whacky thing back then that predicted Parse/Firebase/redux/graphql/falcor, including some basic features they still don't have (should have spun out a startup instead of getting a PhD!). our group even did the first lenses for the web, though that one ended up much less usable. I think we did all that around 2003, while the alternatives were PrototypeJS, jQuery, and a couple other more sugar-level things

however.... react with hooks, jsx, and the various css modes nowadays is pretty awesome, and eliminates most of the needs for streams. main lack there is more for rich animation, than web apps. graphql, redux, and friends are all still clearly clunky technologies with limited shelf lives, so I'd focus more there than react for basic abstractions

at the same time, nowadays I think more about synthesis, ml, end-to-end GPU computing (actually proposed that back then too!) and other more powerful ideas than revisiting frp/lenses/etc...

No, React was first. It was in production, if internally, for more than a year before Elm came onto the scene.

Both Opa and JSX were created in 2011. Opa had other innovations as well, such having the same code base run on both client and server (like Next.js). Unfortunately it didn't get traction and was abandoned by the creators.

Could you expand on this? What was it that necessitated DOM diffing before, and which architectural changes are making it irrelevant?

If you tried to solve this problem by redrawing the DOM every time your app state changed somewhere in the code, the browser would freeze and all your form elements would be defocused on every update, scroll states would be reset etc. etc.

React solved this by the diff algorithm and doing surgical updates of the dom based on the components state. It does this by manually reading the state, keeping a virtual DOM in its memory and doing diff calculations.

But if your whole app is reactive by design, there's no need to read the app state, doing diffing or figuring out which DOM node to update which one not to update. The DOM update operations flow naturally by the declarations given by the programmer. Frameworks such as Svelte are moving into this direction and they're already seeing quite significant performance improvements compared to VDOM implementations.

If you can do declarative rendering without keeping a virtual representation of the DOM and diffing it against the real DOM then "the virtual DOM is overhead" (https://svelte.dev/blog/virtual-dom-is-pure-overhead).

[1] - https://css-tricks.com/say-hello-to-css-container-queries/

I’ve had pretty decent success using this library.

This is a good resource that will walk you through the cutting edge web development technologies, starting from the very basics and progressing to the more complex matters in the end. Highly recommended.

Should I hand-type static HTML to do this? Is that what modern web developers typically do? Will learning HTML, CSS, and JS teach me how to use a backend? Which backend language should I pick? Should I use a database? Which one? Or should I use AWS? Is all I need HTML, CSS, and JS?

PHP, is that a good backend starting point? That seems to be pretty fundamental, since over half of all websites use it. A LAMP stack, right? No? What about Python? Ruby? C? Rust? Arc? Elm?

Should I use Node? If so, what is the typical Node setup?

Should I use webassembly? That's a fundamental and new browser technology.

How do I compress and minify code and images to be served? A makefile, right? That's the typical way to build things in my software world.

Web is a large domain of knowledge. It isn't particularly hard in terms of math, algorithms or mysterious unknown proprietary APIs. But there is a lot to figure out. What parts are important, what parts can I skip.

If by basics you mean HTML, CSS and JS. Sure. Good start. But you could also start with a framework and learn from the middle and out or the top down.

Not everything has to be learned bottom up.

Either way. It is not trivial.

The numbers speak for themselves. I don't need to convince you. There are more web developers than in any other programming field. So it must have some property that makes it easy to get started or at least some kind of incentive to make people go through the initial hurdle.

Anything worth studying is slightly overwhelming at first, but to say that everything continues to be overwhelming once you know the basics is wrong. Knowing a little bit of the grammar and some words will help you understand better Mandarine. Not knowing anything about the language will make it appear as some alien technology.

No skill starts growing at the middle. Nobody teaches mathematics by starting with abstract concepts. We don't learn new spoken languages by studying literature from the get-go. So getting the pedagogics right is part of the success.

https://www.st.com/en/evaluation-tools/p-nucleo-ihm001.html

For $35 you get a little motor, a motor control board, and an ARM micro-controller board. ST includes some software for motor control. If you want to do precision motor control, out of the box it is missing an encoder (a device that tells you the position of the motor). The STM32 chips usually have some inputs you can use with a quadrature encoder, so you could add one if you needed to. It does include a current sensor and the software uses the for field-oriented control (FOC), so you can efficiently and smoothly control the speed of the motor. To learn more about motor commutation and FOC, check out this document:

https://www.actronic-solutions.de/files/actronic/FTPROOT/Fie...

For an example of stuff people have built with them, here's a Robot Inventor-based Rubik's cube solver: https://www.youtube.com/watch?v=_cl2Wur8waY

Being able to just run Linux on the thing sounds like a god send.

But the most significant feat React achieved IMO is how easy to write asynchronous hiearchical actors (from actor model) with it (kind of like erlang vm).

Context enables dependency injection and ownership management. Effect and state enables object ownership and lifetime management. Js timers, (i.e. setTimeout, setInterval, queueMicrotask, promise/async), help making an object living asynchronously as if it has its own private thread.

Yes, those are similar concept of lifetime and ownership Rust have, but instead of functions/blocks the object (value in memory) is owned by/shared with components. And of course these are not enforceable by compilers/transpilers/linters due to them not being a javascript-primitive, but at least React helps organizing those things in a lot more explicit and clear manner.

In summary, it requires more than a few tutorials to get started, it is multidisciplinary, and you have to deal with the unpredictable real-world.

Webots R2021a has arrived and it brings camera image segmentation among the other features: https://cyberbotics.com/doc/blog/Webots-2021-a-release

Download it now and start building deep learning applications! https://cyberbotics.com/

The interface simplifies usage of Reinforcement Learning algorithms with Webots.

There is a Wikipedia article comparing different robotics simulators: https://en.wikipedia.org/wiki/Robotics_simulator

You may find a podcast with Olivier (CEO of Cyberbotics) interesting as well: https://www.youtube.com/watch?v=gy75VfUg9II

For everybody interested in details, the article gives useful insights on configuration automated by the script.