Developing apps on it still seems really, really primitive. HTML alone is not sufficient for a decent looking UI. Tailwind directives gunk it up rapidly. Component frameworks help some but still don’t seem quite as nice as something like SwiftUI. Server side functionality still requires a lot of manual serialization/deserialization (unless you use the newer crop of frameworks that have figured out this is pure noise).
And then there’s JS.
Rails, htmx, and a few others seem like the only ones who really get that a simple web app should be 50-100loc.
> It isn't even difficult if you have any skill at all.
Very constructive, thank you.
I'm talking about the defaults of HTML. There's no pit of success, just lots of div-wrapping and tweaking until things fall into place. Compare with SwiftUI, where you plop two controls and they're spaced sensibly from one another without you doing anything. This was also the case in VB6.
> And then there's another person who didn't take the time to learn JS and just hates it for reasons.
I've been writing TS for awhile now, it's mostly fine. Should've expanded further: npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."
> Show me a native app with a polished UI and any useful functionality in only 50-100loc.
I'll concede that. At 50-100loc, you can have a decent looking native app for a simple task. Presentation layer for a webapp blows through that immediately. Some of that is accepting the medium as is and learning to work with it. Some of it is also the fundamental impedance mismatch of the web writ documents/apps.
>There's no pit of success, just lots of div-wrapping and tweaking until things fall into place.
If you don't know what you're doing and plan things out, sure that is what you might expect - but that's a choice. And that's the same in any language or framework or platform. It's possible to write bloated unmaintainable UIs outside of JS/HTML.
>npm is a bit of a madhouse, and JS culture basically consists of "we shove JS everywhere we can and say it is good because it is JS."
Every package manager for every language is a bit of a "madhouse". It's the nature of free software. I'm not sure why you would expect JS programmers to not want to use JS packages, I'm not quite sure how you arrived at this sentiment.
>At 50-100loc, you can have a decent looking native app for a simple task.
Same with Javascript. You might be surprised what can be achieved in a few bytes of Javascript. Ever visit dwitter.net ? I think you're also leaving CSS out of the equation, which has very powerful styling capabilities. 10 or 20 lines of CSS can achieve a lot of UI styling for a simple app. The HTML/CSS/JS combination is very expressive, extremely powerful and easy to use. Not sure how you think it's somehow incapable of UI similar to native applications, without bloat, and easy to implement. I suppose it depends on your skill level with these tools, because I find it extremely easy to do. YMMV.
I have learned JS & used it extensively in many projects. Including modern SPAs. And I absolutely despise it & wish I could use something like recently trendy GO or RUST.
JS has absolutely no rhyme or reason, single threaded nature makes it gunk up browsers crazy quickly & the insane bloat of "frameworks", which attempt to completely replace already great APIs, while working on top of them... IS CRAZY!
That's really false. The type coercion matrix does make sense for the job it is supposed to accomplish, even if you personally don't agree with it for whatever your reasons are.
If you haven't seen the info presented like this before, then I can understand why Javascript might seem "CRAZY" after reading so many blog posts by people who like to complain for clicks. If you think this chart doesn't have any "rhyme or reason", then please explain why.
>single threaded nature makes it gunk up browsers crazy quickly
That's one way to look at it. Another way is to learn how to work with the system you have, not the system you want. Improvements to the system can be slow, and can't be breaking changes. This is true about every system humans have ever devised.
Webworkers are great, you can absolutely do multi-threaded Javascript, I've done it, it was easy. If that solves the problem in a reasonable amount of time, great, if not then I'll probably do it in C and run it from Javascript since it's so easy to write the rest of the application with Javascript.
Not everything needs maximum performance. For some embedded systems I usually write 100% assembly language because every byte and clock cycle matters. But I know all of this really well, so maybe it seems easy for me. When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges. But today? Naaa. It's easy, it's got a huge support system, a lot of progressive enhancements, thousands of videos, millions of developers and about a billion blog posts on medium.com.
I switch back and forth from C to Javascript and it's a great combination. Less context switching, the syntax close to 1:1 as far as I'm concerned. But C is a pain in the ass in comparison to Javascript, and I know both languages extremely well. I've been writing software almost 50 years.
>the insane bloat of "frameworks"
I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
I have complex front-ends running "at web scale" based on jQuery (for business reasons). We decide every byte that gets included, and manage to score 100% on all page speed tests. No bloat.
>which attempt to completely replace already great APIs,
Citation needed.
> IS CRAZY!
People have been using Javascript successfully for decades. Sorry Javascript isn't your favorite language, but it's not as you describe it either.
> When I started with Javascript in Netscape in the early 90's, it wasn't as well documented and well supported as it is today. That version of Javascript was a bit rough around the edges
Best bug I saw there was how it would sometimes just...give up on running JS if you held it wrong (probably a Netscape thing) and you had to figure out why.
> I'm using Preact for my embedded IoT front-end and the complex web app it compiles is less than 50KB total gzipped. Bloat is a choice, not a requirement.
50KB sent to the client in total? What UI libraries do you use? Happy to try out things; I'm currently a fan of Svelte but haven't tried Preact yet.
I started the project with create-react-app a long time ago. I've since updated it to latest versions of webpack and switched from React to Preact. It's not using any hooks or any modern React conventions, but I don't really need it. I've kept it simple, the only two libraries I include are preact-easy-state and preact-router. Everything else is components I wrote. All images used are SVG, I'm using LESS to compile to CSS, and everything is bundled into a single HTML file that gets gzipped down to about 48KB. I've tweaked the default Webpack configs to get exactly the payload I want. This gets compiled into my ESP32 firmware and served directly from flash. The web app handles all devices configs as well as wifi access point config, and it controls all kinds of device functions using custom sliders and buttons, etc.
And then there’s JS.
Rails, htmx, and a few others seem like the only ones who really get that a simple web app should be 50-100loc.