Here sucks is in the sense of suckless philosophy, I don’t think everybody likes the suckless movement but I’ve seen that many people, me included, don’t like how modern web apps look like (messenger and tiktok are like the worst). So if I want to make interactive web apps, what are the better technologies to not make the web shittier ?
Use TypeScript
While JS does suck, most of the people who complain endlessly about it are fairly inexperienced tbh. A lot has changed over the last 20 years and it’s honestly rare to code in pure JS nowadays. You can’t really escape it when doing frontend work anyways.
You can do a lot with modern css too, especially extensions like scss
The bigger problem imo is overuse of third party modules, especially through npm. That’s how you get a massive amount of bloat
This. There has been a huge investment in the tooling around JS. Using TypeScript, you get the benefit of that ecosystem with a decent language.
It isn’t perfect, but it’s perfectly cromulent.
JS is fine, it’s more that people overdo it and bundle their heavy, deeply layered frameworks with thousands of npm dependencies for the web. Often times analytics/tracking/ad libraries are a major contributor of bloat, I once shrunk down a package-lock from thousands of lines to a few hundred just by stripping the telemetry libraries from an open-source app.
Use the right tool for the job. Sometimes it’s a static page, sometimes a server-rendered dynamic page and sometimes a single-page application, all of those can be made performant.
Part of the reason that “JavaScript sucks” is BECAUSE it doesn’t have alternatives. If you want to build a WebApp that manipulates the DOM, JS has the ONLY API to do it.
For me, “JavaScript sucks” not really because of the language itself, but because there’s such a massive disconnect between what it was designed for (small amount of bells and whistles within a web page), and what the ecosystem uses it for (foundation for entire GUI applications).
If you want to build WebApps, learn JavaScript, then do all your development with TypeScript, and be VERY mindful of the third-party dependencies you pull into your project.
If you are doing web development you can’t really run from javascript.
You can do so much with modern CSS tho
The language itself has gotten a bit better. It’s not amazing but it’s decent for a scripting language, and very fast compared to most scripting languages. TypeScript can also really help a lot there, it’s pretty good.
It’s mostly the web APIs and the ecosystem that’s kinda meh, mostly due to its history.
But what you dislike has nothing to do with JavaScript but just big corpo having way too many developers iterating way too fast and creating a bloated mess of a project with a million third-party dependencies from npm. I’m not even making this up, I’ve legit seen a 10MB unit test file make it into the production bundle in a real product I consulted on.
You don’t have to use React or Svelte or any of the modern bloated stuff nor any of the common libraries. You can write plain HTML and CSS and a sprinkle of JavaScript and get really good results. It’s just seen as “bad practice” because it doesn’t “webscale”, but if you’re a single developer it’s perfectly adequate. And the reality is short of WebAssembly, you’re stuck with JS anyway, and WASM is its own can of worms.
And even then, React isn’t that bad. There’s just one hell of a lot of very poorly written React apps, in big part because it will let you get away with it. It’s full of footguns loaded with blanks, but it’s really not aweful if you understand how it works under the hood and write good code. Some people are just lazy and import something and you literally load the same data in 5 different spots, twice if you have strict mode enabled. I’ve written apps that load instantly and respond instantly even on a low end phone, because I took the time to test it, identify the bottlenecks and optimize them all. JavaScript can be stupid fast if you design your app well. If you’re into the suckless philosophy, you can definitely make a suckless webapp.
What you hate is true for most commercial software written in just about any language, be it C, C++, Java, C#. Bugs and faster response times don’t generate revenue, new features and special one-off event features generate much much more revenue, so minor bugs are never addressed for the most part. And of course all those features end up effectively being the 90% bloat you never use but still have to load as part of the app.
So, I should learn it well and be careful on what to add and my product should be good, okay I will give it a try insha’alLah
I like Rails or .Net with JS frontends. JS backends are an affront to God.
JavaScript is fine, everything thats wrong with it is corporations trying to turn JavaScript into java. Its a fucking mess at large places.
Its fine for webapps, its what the internet front end runs on.
I’d say it’s the tooling that sucks more than anything. I’ve had installations fail because of bad caches (and resolved it by doing things NPM advised me not to do), installations that take forever and seem stuck on one dependency, conflicts with ES and Common modules, node_modules folders that dwarf other folders in size, nobody makes proper use of devDependencies, some odd dependencies on Java or Python, and so on. I think the ease of learning JS has done it a disservice as you get millions of devs contributing but not all are trained as devs or computer scientists and you get a flood of libraries that all do the same thing and often even reproduce built-in functionality.
I really do enjoy coding in it more than any other language but when it comes time to run or build is when my rage kicks in.
Wait… what were we talking about? Oh, yeah.
Shitty web apps aren’t really the fault of the underlying tech. This is a problem of design and I don’t think the programming language really has much of an effect on the usability.
Javascript has its warts and quirks, but it’s fine. I hated it until Typescript came along. That way you can at least get some sanity checks and keep the language generally in the rails of normalcy.
Like it or not, the browser basically only knows how to run javascript, and using another language to compile wasm is almost certainly going to be more headache than whatever gain you might get.
However, what you seem to dislike is the UX of modern web apps which is barely related to any of that.
I highly suggest ruby on rails. Simple language and amazing to work with.
Well, part of the problem is that web apps themselves are kind of alien on the web. The web is generally document-based. Web apps take the document format and try to turn it into something it’s not.
There’s a way to not do the JavaScript, but it doesn’t fix things being document-based and it can be argued that it makes other things worse in some respects.I’m talking about WebAssembly. Basically, you can write your web app in HTML+CSS+Rust and then the Rust part is compiled to WebAssembly, which then takes the role that JavaScript would normally take. It does not have to be Rust, lots of languages can be compiled to WebAssembly, but Rust has the most mature ecosystem for that, as far as I’m aware.
In principle, it is also possible to use WebAssembly to render directly to a pixel buffer, but that’s really rather heavyweight and not terribly responsive, so not generally done, unless you implement a game¹ or similar.
Alright, so back to the document mangling approach. There’s various frameworks available for Rust. I’ve used Leptos so far. There’s also Dioxus and Yew and probably others.Advantages:
- Don’t have to write JS.
- Can write Rust. Rust has some concepts that mesh really well with frontend dev, like the
ResultandOptiontypes for error handling, which you can pass directly to your rendering stack and it can show either the data or the error (or nothing). - Can use the same language in backend and frontend and therefore also get compile-time checks that the two work together.
Disadvantages:
- The ecosystem is young. You will find barely a fraction of the component libraries as you can find for JS.
- Rust also has concepts which don’t mesh well with frontend dev, like the whole memory management concept. Those frameworks bypass that or make use of it in clever ways, but things can be a bit peculiar or overly complex at times.
- WebAssembly is sent to the browser in one big blob, because it’s a compiled program. This means you get somewhat of a loading time when first loading the web app. There’s ways to mitigate that with “hydration” strategies, but yeah, still a thing.
- While JS is often minimized/uglified and therefore not readable anyways, WebAssembly makes that even more of a reality, because it is essentially assembly code that’s sent to the browser. It does still call the same APIs under the hood as JS does, so content blocking shouldn’t be affected, but yeah, can’t try to understand the code itself. This can also make debugging during development somewhat more painful.
- Well, and it’s also yet another web standard that browsers have to support. It doesn’t make browsers simpler in the sense that suckless would like.
I’ve listed a lot of disadvantages, so just to point out that, yes, to me, the advantages are absolutely worth it. But I can totally understand, if others see that differently.
¹) See, for example, Bevy and this UI example in particular.
Webassemby is still limited to a single thread as far as I’m aware, so it’s not a full runtime for the language you are writing in as anything using threads behind the scenes tends to fall over unexpectedly at runtime.
Its also an absolute bastard to debug (young ecosystem)
Yeah, I doubt WebAssembly when executed in a browser will become multi-threaded anytime soon, since JavaScript is single-threaded just as well. If you need multiple threads, you need to use web workers. Haven’t done anything with those yet, but I’d assume them to be usable from WebAssembly as well, since the whole JavaScript API seems to be accessible.
Well, and in Rust, I’m pretty sure the runtime that’s typically used for async stuff (
tokio) will produce a compile error, if you try to enable the “multi-thread” feature flag on the WebAssembly target.
But yeah, might be more of a problem with other languages.
JavaScript doesn’t suck and it’s performance is more than adequate for most applications. If you are doing some serious number crunching you might want to look at web assembly, but last time I checked it doesn’t actually have access to the DOM so it’s not really got any control over the page itself.
JavaScript is great. Typescript is better. Give JavaScript a go and if you want more safety try typescript.
I personally use the Vue framework for my web apps but there are many others out there, and if you really want to keep things clean you can opt out of using Frameworks altogether.
Anyway, you are never going to be able to completely avoid JavaScript no matter what approach you take, so if suggest learning some and making up your own mind
Do you know how you make good web apps with good performance? You don’t listen to people whining and bitching about a language, you go out and start coding something and find out where the actual issues are.
Javascript / Typescript is great. There are little annoyances here and there, like with literally every single language, but anyone who says it sucks overall is a quite frankly, a moron.
Our project focuses on advanced and experienced computer users. In contrast with the usual proprietary software world or many mainstream open source projects that focus more on average and non-technical end users, we think that experienced users are mostly ignored. This is particularly true for user interfaces, such as graphical environments on desktop computers, on mobile devices, and in so-called Web applications. We believe that the market of experienced users is growing continuously, with each user looking for more appropriate solutions for his/her work style.
Designing simple and elegant software is far more difficult than letting ad-hoc or over-ambitious features obscure the code over time. However one has to pay this price to achieve reliability and maintainability. Furthermore, minimalism results in reasonable and attainable goals. We strive to maintain minimalism and clarity to drive development to completion.
You now what all of this says? It says that they focus on building utilities that accomplish some small technical task and ignore their users’ actual workflow needs. It’s the equivalent of minimalist architects that make unlivable spaces because they’re technically nice.
As a casual js user (I build some static sites for fun and personal use), I am under the impression that JavaScript “sucks” mostly because some things really make it look like JavaScript was invented as a quick scripting tool rather than the backbone of the WWW.
I’ll bring an example that maybe helps me learning someting. Why in javasctipt “1” == 1? I know the === operator exists, but why isn’t the default behaviour the safer one? Especially when the mantra is “don’t trust the user”.
Like, I get, I am a strongly-typed guy, but I see why weakly-type languges exists, but this feel frankly moronic, and all the answers I’ve seen are " because that’s how it is". That’s just copium.
Also when I tried to compile a single Cordova app to play around I needed some 5GB of npm modules that totalled ~200k files! Is that how modern app development is like?
Also, the particular webpage OP linked might be a little extreme, but modern software does suck ass, and is not user-friendly nor efficient. Just look at mobile communication apps, like Teams. The user experience is terrible, the UI is unrespive, the battery drain is crazy and it takes 800MB of space. Is this because it’s an electron app, or because it’s made by incompetent programmers? I don’t know, but we made incredible hardware improvements in personal computing, new software should be even more efficient and use them better, not get more and more bloaty to have the same experience on older and newer hardware
As a casual js user (I build some static sites for fun and personal use), I am under the impression that JavaScript “sucks” mostly because some things really make it look like JavaScript was invented as a quick scripting tool rather than the backbone of the WWW.
I’ll bring an example that maybe helps me learning someting. Why in javasctipt “1” == 1? I know the === operator exists, but why isn’t the default behaviour the safer one? Especially when the mantra is “don’t trust the user”.
Like, I get, I am a strongly-typed guy, but I see why weakly-type languges exists, but this feel frankly moronic, and all the answers I’ve seen are " because that’s how it is". That’s just copium.
Like, you’re not entirely wrong here. The == vs === is entirely just a legacy of a poor early decision in the language’s development.
However, the reason that it’s still there isn’t just “because that’s how it is”, it’s to maintain backwards compatibility. You could break the language and change your equality operators to something more sensible, but to do so would result in:
- A) If you make a new language that compiles to Javascript (like Typescript for instance), you can maintain compatibility, but you do now need to build a bunch of tooling around compilers and debugging so that you can trace errors in the compiled and running javascript back to your own code. In any situation where you have a codebase that contains a mix of the two, you’ve got to remember and stay on top of which to use where.
- Or B) If you make a new dedicated language that runs in browsers, now browsers need to ship two engines, one for legacy javascript web sites and apps, and one for whatever your new language is. Same issues with mixing legacy and new code.
OR the real answer is C) devs just add linters that check your code for common mistakes. All modern javascript dev environments will include a linter that yells at you if you accidentally use the == sign, right in your IDE as you type it, making it not really a big deal, and autocomplete will automatically use ===.
And maintaining backwards compatibility for the Internet / World Wide Web, is probably the single most important place to maintain backwards compatibility, as it is effectively a continuous archive of information and publications. Putting up with === is honestly not that big of a deal in the context of all the above.
Like, I get, I am a strongly-typed guy, but I see why weakly-type languges exists,
I got my start with Java and C#, then Python, then Javascript, then Typescript / etc. etc. Trust me, I vastly prefer a good type system, which is why I use Typescript for everything I can these days. It is still technically weakly typed in that you don’t get type errors at runtime, just at compile time, but it still makes coding in javascript soooo much nicer and more pleasant and more predictable, and it’s quite frankly the most flexible and easy to use Type system / syntax of any language that I’ve used.
Also when I tried to compile a single Cordova app to play around I needed some 5GB of npm modules that totalled ~200k files! Is that how modern app development is like?
I mean, Cordova is not just a web app platform. That’s including the toolchain to build a web app, but also do compile it into an Android app, or to compile it into an iOS app. You’ve basically got large chunks of the android and ios sdks in there.
Also, the particular webpage OP linked might be a little extreme, but modern software does suck ass, and is not user-friendly nor efficient.
Just look at mobile communication apps, like Teams. The user experience is terrible, the UI is unrespive, the battery drain is crazy and it takes 800MB of space.
Yes, because of corporate practices that prioritize feature development instead of addressing tech debt or performance. But that’s not always the case. I worked at Meta for a stint as a contract developer, I’ve seen how they make decisions and they’re not uninformed. They will run A/B testing on simulated apps to measure exactly how much of a difference performance makes, and then balance that against the effort it will take vs the effort it will take to develop new features and then they prioritize accordingly.
No where else I’ve worked does that. Everywhere else just hears a customer or executive yell for a new feature and then the PM just starts working on it without proper research or without giving team’s time to go back and address tech debt.
Is this because it’s an electron app, or because it’s made by incompetent programmers? I don’t know, but we made incredible hardware improvements in personal computing, new software should be even more efficient and use them better, not get more and more bloaty to have the same experience on older and newer hardware
Given that VSCode is made by the same company, is also an electron app, and is generally remarkably performant, I would posit that teams is made by worse programmers since it’s a less attractive product to work on, and the team is probably less user focused since users don’t buy their software, the users’ workplaces do.
VSCode is remarkably performant? For a text editor? Maybe compared to other Electron apps, but not for a text editor, I mean compare to Geany (let alone vim, neovim or Emacs). They had pretty much same useful features before AI assistants
For an IDE.
I can configure VSCode as a full IDE for say C#/.Net development, and it performs pretty much just as well as VS which is written natively.
Ditto for configuring it as a Python IDE vs PyCharm, ditto for Java and Eclipse, ditto for basically everything else.
And I’m sorry but I have to respectfully disagree here: VIM / Neovim / any purely text based editor has never had anywhere near the same feature set as VS Code + it’s extensions. They are more performant, run anywhere, and can be configured to be quite powerful, but they’re still fundamentally hamstrung by using a typewriter’s line by line interface rather than being able to easily draw arbitrary 2d or 3d graphics and use the power of CSS styling.
Like, just drawing out a list of items, and then being able to get more detail on one of those items, is fundamentally a pain in command line, requiring a list command and then an item detail command or a list verbose command, where is in a GUI you just list items and can then expand them or hover on them for more info.
You can always write native apps or use rust. I don’t recommend doing that unless perfectionism/being esoteric/learning is more important to you than just making the webapp.
The main issue with fb/TikTok is the 9 billion trackers and ads. So step 1. Don’t do that.
Svelte/SolidJS are smaller/faster than react/ vue. React has the most tutorials, but I think vue is the easiest to learn.
Next, while working on your app (probably all of those use “vite” instead of web pack by now) meticulously watch your build size. Avoid installing giant dependencies if you can. If you have lots of options, pick libraries that are tree-shake-able. rollup-plugin-visualizer will help you visualize which Javascript file(s)/ dependencies are big. You’d be see surprised how many webapps that is basically 10kb of functionality ends up being 1MB of Javascript.
If your webapp is small you probably don’t need to think too much more about this, but you could probably ask others to critique your code later.
HTMX might be appropriate for your usecase
