* Styled select boxes

* Good cross platform datepicker with ranges that looks good

* More form validation options / dynamic form validation

* A good drag api that does edge detection well in every browser

* Bring back frames (would allow good nested routing)

* A built in rich text editor

* A good modal API (or bring it back)

* A way to submit a form via AJAX with just a property (think Rails UJS) to just render html.

> (finally going to be a thing)

Similar to a link targetting an iframe, but without an actually ugly iframe.

I was thinking about something more like `<a href="..." target="#someDiv">`.

That could be some handy (albeit rudimentary) foundation to build maintainable sites on a static server without any JS or build pipeline.

Now the only option is to replace them which is quite sad.

How many end-users complained what a select box is not styled?

I'm not very up-to-date with JS frameworks, so please bear with me. I know that new libraries pop up here and there, but if I'm not wrong, React is by far the most popular, and React has been around for almost 10 years. Vue's not much younger, and now it's 3rd major version.

Is there such a big difference between JS front-end frameworks and the rest of the world?

We're kind of into the next generation of frameworks (Solid, Svelte 3, Vue 3) and that's more about how much JS is getting delivered to the client. The current area of exploration is "partial hydration" where the goal is to write stuff using the component model but do server rendering and only send JS for the parts of the page that'll change client side. For quite a few classes of application this would substantially reduce the size of JS over the wire. All this is less of a benefit than the state control React brought so I expect slower/partial adoption.

More broadly, there's been a resurgence of the render everything on the server and send html diffs approach in the form of alpine and htmx. The other potential area for change on the horizon is web assembly getting host bindings support so it doesn't have to bridge through JS to affect the DOM and other browser APIs.

Maybe one or two years after that.

It's not that bad. I am lead on a large Angular 13 project and we love it, easy to work with, build, deploy. We have literally no issues at the moment. .Net 6 C# APIs on the back-end, Oracle database. It just works.

Take everything with a grain of salt.

Eg: Google Cloud console downloads like 20MB of resources.

Maybe the DX is good, but from an end user perspective, Angular is far from good.

That's literally the biggest (publicly known) Angular app in existence, and the fact that it's slow doesn't have anything to do with Angular. E.g. FWD:Everyone pages load in well under half a second:

https://www.fwdeveryone.com/t/K3KKGbMyQbaCGDc-izuaow/venmo-f...

At this point the main things preventing it from being faster are the TTFB from CloudFront, and the fact that Bootstrap is used as a dependency.

That must be a fairly large application. Consider they are pushing it internally, I have no idea how optimized that is.

When you consider this is cached, that means you only have to do that once until an update. Similar to any other software.

Look at what Electron apps do in terms of constant updates. This is similar, but it's a web page.

And the problem is not only the bytes loaded but how clunky and slow it is in general.

The Electron argument doesn't make any sense as it includes two runtimes ffs.

I just don't get the concept of people being like, I'm going to start a project that's likely going to take the ten years to become successful, but I'm not willing to spend the twenty hours to read the documentation so that it will be successful.

Last I asked, it was still a tire fire, even after more than a dozen versions and after a fully mature previous framework that was replaced :-(

Basically, they now (as of Angular 12) force you to build a difference version of your app for each language you support, and either serve them up at different URLs or use cookies to serve up the right version to each user. The technical reasons make sense...your translations occur at build-time, rather than at run-time, but it's a pretty drastic change that occurred out of nowhere.

Not a fan.

I use ttag (https://ttag.js.org) with React and like it. I don’t see any reason you couldn’t use it (or another library) with Angular.

Well, kinda? I tried to set up typescript, storyboard and tailwind the other day, via create-react-app - and it's not really clear if I can/should use npm or yarn, and what, if any bundles like webpack or esbuild/craco I need... Nor did any of the documentation/tutorials "just work" - and as final punishment I think I had to download more than a gig of dependencies.

I get that there are many layers of tooling, but when I can't seem to get half the features of qt, nor a gui for 4gl development - it does seem like there's a lot of churn and pain for limited gain.

Using Laravel with Breeze and the set up just works out of the box.

The real difficulty is that web UIs have to be very flexible and varied: you have different screen sizes, mobile vs desktop, and every website has a different UI vs native apps all looking similar. And yeah, there are over 100 different web frameworks most which have a particular use case, although you don't have to use the perfect tool for the job. Also, there are a few quirks left over from the old days of HTML/CSS/JavaScript.

But making a basic website nowadays on modern tools is very straightforward. Clone a vite starter project, write out your DOM in React or Vue or Svelte or Solid.js or whatever, and launch a live-server with a browser inspector to fine-tune the design. There are some especially bad JS frameworks (looking at you Meteor), but that's the case for most platforms.

Made me chuckle. Web frameworks are thin-to-medium layers of dealing with bs that web graphics are by nature and design. Their entire purpose orbits around that. Runtimes that do not suffer from these birth traumas don’t even need all that complexity. E.g. with apple core ui libraries you can in hours design a new flex/grid/stack/align/etc geometry container (which takes decades in the web), can animate things, make them cheap-scrollable, sizeable, constrainable out of box. Do you really think that web reflows and size dispatch up and down a hierarchy is a complex issue which only a “top-notch” web tech can solve?

Of course web traditionally was more game-like and does not have any guidelines and presentation standards beyond “reset”, allowing to focus on design better than the rest of the world (and due to widespread nature monopolized by a single platform), but calling frameworks which basically deal with its own shortcomings and ancient issues ahead of the world is pretty misleading.

What exactly is ahead of the world in there? My bet is on reactivity, components, caching and lazy redraws, which “weren’t a thing” before web, because, you know, jquery and comctl32.dll were bad.

making a basic website nowadays on modern tools is very straightforward … and launch a live-server with a browser inspector to fine-tune the design

Ah yes, something we had at VB/Delphi 3 times but not quite as RAD. I mean, maybe launch a live server, drop a query and see live data in design-mode, or enumerate columns and make some of them editable out of box? Or fill a form with master-detail link? You can’t. Web praises primitive/workaround things which nobody even had a name for before, so trivial and obvious and default it was.

It's your choice to learn a new JS framework every 6 months. If you don't want to use the new thing, then don't. Just make something valuable and use what suits your needs. That's all that has ever mattered.

Today, it's Go in the backend and Svelte in the frontend, or vanilla JS for very small and simple tools.

Nothing like this did I ever see in the go or kotlin world.

It's obviously not a one to one replacement for an honest to god frontend application, especially one that can be recompiled into an offline capable native app, but where you can use it, it does a lot of lifting.

I actually think things are pretty great these days. Even amongst the different frameworks and tools, things are settling into a common set of ideas and concepts.

If you made the choice to build an app on React/Vue a year or two ago, that decision is still valid today and I think that speaks a lot for how far things have come.

0: https://htmx.org/

Is there really a JS script parsing all of that? Seems like there would be performance penalty.

Also, I still believe that web-pages should be functional without JavaScript. For all of my traditional SSR / non-SPA projects I definitely put effort into ensuring my projects exhibit graceful degradation.

There's already a lot of things we can do without any scripting at all: animations and dynamic content, for example - and we can even use CSS trigger-tricks for basic interactivity (e.g. show/hide toggles) all without scripting. What I'd love to see next is something like WPF/XAML's declarative data-binding in HTML (but in a less broken way...) - and I'd like to be able to submit a <form> element directly as JSON, as well as AJAX-like <form> submissions that don't replace the current document, all without scripting - that's the dream (oh, and CSS positioning relative to an arbitrary named element, I could go on...).

I think this is actually not a tangent at all, but rather, it’s kinda the whole point! I doubt we’ll ever get to a point where there’s a single standard, because a single standard can’t satisfy everyone.

You are already free from this. The only one putting that pressure on you, is you. Pick something and stick with it, and spend your time learning _how_ to build things, instead of _what_ to build it in.

I'm totally on board with building better tools and solutions. And with pointing out the flaws of tools as we find them. However it is folly to thing this work will ever end.

Something better (and different) will come after SPAs, and the cycle will start again.

Servlets run on the server, I think you meant applets? If so, I'd argue a counter-point: WASM and <canvas>.

The de facto starting point for writing browser applications is React, and that came out almost nine years ago.

It’s fine to say React is a decade old but the way we write apps with React has drastically changed multiple times with the only real constant being JSX.

And let me be a bit proactive, yes, I know react is backwards compatible for the most part, but similar to PHP, just because the syntax is still supported doesn’t mean that’s the recommended way to write apps today.

React arguably started the churn of JS fatigue we all complain about now.

I don't really agree with this. Sure, we went through createClass -> class -> functions + hooks, but the core is still props, state, and lifecycle.

Take lifecycle. It used to be very explicit. Then hooks turned it into this weird implicit thing where you have to know how use effect works and how to only trigger something once, but then the empty array thing is an anti pattern etc etc. Now with suspense, that lifecycle is changing again in a way. I’ve seen some tutorials where the teacher refactors out of use effect into throwing a promise. But then you can have use effects inside your thrown promise and dealing with module scope potentially.

It’s late and im a little out of it, but to me, this is all a lot of churn and creates long periods of uncertainty as developers try and decide which of these features they want to use and when.

At a certain point it can get really frustrating when it feels like you need to rewrite your app to stay up with “best practices” and attract new talent into your org. It would be one thing if the best practices were making things better functionally, but I find that argument hard to justify for anyone outside of Facebook scale. Angular and Vue stuck with a more traditional lifecycle ideology and there are plenty of apps building at scale on those frameworks. That stability in low level APIs gives a community time to grow and mature without leaving a bunch of people behind.

I honestly believe React would not be anywhere near the scale of what is today based on merit alone. They were lucky to see the demise of angular 1 and learn from that mistake and now Vue is sorta suffering the same way by moving too far away too quickly from 2 to 3.

Anyway, ramble over! :)

That doesn’t sound right. The linter will certainly yell at you for doing that, and I’d be surprised if the program did not crash. The “rule of hooks” due to their implementation is that you can only call them from directly inside of a component function block, I.e. not from within an if block or a promise.

Developer choice is one of the things people cite as a reason not to use React already, since you have to pick a router, state management library, etc. What’s a couple more decisions about built-in features? =)

I will say that I feel the opposite way about hooks: I only became interested in using React after hooks were added, because classes in javascript always rubbed me the wrong way, and I want to get as close as possible to functional programming style from start to finish. We’re using it now, and reasoning about the app is much simpler than before. I can’t say how much is due to hooks specifically vs overall React app architecture, but the components are much more pleasing to my eyes!