[lukicdarkoo]

Professionally, I do embedded and robotics, but once a year I find an excuse to create a simple web application (to stay updated). Every time, I get impressed by power and simplicity of the web technologies in general. In JavaScript those are things mentioned in the article + WebComponents. For CSS those are flexboxes, grids, and animations. In my opinion, React made a revolution with hooks and contexts. I love the direction in which the web world has been going!

[BrissyCoder]

> simplicity of the web technologies in general

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

[rtpg]

Try writing a GUI with other toolkits. Hours of tweaking random XML to try and figure out why some constraint solving thing just isn't working...

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

[kaba0]

Absolutely not true. Windows forms, WPF, JavaFX, Swing all are much more productive than the vanilla web. Like, how many lines of code does the most basic vbox/hbox thing requires in web technology? Many of them even have dragndrop ui creations, and this XML hatred is downright stupid at this point. How about criticizing the technology and not a random medium for that? Is writing something stupid in JSON inherently better?

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.

[ath92]

That example you mentioned would be just a couple of lines of html with css (which you could inline if you wanted), and there are plenty of drag and drop tools for the web (WebFlow is a modern example, but they have been around for decades).

[kaba0]

Why would it need any sort of CSS? Isn’t HTML supposed to be responsible for the structure of a webpage? And of course it can be done, but if we do something like hbox inside a vbox inside a vbox, the resulting code will be ugly as hell (perhaps Webcomponents will help a bit here?). Like, what is the point of HTML at that point? To spam divs (pun sort of intended)?

And there are plenty of other “layouting primitives”, all of which are quite cumbersome. And due to HTML encoding some form of semantic meaning only (though seldom used even for that), drag n drop tools can’t generate easy to read/modify output. Also, without js frameworks, you can’t really just embed another component into it trivially.

And I’m not trying to shit on web tech, JS has absolutely overcome its shitty past, and is quite a likable language nowadays, and CSS is an extremely powerful and expressive system (though this latter is due in part to how shitty html is). My only gripe is with HTML that is simply not fit for the task (as it was never meant for that).

[yoz-y]

> Isn’t HTML supposed to be responsible for the structure of a webpage?

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.

[rtpg]

Drag n drop UIs don't really help when you have too much dynamism (like "oh only have this button appear in these conditions", "do this here", etc). And I would say that box layout offered by CSS is much nicer than the constraint layout system _when you have a lot of dynamism_.

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.

[kaba0]

> Drag n drop UIs don't really help when you have too much dynamism

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.

[hnbad]

> Like, how many lines of code does the most basic vbox/hbox thing requires in web technology?

CSS:

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

HTML:

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

Or was that a rhetorical question?

[noduerme]

Such a great point. HTML is a terrific way to write documents and TERRIBLE way to lay out applications - especially for lots of different screen sizes. It's not surprising at all to see Google embracing Canvas now to underpin Docs; basically they are admitting that it would have been better to write the whole program in a Java VM or in Flash than to rely on the browser for layout. This is patently obvious to anyone who builds large web applications. Ten years ago we had ASWing, JSwing and plenty of other actual frameworks where you didn't have to diddle around with tons of logic embedded in templates which were embedded in other logic; but thanks to Apple we're still saddled with this wretched Javascript/HTML paradigm that was never meant to do much more than inline some animated GIFs back in the 90s. Yes, it's gotten better (I've been doing this since the 90s, so I know). But it's so inelegant. To some degree this is just a problem with open web standards. It would be better if any one company actually had dominated to the point where they could write a closed standard, because at least it would be coherent and cross-platform. It was a lot easier to write a web app in 2010 than it is now, and it pains me to think how many hours I could have avoided reinventing the wheel if Flash had been allowed to stick around. Any app written entirely now on canvas is just replicating a VM that already existed a decade ago in what was by then a much more mature ecosystem - and was faster then than canvas or WebGL is now.

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.

[friend-monoid]

I'm not sure I buy the idea that "efficient and easy tooling around a technology makes the technology". We all went through the same Dreamweaver pains.

[kaba0]

How come the minuscule userbase of native frameworks have better tooling than the numero uno popular web? It may mean that there is a technical reason in the background.

[goto11]

They solve a simpler and more constrained problem which makes it easier to make tools. Something like Windows Forms are basically WYSIWYG - you drop some controls on a canvas and now you have a GUI. But the GUI will not gracefully adapt to different screen dimension from large monitors to mobile.

[pmontra]

30+ years of history?

[jcelerier]

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

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

[einpoklum]

I agree that it's pretty simple to get a button on screen in Qt, but your linked video presents it as horribly complicated. And requiring an IDE to do it is pre-admitting it's complicated.

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

[jcelerier]

> but your linked video presents it as horribly complicated.

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

[bryanrasmussen]

>(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.

[presentation]

Just that starting modal with 6 steps to choose various configuration stuff would probably throw a beginner into a loop for a while, even if you could just skip it all. Maybe if this IDE wanted to be beginner friendly, they ought to consider just having reasonable defaults and letting power users change them later - like how web tools tend to be designed these days.

[hnbad]

There are visual editors for React. Pretending QT is easier than web technologies because it's easier to drag a component in a visual editor than type text in a code editor is comparing editors, not UI technologies.

[indigo945]

What do you feel is a more "modern" way to do a GUI in C++?

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

[krapht]

Is this a joke? There's a whole world of software out there that isn't web based. Anybody who hasn't switched to a Chromebook uses them every day.

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

[einpoklum]

Well, the question of what's "modern" in C++ is both deep and contentions. But I won't shirk the question...

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();
  }

This is not perfect IMHO; for example, I don't really like the confusing div string with the many < and > signs. But you can put this in a text editor, build it with `g++ -I/path/to/nana/includes -L/path/to/nana/libs -lnana` - and it will just work, on various platforms. No secret sauce, no need for a bunch of IDE dialogs or any special configuration or action.

[alibarber]

There is a wide world of applications and development that don't have anything to do with the web.

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...

[cies]

If not using C++ with Qt, Qt is a bit harder to get going. But I honestly dont think that building a UI with JS/HTML/CSS is easier than in C++/Qt.

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

[klausjensen]

Agreed wrt other GUI toolkits.

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

[kwanbix]

I imagine you never used Delphi, VB, or even Lazarus?

[kodah]

Having worked on both desktop and web UIs the problem you're describing occurs in both worlds. Usually with web you run into it when you're dealing with a more sizeable app, or fancier things you want to do with your framework.

[1vuio0pswjnm7]

Sounds like "developer productivity" could be increased by not having to create GUIs. As an end user, I will happpily accept and in fact prefer text-based, keyboard-driven interfaces.

[zodiakzz]

I am a senior web developer with 12 years of experience, also perplexed by that statement.

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

[brundolf]

There are different definitions of "simplicity". The entire stack top to bottom may not be simple, but if the developer experience is simple (which it can often be on the web- that's a major driver of the web's prevalence as a platform), that can be what matters.

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.

[kwanbix]

Maybe you are too young, but there was a time were we used RADs (Rapid Application Development) environments like Delphi, VisualBasic, Visual C++, etc. Those solutions which are from 1990s, are still years ahead in simplicity vs what you need to do to build a full web solution today (front-end and backend). Of course the web has many other benefits, like 0 install, runs everywhere, always updated, etc., but calling web development simple is just crazy in my humble opinion.

[kaba0]

What are the incredible benefits of the web? Have you worked on a complex QT app?

[subw00f]

I have worked with both, including Widgets and Quick. I wonder why you think Qtcom is focusing development on Quick, which uses QML (JSON-like syntax) and JavaScript (ES6), while declaring Widgets "feature complete", mostly releasing minor fixes, in other words, keeping it stagnated. The obvious answer for me without getting into Mobile vs Desktop development is: it's easier to get new professionals to use technology as popular as JS (or any other web related stuff), and definitely cheaper for companies to hire said professionals, therefore making it a easier pick for new projects. To summarize the benefits: easier for junior devs to use and because of that overall cheaper/faster deliveries. Note that I'm not saying anything about quality.

[pseudalopex]

Junior developer doesn't mean a developer who just knows JavaScript. Cheaper developers doesn't mean faster or cheaper delivery in the long run. And I don't think brundolf meant cheaper developers.

[eurasiantiger]

I have seen a LOT of Qt apps and 100% of them had worse UI than your average web app.

[pseudalopex]

I've seen lots of Qt apps. Most of them have been much better than the average web app.

[ramchip]

Where do you get that figure from? I'm looking at the add/delete statistics for instance:

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

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

[shakow]

Indeed, tokei gives me ~400 000 lines, including ~310 000 LoC.

[spookthesunset]

In my 20 years as a developer I’ve learned that the more polished something looks on the surface, the more complex the codebase under the hood becomes. Things are simple to the end user because of all that complexity.

[cryptos]

That is my experience, too. I worked on a SPA with a more or less simple looking table that presented hierarchical data and made them editable with form elements. Under the hood there were hundred lines of very dense rxjs code and the whole thing was communicating with about 10 HTTP endpoints. But it looked simple.

[buchanaf]

It's a monorepo, so the only package you are really interested in is 'packages/react-dom', which I'm guessing is less than 3 million.

[uryga]

what niche language?

[vgel]

Flow

[egeozcan]

I find it interesting (and, a bit funny, tbh) how flow became a niche language. This is the difference investing in tooling makes, folks.

[11235813213455]

while preact is 3kb and does the same

[mpfundstein]

it does not do the same. it does few things that react does and thats it. what an ignorant comment

[11235813213455]

There's preact/compat sub-module for the remaining react features, please inform yourself before inappropriately flaming someone. There some very slight differences https://preactjs.com/guide/v8/differences-to-react/#what-s-m... nothing blocking at all

[59nadir]

Does it have hooks? Class components are super tedious in comparison.

[irrational]

Seriously. I’ve been doing web development professionally since 1998. I’d love to have OP write a blog post to teach the rest of us about this simplicity.

[adventured]

I've also been doing web development on essentially a daily basis since the 1990s.

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.

[taotau]

What sort of systems are you building ? I’m guessing some variation of CMS, shopping cart or simple crud backoffice reporting systems.

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.

[adventured]

The last thing I built was a CMS structurally (a new non-commercial knowledge service), took about ~18 months to build. I plan to work on it for the rest of this decade approximately.

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.

[egeozcan]

> so much data that mongodb makes sense

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.

[swagasaurus-rex]

Parent is probably referring to how MongoDB has consistency issues and isn't recommended by third party testers like Jepsen.

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

[javajosh]

Taotau my aesthetic is similar to yours, but it's true that we are a minority. Devs are, as a group, perceived as technology maximalists that love new toys, and the truth of the perception is reflected in the software landscape. Libraries like Angular, RxJs, and Webpack are all packed to the gills with features! It's also reflected by all the "slightly better" options we get in our tooling (yarn v npm) and (scss v css) and (ts v js) and even (ts v es)lint. But without exception, all of those incremental improvements still require that you have total mastery of the browser's native runtime, html5 + css3 + ES6 + dom + async, and all the protocols it enables, HTTP, TCP/IP, DNS, and all the infrastructure that's grown around it all (CDNs and load balancers and hypervisors).

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

[einpoklum]

> Devs are, as a group, perceived as technology maximalists that love new toys,

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.

[fitpolar]

> HTML, CSS, JavaScript, Go or PHP, Redis, MySQL or Postgres, Ubuntu & Nginx.

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?

[adventured]

The premise isn't that what I'm using will make it easy for somebody with zero knowledge to become good at web development in 24 hours or a week or a month, or any such pitch. It's certainly relative.

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.

[theonething]

Do you roll your auth and stuff?

[adventured]

I started building my own auth about 20 years ago and I've been learning and rolling (improving it) as I go. I've been using a structure that I've been iterating for about the past 6-8 years or so. Hardly a week has gone by that I haven't worked on something related to auth.

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.

[archerx]

I made a custom e-commerce from scratch with PHP and doing the auth system wasn’t hard at all and it is pretty secure. I feel people make auth seem scarier than it really is.

[petewailes]

Don't roll your own auth.

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.

[scrollaway]

> the auth system wasn’t hard at all and it is pretty secure

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.

[QuadrupleA]

Definitely agree with this type of approach - and my experience as a freelancer (thankfully in charge of my tech stacks) is that clients are happy to pay for fast, reliable software built like this.

[cies]

Software that does not have a one-man-team behind it (with all due risks): that's where bigger companies pay even better.

[z3t4]

Web development, even single page apps, and progressive web apps, can be simple if you skip the web frameworks which solve non-problems and complicate things. The most difficult problem in web development is to make the user interface (UX) work on everything from smart-watches to 40 inch 4k monitors. CSS solves this problem, but it's not an easy problem by itself. The second most difficult thing in web development is automated testing across the stack, testing both back-end and front-end, with different user devices. It's complicated and time consuming to write the code that test every function automatically. Third most difficult thing in web development is optimizations, the browser dev tools doesn't say much about what is going on internally in the JavaScript engine.

[pseudalopex]

Show me a user interface that works on anything from smart watches to 40 inch monitors.

[einpoklum]

> CSS solves this problem

No, it does not.

CSS allows some mitigation of this problem.

[austincheney]

I was able to create an original OS like GUI, including file system interaction, using vanilla JS (TypeScript) in about two weeks. I am still using it. The actual GUI is just a couple files each comprising about a dozen functions, nothing really complicated.

[mixmastamyk]

Delphi probably would have gotten you there in two hours.

[mssundaram]

Probably in contrast to the embedded hardware development the OP does...

[XCSme]

The nice part is that you can make web dev as simple or complex as you want. You can write your entire application in a single index.html file with no compilation or build step. You can also use various preprocessors, scaffolds, libraries and frameworks to achieve the same result. The choice is yours.

[VWWHFSfQ]

I feel like I'm a freaking alien right now.

[rkagerer]

One thing I hate about the modern web is pages that load with lots of missing content / empty components and then download and render that content afterward.

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?

[allset_]

It's not specifically a React thing, but JavaScript enables it. Lazy-loading content is a good idea if you're building dynamic web _applications_, as common components (buttons, modals, etc.) don't need to be reloaded over and over. However, with mostly static content like a blog, it's generally not a great idea.

[mbirth]

You can probably thank Google for that as to get a higher page ranking, a site must do the initial load fast. And showing only empty placeholders is fast.

[dzhiurgis]

Any modern browser automation tool can wait for all requests loaded. Also sounds like you need better internet or re-check your expectations.

[Fredej]

I absolutely agree with OP. I find it annoying that things load like that - even on a gigabit line with a beefy modern CPU. The solution is not to slow everything down to wait for the last thing to be loaded.

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.

[deergomoo]

> their initial content should be included in the payload with the initial page load

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.

[midrus]

Even if you are talking about SSR such as how Next.js does it, you wouldn't be spanning processes from your ruby/php application. You would deploy it as a separate application responsible of the frontend, using your ruby/php application as a backend service providing an API.

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.

[deergomoo]

> An alternative is to just serve the HTML from your ruby/php and then take over in the frontend

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.

[gpanders]

What, why? It’s just HTML, which PHP and Ruby can generate just fine.

[deergomoo]

If your component is generated by something like React you'd need to be running React on the back end to pre-render the component and have the front end re-hydrate it.

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

[antris]

>In my opinion, React made a revolution with hooks and contexts

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.

[madeofpalk]

> nothing in React was / is innovative except for the virtual DOM diffing

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.

[antris]

100% true.

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...

[8note]

I think the innovation comes from making it easy to do. Its been transformative for how people write UI code as a result

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

[miralize]

On that point, I think the next innovation to come to front end development is to declaratively think about states using finite state machines & statecharts.

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.

[antris]

I suppose. It just feels weird that the post was highlighting hooks and context, while VDOM was omitted. VDOM was easily the biggest thing in my opinion. I had never seen anything like it and it worked wonderfully. It's not to say that everything else in React is bad, it's more like everything else pales in comparison to how huge VDOM was when it was introduced.

Kinda like hyping iPhones innovation without ever mentioning touch screens.

[Mogzol]

I read it more as talking about a revolution within React. Hooks and context are (relatively) new features that do "revolutionize" how you write components. That's not to say VDOM isn't important, it just isn't anything new, it's been a part of React since the beginning.

[madeofpalk]

I'm so confused by what you're saying all over this thread, apart from "React is something that exists, and I modified the DOM before it existed". Okay?

[varrock]

> many people don't understand any better why or how React is good and when it's bad to use...

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?

[antris]

One these problems usually:

- 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.

[thealig]

I have experienced working on a messy application codebase (jQuery + Knockout.js) which was 7-8 years old and seemingly was hastily made by on contract of another company. Had to refactor it to ES6 (dynamic imports) -needless to say it was a big pain with unpredictable barely any performance improvement as compared to refactoring on another codebase.

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.

[Oddskar]

I'll bite. What part of React has really been innovative?

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.

[ketzo]

Well, isn't there something a little "revolutionary" about mainstream adoption of cutting-edge techniques?

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.

[antris]

>Well, isn't there something a little "revolutionary" about mainstream adoption of cutting-edge techniques?

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.

[warent]

> but all of the other ideas have been implemented and used on the web before.

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.

[tppiotrowski]

Honestly, the separation of concerns movement where content writers do HTML, designers do CSS and programmers do Javascript, all with with minimal overlap, set web development back a good 10 years. React was a wake up call that the three are intertwined so closely that you cannot think about them in isolation.

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....

[sircastor]

HTML in JavaScript still feels wrong to me and I still hate JSX. The Vue and Svelte approach to simply having the HTML in the same file was much more digestible.

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.

[kentor]

Why hate JSX? There are lots of benefits to it, like debuggability and variable scoping rules are exactly those of javascript. Templating languages, on the otherhand, are not debuggable and have awkward scoping rules. And, they always feel broken in one way or another.

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

[graftak]

Don’t forget proper and full typescript support. Going back to vue (2) after doing tsx was like going back to jquery; loads more context switching and mistakes.

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

[antris]

Yes, yes and yes. 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, 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.

[ZephyrBlu]

I'm very curious what the better, academic version of VDOM, hooks and components that has already been done looks like in comparison to React.

[antris]

Svelte does reactive UI without a VDOM at all. Every DOM operation flows from declarative instructions based on the state of the application, without a need for VDOM or hooks.

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.

[ZephyrBlu]

I know what Svelte is. Svelte wasn't done before React or by "FP academics" though, which is what you said in the comment I replied to.

[eurasiantiger]

The esotericity is not in the expressible semantics, but in the syntax.

[nextaccountic]

I think the Opa language was doing JSX-like code in the frontend before JSX http://opalang.org/

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.

[hajile]

JSX as syntax goes back to ES4 and the E4X specification (though the function aspect goes back to php as far as I know).

[ptx]

> virtual DOM diffing ... is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture

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

[antris]

State and DOM being mutated all over the code base was the norm before React. In many apps, state was a thing that was spread out all over the code and could be mutated by any part of the code. And a DOM was another global state on top of that, that had to be kept in sync with the data of the application. Otherwise users would be shown a state that wasn't representative of the actual state of the application. People did this with careful DOM modification code, trying to always remember to set, reset add and delete DOM nodes correctly. Of course, this caused many bugs and sometimes huge performance issues.

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.

[atom_arranger]

The best part about React is declarative rendering, you tell React what the DOM should look like, it makes it so. React does this using a virtual representation of the DOM, but this is an implementation detail.

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

[idkwhoiam]

My only issue with CSS is the absence of container queries [1]. Now I need to rely on size listeners of the container element to make my components truly responsive. Media Queries do not work for components. CSS Grid & Flexbox are nice but not enough to achieve radical layout changes for certain breakpoints.

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

[willhoyle]

https://github.com/marcj/css-element-queries

I’ve had pretty decent success using this library.

[rthomas6]

I do embedded also, and FPGAs. Do you have any suggestions for how to start learning web stuff? Every time I try, I get overwhelmed by all the frameworks, libraries, package managers, build pipelines, etc. There doesn't seem to be a set of best practices for what to do, or even what is needed and what isn't. What is the best way to get started?

[reynhaim]

https://fullstackopen.com/en/

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.

[_pdp_]

Do you start learning FPGA programming by studying frameworks? I doubt. Like all other things you start learning the basics and then once you know them you can abstract complexities with frameworks. There is nothing overwhelming about web development. It is trivial.

[rthomas6]

Creating a CRUD website is supposed to be pretty fundamental, right? And how do I have individual user sessions with logins that show different content to different users? That seems, if not basic, fundamental to at least know how to do.

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.

[lawik]

If someone says they get overwhelmed by something, chances are decent there is something overwhelming about it.

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.

[_pdp_]

> If someone says they get overwhelmed by something, chances are decent there is something overwhelming about it.

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.

[ffhhj]

Don't bother with frameworks, write plain HTML+JS+CSS and use jQuery.

[neycoda]

HTML then CSS then JavaScript. I've taught all three and people struggle more in a different order. HTML is the skeletal architecture, CSS is just styling, then JavaScript is behavior. Those three things in that order are like orders of "need". You need HTML first to have a webpage structure, then styling to make it easy to understand its elements, then the behavior is more complex than both. I don't know why I see people put JS learning before CSS... JS is much more complex than CSS, and a much different change in paradigm from HTML than CSS is.

[DrSiemer]

What exactly do you still use or need jQuery for?

[ffhhj]

It's mostly a wrapper of JS functions that takes care of compatibility, and makes code more readable.

[buchanaf]

Compatibility isn't really a consideration nowadays.

[PedroBatista]

I like the API.

[atatatat]

HTMX anyone?

[biinui]

May you kindly point me where to start learning robotics, and recommendation for a starter robot arm? Maybe ~$300 if something worthwhile exists at that price range. Take care.

[MarkSweep]

Not OP. This is not necessarily the friendliest or best place to start, but in terms of hardware costs it's great: the ST-Micro P-NUCLEO-IHM001:

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...

[jb1991]

Strange, I was pretty sure your parent was asking sarcastically!

[crooked-v]

Lego Mindstorms could be worth considering as a general-purpose hobby robotics platform: EV3 (the older version) can be flashed with a custom Linux distro, and Robot Inventor (the newer one) can run Python scripts. In either case all you need to add more structural parts is to pick up a bulk case of used Technic parts, so it's eminently reusable for multiple unrelated projects.

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

[monocasa]

Oh jeeze, I feel old if the EV3 is being described as "the older one". I have horrible memories of writing some "Not Quite C" for RCX because the compiler didn't support modern amenities like stack frames.

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

[wcarss]

A group I worked with in a high school lego robotics competition managed, if I recall correctly, to achieve 'recursion' by defining 2 very similar functions and having them just call each other. It was a frustrating device at times but also a really fun experience!

[cema]

Is called a trampoline, a standard trick more or less.

[wcarss]

Cool! That makes sense -- it still felt incredibly clever and tricksy to us when we were about 16 and trying to map our 'beautiful algorithm' into NQC sometime past midnight, for a morning competition.

[valand]

On React, people talk about it especially for it being a UI tool.

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.

[geodel]

I hope this is sarcasm.

[neycoda]

Web hooks are nothing new in other languages, they're just built-in functions that do things that were previously cumbersome to code yourself. That's only revolutionary to React. PHP is a great example of built-in functions, yet I've heard React fanboys complain that PHP has too many built-in functions (which is a really odd thing to complain about).