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.

The problem started a decade or so ago with Node. Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.

ECMAScript is a general purpose standard, but it was invented retroactively. Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit, and has wasted too much potential for me to say anything positive about it.

I've commented this many times before, but having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it's trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.

Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.

JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy/falsey, typeof null === 'object', undefined vs. null, etc.) can be learned in an hour and written on a half page.

So you’ve come to it at a time when the syntax and capabilities have a popular subset that actually starts to fulfil the early promise. And yet, despite the article above, one may still be enormously critical of the anemic and inconsistent standard library, and don’t even get me started on the horrifying dependency shitshow of the node ecosystem that cripples maintainability of anything over 18 months old.

Just because we’re all holed up in the throne room, doesn’t mean there aren’t monsters still roaming the sewers, just a few levels down.

As for isomorphic code, I strongly encourage my competitors to write backend code in the same fashion and the same breath as the front-end, because the resulting tight coupling and special-case-driven technical debt makes them easy to outmanoeuvre when markets shift. And if they’re reading this then please also consider microservices, graphql, and nosql data stores whilst you’re at it, for the same great reasons.

The reason is that these two books don't fulfill the same goal. The Good Parts is a rather short walk through the language and reads more like a "get started quickly" guide. The other goes into much more detail. That doesn't mean the latter's size os due to it covering all the bad stuff whereas the former doesn't. It's just a clever title but it's an apples and oranges comparison and I'd suggest not using it as some sort of supporting argument.

Whether JavaScript is good or bad as a whole is a different question (I think it is), I'm simply taking issue with that meme (that originally popped up in picture form, the two books side by side, rather than text).

JavaScript is becoming bearable but still too painful for anyone who has touched ruby for example.

Meanwhile I’m learning closure and loving every second of it.

I get not wanting to start with a super complex stack, but Ruby and Rails are the worst mainstream framework maintainability wise it's obvious why it fell out of favour.

You always know exactly how to implement what you want, without having to think very hard.

You can do something small by yourself by writing less code, but using less code makes it more complex since you have to think a lot harder to understand the code when you come back to it in a few years

Because one's a style guide and one's a complete API reference?

> Don't use continue. I've never seen a loop with a continue that wouldn't be better without it.

And that's it. No examples, no objective criteria, we're just supposed to take the man at his word on this. Whether or not I agree with this particular case, I don't enjoy argument from authority in most forms, especially not in one where you are supposed to learn about a better style of programming.

Front and back do different things, have different requirements. You control the architecture on the back end for instance, not on the front. The back end deals with data modeling and processing, the front with layout, very different task, very different skills, and the language is just a small part of it.

There is some overlap, for exemple I remember having to code a clock twice, once on the back end of to show it correctly the first time, and once on the front to have it refreshed in real time, the code could have been shared, but these occurrences where code can just be copy-pasted are not that common.

And BTW, most of my web dev was JS/PHP/SQL, and I actually liked all three languages for what they did. JS, I had no choice, but it did event handling well. PHP was good at generating HTML from a database and SQL, despite its age is still king for querying databases. I wouldn't want to use these languages for anything else.

I disagree, but with nuance. I consider myself a skilled programmer, and I have switched languages many times throughout my career, and you are correct, it is not much of a big deal. There have also been times in my career where I've been responsible for whole swaths of an app from back to front end where the backend was in Java and the front was in HTML/CSS/"old school" JS (this was back in the JSP/server-side days). And yes, in that case it was not hard to switch back and forth.

The problem, though, is that, as you point out very well, the back and front ends have very different requirements, and so in most organizations you have separate teams focused on the front end and back end. If I'm a front end dev, I'm going to be spending day-in day-out working in Javascript and my JS ecosystem. It's not that it's hard for me to, for example, learn and use Python, the issue is that since I'm not "practicing" it every day it definitely gets rusty, and as time moves on the ecosystem moves on such that my environment likely needs some tweaking (venv vs. pipenv vs. virtualenv vs. conda - honestly it's been a while so I have no idea what is in widest use these days).

So if I'm on the front end, and I need say one extra piece of data that I know is stored in the DB exposed in some specific API call, for what is likely a trivial change for a backend dev, well now the time it takes for me to get my backend env in sync (again, which maybe I haven't bothered with in 3 months), refresh my knowledge of Python, work through any dependency update issues etc. I may have can often be longer than the time it takes to make the simple code change. So what usually happens is the front end dev just doesn't bother, they submit a ticket for the backend dev to do it and wait to sync until the next sprint.

Compare this with what happens when front and back end are both in TS - the front end dev usually has a short chat with the backend dev to make sure the changes will be OK, but since everything is immediately familiar can go and make the change just as quickly as the backend dev, without needing to wait for the backend dev to have time to do it.

I have seen this cultural change in depth over the past couple years, and it is just a pretty shocking change if you've ever experienced it if you've been used to teams that were more "siloed" between front and back ends.

There's tools to make it easier, but using them still means you have to pull in another stack into your workings/you're stuck with whatever limitations the tool has

Not exactly.

It is easy in web space, but switching language is a big deal if the previous and next language have huge differences in concepts and on which layer of the stack lives.

For example, switching from language that has a complete runtime and GC to a language that does not, is a bit hard. In JS we have things like Promise.all, and setTimeout, and such to control concurrent async operations. On language like c/c++/rust where you produce abstract machine, you have to choose how to operate and regulate those async operations.

In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is probably not the way to go unless you want to pay for all the extra instances you'd need for the same amount of load. In my experience, for example, a java-based graphQL server (that spawned multiple connections to various services) needed much much less in the way of resources than the node equivalent serving the same amount of traffic - AND the latencies were generally much better with the java server, depending on the size of the JSON payloads that it was handling.

All that being said, you can certainly architect your way out of that problem and I imagine a relatively small percentages of web applications even HAVE that problem.

But again, I definitely agree with what you've written, right tool for the job.

The JS scripts together the compute heavy CV alogrithms, and you can do similar by hosting your computer heavy things behind a service call, while keeping the orchestration parts in node

> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit

And what makes V8 a "browser JS engine"? A focus on:

- rapid startup. Code starts running immediately, JITs quickly. The VM is designed for latency, not just for throughput.

- excellent sandboxing. The VM is designed to run untrusted code.

- no blocking code. Designed for callbacks and promises. No threading, no thread.sleep(), no mutex, etc. Makes is much easier for non-expert developers to write fast & reasonably correct code.

Now look at things like Cloudflare Edge workers, Lambda etc. Modern server environments share all of those same design goals.

Server-side JS/TS not only has the advantage of a single codebase. It also brings the design and engineering advantages of a browser VM to the server.

Rapid startup: lambda is a tiny subset, and not really server application. A server app could take minutes and would still be okay, because they are designed to run for a long time. Even in case of scaling minutes are more than okay since deploying a new instance takes a similar amount of time.

excellent sandboxing: you usually only run your own code connected to db and other very privileged services. If there is a vulnerability it is a very big problem with or without sandbox

no blocking code: i’m not up to date, but node doesn’t have a strong parallelism story at all, compared to the JVM, Go, .NET

Wby would you want to maintain a long-running server process if you don't have to? And, wny do you think you have to?

Most of the "serverless" things delegate to a server in the end anyway - whether they be a database, a managed service, etc. Something has to stay alive, be a server and own the state after all - serverless doesn't make the problem go away just passes the buck. For run of the mill small scale websites or websites that fit a particular paradigm lambda works fine. But it doesn't suit all apps, and its hard to make all problems fit it currently. As businesses scale custom solutions can scale better.

That's an irrelevant tautology; the question was why you believe a long-running traditional server process is necessary.

Lambda is great for seldom run functions, like running some analysis/conversion on user uploaded profile pictures or the like.

Also, specifically for Aurora, Lambda supports transparent connection pooling. It is just no longer a concern of your application code.

Disclaimer: I work on serverless services at AWS. I’m definitely biased :)

Though I suppose Lambdas don’t use separate traditional OS processes to serve requests, do they?

I don't really see how. TS doesn't seem to solve any annoying problems I previously had in Java. As a concrete example, it would be nice to have the concept of a DTO as a first-class language feature, but alas, I find myself constantly casting and re-casting, plucking, or writing endless wrappers to make sure properties trickle down (or up). Hell, sometimes I just give up and use `any`. I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.

TypeScript's generics system is cute, but I think it's mostly academic. And did you look at the toolchain? To get TS working, you need babel or ts-node or webpack, and like 3 different .json config files. Importing a package without TS support? You need to write some stubs yourself in types.d.ts. In fact, the best parts of TypeScript are actually JS (await/async, arrow notation, spread operator, etc.).

> I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.

I have no idea what you're talking about here. I use GraphQL with auto typegen of my TS types and I get typed data objects everywhere.

> TypeScript's generics system is cute, but I think it's mostly academic.

TBH this remark just makes me thing you really don't know much about TS. I use generics extensively, find them very helpful and are easy to use.

I'll give you the point on initial TS setup being non-trivial. Hopefully advances in tooling (things like Deno, which I'm not actually a huge fan of, or other projects like Rome) will make this easier, but even then I found this to be a "one and done" cost.

I'd look into what Jersey actually is before you say something like this, because what you've said really doesn't make sense.

> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Afaik esbuild only intends to be a replacement for 2 out of 5 of those things. It does that well for sure, but if parent commenter's main issue is the amount of different tools, I don't think esbuild will help.

But there is also sucrase which is fast because.. its written in TypeScript? https://github.com/alangpierce/sucrase

It would be better if there were no oddities in a language. One of the reasons why everyone hates PHP is that it is full of inconsistencies, odd design choices, weird naming and unexpected behaviour. JS has at least some of these.

If there was a second of third language available in the browser, then that too could be used to develop back-end applications and would have the benefits you describe - that you can use the same language for both stacks etc. For example - if you could front-end stuff in Python, would it be amazing or bad? Or would the current JS devs just fear for their jobs because of it?

Is there any Typescript backend framework as mature as Django?

> Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.

So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.

GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.”

There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.

Because he considers it a "barrier" to have to switch between languages to do backend-only changes. Which is a completely different use case than the one you're describing.

For an SPA where you're essentially doing frontend on both ends, yes, that's obviously easier when you're only doing it once.

But that's not the general case, and I'd argue that transitioning between different mental contexts for components you're not regularly touching is always going to be a hurdle to developers, regardless of the language used. Blaming it on the language is an useless red herring.

The classic example is of course validation, but plenty of other places it can come up.

But as you can see, there's n+1 standards for it, and in practice none of them has a Javascript implementation good enough for productive use. So it's more a "what if?" scenario, had Angular/React/Vue not taken off.