It is hard to avoid JavaScript
alexkutas.com
alexkutas.com
TC39 has done a great job shaping the language over the years. New capabilities are usually well thought out & integrate well. Async await has been amazing.
The one major miss that makes me so sad and frustrated is modules; js has gotten better everywhere except it's near requirement for build tooling. Being able to throw some scripts on a page and go is still an unparalleled experience in the world, is so direct & tactile an experience. EcmaScript Modules was supposed to improve things, help get us back, but imports using url specifiers made the whole thing non-modular, was a miss. We're still tangled & torn. Import-maps has finally fixed but it's no where near as straightforward, and it still doesn't work in workers, which leaves us infuriatingly shirt of where the past was. https://github.com/WICG/import-maps/issues/2
I've been working with CSS since its invention, I get by OK, I can use it a hundred different ways, but I would never consider it straightforward.
It's powerful, it's evolving, it's useful, but simple it is not.
WYSIWYG is terrible for the web not because of the languages used. It just does not make sense.
And responsive design not only means mobile, it means all screen sizes and includes other factors.
Flexbox is a good example for this.
As a developer you can tap into endless pit of resources for web development.
As a user, you can access same program on all platforms without any changes and continue where you left off, what’s not to like?
Both in enterprise and consumer software.
Yes, they probably weren't holding it right, were written in Java and/or sth else.
But I don't understand where the sentiment that native=better comes from.
I like native applications too, when done well. For example, I still like IntelliJ IIRC, this does use Java for GUI? Also it doesn't use native controls.
OCD.
Some of it is integration, the UI just looks nicer for native apps and the graphical language is the same as the rest of the system.
Some of it is performance, these non-native toolkits always seem to bring along too much junk.
Some of it is vibes, if an organization is willing to invest in a native app, it seems like they are probably more interested in sticking around.
I agree that HTML+CSS is a great GUI framework.
Responsive design as a term has long gone out of fashion.
But I see nothing wrong with its meaning.
I wouldn't mind a GUI where I put constraints to the elements visually and then check the different ratios/sizes I want to support and bam, done.
As a field we're under a general assumption that it makes sense to do visual work textually. Just because WYSIWYG tended to be overly verbose and used by "noobs" that it's not how it should be.
Imagine most people making music by just writing notes and then only playing it back afterwards.
The real issue with CSS is the eternal question of, do I fill my parent or expand to fit children? You have to trace multiple levels and rules, and even then it might be a guessing game. This is because the rules that govern this can change at each level, and that changes how you answer the question.
I have been using CSS for 20 years. It’s too difficult for what it primarily does.
This is one of the real issues of GUI tools in general, not just CSS. You run into the same complexity on e.g. UIKit/SwiftUI (Apple) or any other toolkit that tackles the full complexity of defining UI layouts for any screen simultaneously.
Agree that CSS has a bit of extra cruft due to it’s evolution which makes it more difficult to learn and slower to work in than it perhaps could be if the web standards process allowed pruning features more easily
I've been using CSS since the day it first appeared in IE3 in 1996. "Too difficult" is not at all how I would describe it. Considering how many kinds of layouts need to be created, CSS has performed really well for the task it was designed to do. New features are added every year. It keeps getting easier. The difficulty is in trying to support every kind of device layout, which wouldn't really be any easier in any other layout language.
There is nothing magical about CSS that makes it uniquely suited for responsive layouts, especially compared to print layout software (Illustrator or Word or InDesign have had to deal with many container and page sizes and be able to reflow text between and around them for decades) or other GUIs (like Winforms or the ill-fated WPF, or today's mobile platforms, all of which have responsive layouts) or bespoke UIs like game UIs that have had to support different monitor and window sizes since the Everquest and WoW days and before.
Hacking together a bunch of pixel measurements and percentage calculations and virtual pixels to do responsive layout is just so... unnecessary. Even with Bootstrap or Tailwind, when a lot of it is abstracted away with helper classes, it's still often much slower than defining the same layout in GUI tools with a few simple clicks and drags. Having to try to guesstimate a resulting layout from code is a poor way to lay out visual designs, which is why full-time designers usually use Figma or a similar tool, not just tinker with CSS until it looks almost right.
I don't hate (or even dislike) CSS; it's a powerful tool uniquely suited for the job it was intended for (wrangling HTML "documents" into complex app UIs), but I do wish we had an entirely different workflow that was custom-built to be UI-first and not a paint layer over a hacky XML document... CSS itself has to compete with HTML layout rules, different levels of specificity and overrides, etc. It's a lot of unnecessary complexity that only exists because of history and backward compatibility, not because it was the best design choice overall.
That would have been just as true in 1996. Programming is hard, that's why not everyone is doing it. You can't get someone to code just by dumbing down programming, many people will fail and just don't have the focus, perseverance, or aptitude for it, and that's okay. I can't ride a skateboard without coming close to killing myself, but many people can.
But people coming into it now actually have it easier because all the wonky stuff and been fixed, there are new ways to do thing that are actually much easier than it was in CSS1 or CSS2, or even CSS as it was 2 years ago. The new people learn "best practices" that didn't exist even 5 years ago. And just because a layout or programming language has lots of features doesn't mean you need to use all of them or feel like it's too difficult to know how to use all of it.
>There is nothing magical about CSS that makes it uniquely suited for responsive layouts, especially compared to print layout software
I also have to take issue with this. CSS has evolved quite a bit specifically for responsive layouts. Flexbox is easily the best example of why your argument is wrong. It's been around for 15 years. And quite a bit more has been added to CSS since then specifically to make responsive layouts easier. Media queries for example. And citing Illustrator and Word and InDesign are just kind of nonsensical, because the output from those programs are not designed to be resized at will by the person holding a piece of paper (printed page). I'm not even sure how you can use that as an example except if you're trolling?
>or bespoke UIs like game UIs that have had to support different monitor and window sizes since the Everquest and WoW days and before.
These aren't tools to use for layout, they are hard-coded programs that adapt as far as they can to specific screen sizes. I seriously doubt they would resize correctly for a portrait display.
>Hacking together a bunch of pixel measurements and percentage calculations and virtual pixels to do responsive layout is just so... unnecessary
I'm sorry if you think that's the only way to do responsive layout.
>, different levels of specificity and overrides, etc. It's a lot of unnecessary complexity that only exists because of history and backward compatibility, not because it was the best design choice overall.
You don't need to have different levels of specificity or overrides or anything complicated to use CSS and get a simple page working. These advanced things exist because there are absolutely a million valid use cases for specificity and overrides that don't fit into your narrow view of what web browser should do.
But not having easy drag and drop at the component level, and having instead to cut and paste chunks of code, makes it slower and more error prone in my experience.
All that is needed to build such a tool is available.
I think you are talking about a developer-focused tool you mentioned WinForms.
The largest issue building something like this is probably what the input (widgets/components) and output formats (a layout description to be consumed by some framework like react? or pure HTML/CSS?) should be.
It needs to be integrated with the code, and we're leaving pure HTML/CSS territory here for purely technical reasons.
The web still has no proper native component abstraction.
Outputting pure HTML/CSS wouldn't be very useful to me, but might still be cool to visually design layouts, and be useful in some cases.
Are talking about Javascript or the DOM? I write a lot of NodeJS and since somewhere around v8 or 9 it became pretty nice to use.
Huh, I had no idea.
Sometime around Node 8.x, the async/await functionality in the ECMA spec was finally added to the stable API and I began to enjoy writing Javascript as a result. The language had a feature that was good, but the abstraction did not yet fully support it without a flag. The ECMAScript language is a good language.
I think the problem is not so much about JS as a language, but about the amount of low quality libraries and frameworks that make it more productive.
A lot of what could be static sites use JavaScript.
CSS may be tricky to some (I'm still lost with flexbox), but what I've found particularly helpful is using some already finished CSS stylesheets, then just modify them to my needs. Like PicoCSS, MVP.css and more.
Like the post says:
Sometimes, people get angry at React or other FrontEnd frameworks just because they look scary or too complex. But the reality is, FrontEnd is complex.
I have been avoiding React and similar frameworks with a belief that they introduce complexity, but also that they make the site perform slower, produces less traffic either due to hardware restrictions or download speeds. These are valid concerns to consider. Vanilla JavaScript and so on is already pretty simple, I wouldn't be too opposed to the use of jQuery as it can make some things simpler. But in the same way a few of us avoid front-end frameworks like the plague, a lot of front-end developers choose frameworks due to a lack of familiarity with standard / vanilla technologies.
I think what's even more interesting to note is the support for modals with regular HTML and other such features, so that one can depend less and less on JavaScript. (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...)
Did like the write-up on HTMJS though.
From that link: "JavaScript should be used to display the <dialog> element."
Thank you for correcting me.
I've written JS/TS that has run across so many different runtimes over the years, and it has endured. Dozens of browsers, NodeJS, iojs, Deno, Johnny Five, Rhino, Nashorn, LLRT, React Native (JS Core & Hermes), Electron, and more.
If you still think JavaScript is not "a proper language" today in 2024 you're giving off serious junior engineer energy.
I would not be surprised if JavaScript gets the reputation of 2012 PHP in a decade.
What the hell are you even talking about?
> I would not be surprised if JavaScript gets the reputation of 2012 PHP in a decade.
What year are you from? JavaScript already passed that stage with ES6.
I think it's the result of a mix of clunky tooling (started with transpiling), OSS maintainers who stopped caring and left a broken mess everywhere and lack of static typing (+ dissatisfaction with TS, despite it being the only sensible option for types), the diffusion of JS in uncool corporate workplaces.
I still think both PHP (which I've used extensively between 2006-2011) and JS are fine languages with a few defects.
In 10 years, who is going to want to open up that unmaintained enterprise NodeJS project running on now-ancient Angular or React? Heck, what if it used Vue 2?
It’s probably going to be worse than what editing a decade-old PHP project feels like now. That’s if it even builds with just one year of no maintenance. At least the PHP project didn’t rely on packages as simple as leftpad or is-odd.
I expect JS/TS's reputation to only grow more favorable over time. The pragmatic path of its evolution and the resources invested into improving it over the years have really made it shine.
JS is a proper language. Modern JS is beautiful - and I say that as someone who is Kotlin developer on a day to day job. Sure it has its warts, but you need to take into account its age and how widespread it is.
Now only a couple companies can make a safe web browser (apparently, so they claim).
I think you should always use JavaScript, unless you are NOT IN A WEB BROWSER. In that case virtually anything is a better programming language. JavaScript is a 1,5GB of RAM consuming to-do application that would take 100MB if built with native frameworks. JavaScript wastes so much energy on this planet that it's the second most energy wasting technology after crypto.
I wish I never bitched about PHP in the 00's if I knew it would be replaced with this 5000+ dependencies for "Hello World" JavaScript hell.
I'm betting on a Rust framework (leptos is pretty nice!) being the next shot at the problem, but nothing with wasm as bundle size actually matters.
This also means… we aren’t necessarily stuck forever with HTML, CSS, and JavaScript. We could make a new scripting language. We could make a new markup language - or, better, explore different paradigms that might be more suitable. Maybe there’s a better way than having a DOM in the first place. We’ll never have that discussion though if people are forever convinced of JavaScript being the pinnacle.
I say this as a person who is more willing to question whether ridiculous levels of abstractions means the underlying technology perhaps needs changes.
I can’t believe how far modern web jumped. Development process, modern ES features, reliable CSS, amount of learning resources.
I will never understand why would you sacrifice all of this for something like Compose/Flutter, with their janky web performance, clunky, baroque toolchains and nonexistent (compared to pool of JS developers) mindshare.
To start with Compose you need to:
Install Java
Install Intellij
Somehow generate working project
Wrestle for half a day with Gradle
Search for ever changing APIs or updates
Find a way to reference html and CSS
Somehow connect all of this together and finally launch in the browser
After that - good luck debugging black box generated by Kotlin compiler
And now compare this to JS/CSS/HTML:
Most likely you already have modern enough browser
Create file wherever
python3 -m http.server
Done.
Web browsers that don't use HTML, JS, and CSS simply wouldn't be web browsers, that would be something else entirely. And anyone is free to try to make that application using any tech they want, but it won't be widely adopted or supported the way HTML, JS and CSS are.
I was just creating a UI with IMGUI library and found it immediately more pleasant to work with. No DOM, no CSS, no HTML. Just C code with a small number of low level abstractions provided by the library.
Also, “just learn JS” is a lazy and off-the-mark response to complaints about having to use JS. Do I prefer Python? Yes. However, I’ve pretty extensively learned and used JS, and I teach a full-stack JS bootcamp. I still think insisting that everyone has to write lots of JS __just_because__ it’s the language that got integrated into browsers is a bit tyrannical.
You call that tyrannical?
It's easy to find the code that does something, easy to understand what it does and easy to modify it to do something else.
Sure, I wouldn't want to maintain an app with thousands of lines of HTML and JavaScript that works like that, but for a single simple feature on a page that isn't doing anything else I don't see the problem.
all the HTML is generated with python and transferred with ajax calls. it's inefficient, but it works well and it's easy to maintain.
there is as little js as possible
I pulled my hair figuring out those pesky async js things, but I'm happy, it works well.
I would gladly use Typescript if I could use it without nodejs, I guess there might be a typescript compiler for python?
Anyways I am glad I was able to take advantage of js while writing as little of it as possible, it feels like a big achievement.
I think there is never really an excuse to be “too aggressive,” the most strenuous opinions can be expressed without threats of violence or slurs for example.
However, people who develop websites that require JavaScript are contributing to this absolutely terrible ecosystem where people just download programs from the internet as a side effect of browsing and run them without even knowing it. That’s wildly insecure as a ground state.
To try to push things out of that wildly insecure ground state, the convention has been to create these very advanced sandboxes. Putting aside the fact that they fail fairly somewhat regularly, only three companies have had success in this endless battle. Apple and Google, by dint of having infinite money to throw at it, and somehow Mozilla using magic.
As a result of the fact that making a web browser now requires constant security fixes, no small organic community projects can create a web browser. We’re living in the failure-state of the idea that the web should be this open standards-based platform.
So, yes. I get that people have to write JavaScript to put food on the table. But it is a choice that has been made at the expense of the rest of us.
This is why that comment is getting downvotes. Javascript running in a web browser is probably one of the least insecure ways to run code that exists. It's been developed for almost 30 years to be secure, an attacker can't just do whatever they want on a system, there are many safeguards, and many smart people concerned with keeping JavaScript safe to run in a web browser. It isn't the same Javascript that it was 20 years ago so the "insecure" argument sounds like you really haven't kept up with the evolution of JS and web browsers.
It is possible that that is why my comment is getting downvotes, but if that is the case, I think it is not a great defense; I think I handled it pretty well in the next paragraph.
Many smart people shouldn’t be wasted on such an impossible task, and it shouldn’t require many smart people to start a little web browser.
The fact that the WWW is an important communication network means that it should not be difficult to make a tool that accesses it. It is bad that almost everybody’s access to it is gated by a massive ad company.
From the ground-up? No. They stand on the shoulders of many, many smart people. Countless.
In your scenario are you expecting them to write an HTML layout engine from scratch, their own javascript interpreter, and CSS engine? Would they create their own SSL encryption libraries too? And all the code in between for image, video, and audio playback?
Sure a few talented coders could import a full web browser engine that already does all that, and slap some buttons on it and call it a day. I'm not really sure where you're trying to move the goalposts to, so please define where you think the goalpost is.
>The fact that the WWW is an important communication network means that it should not be difficult to make a tool that accesses it.
Making up your own facts? The "WWW" is a very generalized way to call something that encompasses many different technologies. The "WWW" sits on top of the HTTP protocol, which sits on top of TCP/IP, which sits on top of various hardware layers, etc... So which part of that is supposed to be so simple anyone could recreate all of it??
The HTTP protocol is as simple a part of any of this as it gets - you do know how to create a full HTTP request yourself, don't you? All the headers? The exact byte sequence needed and the right carriage returns in all the right places? Sorry but "WWW" doesn't get any easier than the HTTP protocol, and most people - including programmers - don't have a clue how it works.
>It is bad that almost everybody’s access to it is gated by a massive ad company.
Except that isn't at all true. People are free to use the services that they want to, including install whatever web browser they want. Nobody is forcing them to use Google's Chrome.
> From the ground-up? No.
I agree, projects should use the abstractions and libraries that make sense.
The rest of your comment seems based on the idea that I think people should not do that, which would be very silly, so I’m not sure it is worthwhile to respond point-by-point.