It is hard to avoid JavaScript(alexkutas.com)
alexkutas.com
It is hard to avoid JavaScript
https://alexkutas.com/posts/it-is-hard-to-avoid-javascript
85 comments
Or maybe the junior engineers grew up with JavaScript, loved it, and have been driving the actual seniors who grew up with strict typing and predictable behavior insane.
I would not be surprised if JavaScript gets the reputation of 2012 PHP in a decade.
I would not be surprised if JavaScript gets the reputation of 2012 PHP in a decade.
I feel 2012 PHP is the perfect description for JS reputation today and I've been working in companies where they do node.js as main backend tech since 2011 and react since 2015.
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.
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.
I also mean it in the sense of 10 years from now.
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.
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.
Your vanilla PHP will still work in 10 years, with a few deprecation fixes. And since vanilla PHP is such a full-featured language and framework, you don't those third party dependencies.
People were refusing to take JavaScript seriously twenty years ago! Here's something I wrote about that back in 2005: https://www.sitepoint.com/2005-the-year-of-the-dom/
> Or maybe the junior engineers grew up with JavaScript, loved it, and have been driving the actual seniors who grew up with strict typing and predictable behavior insane.
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.
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.
In 2012, PHP was already going through a renaissance. PHP 5.4 had come out with massive improvements and the release cycle for updates was accelerated. Composer and Laravel were released and people were not only building real apps with PHP like they always did, but they now had much better tooling, language features, and a more thriving ecosystem.
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.
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.
In the bell curve meme you're that sweaty geek with glasses in the middle.
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 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.
There's no reason to insult people - programming languages, on the other hand, can not feel emotions. The opinion that JS is "not a proper language" is a little glib, but thoroughly subjective, and taking either stance can be reasonably argued. It depends on the semantics of the word "proper", of course, but JS does obviously have glaring issues compared to some languages designed from the ground up in the 21st century (or even some languages at a comparable level of abstraction born in the 20th century).
In this case I think it's OK to insult people, because when they imply JavaScript isn't "a proper language" they're insulting several million other people already.
A lot of “actshually”.
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.
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.
The problem with JavaScript was never that it isn’t a proper language. The internet is best as a document sharing platform, and the fact that the funny little scripting language to sprinkle into the documents has grown into a fully featured programming language made it worse, not better.
Now only a couple companies can make a safe web browser (apparently, so they claim).
Now only a couple companies can make a safe web browser (apparently, so they claim).
I take issue with “CSS is tricky”. We’ve never had it easier with CSS in terms of browser compatibility, documentation and functionality.
IMO CSS is fundamentally tricky because HTML isn't WYSIWYG by default. In similar document styling systems like in Word or Illustrator, you can graphically alter your parameters and get immediate feedback. In CSS it's often tweaking ambiguous parameters (align vs justify) across several layers (self, items) just to try to position something in a way that would take half a second if it were a good GUI.
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.
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.
This is mandated by responsive design.
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.
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.
Forget responsive design and WYSIWYG... VSCode, Figma, Discord, Slack.. etc.. etc.. can be implemented with html and css and it's a better experience than any other GUI framework for any other platform.
Well, I meant not only all screen sizes but also all feasible window sizes!
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 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.
Why do you believe that (it's a better experience)? Are you talking about for the developer or the user?
So just for context the one's I've used are WPF, UIKit, Electron, and Qt. And using Electron was easiest to develop on for me because the tooling just worked, everything updates instantly in a real running browser environment, and layout was predictable and easy to get it to work exactly how I wanted on actual devices. Is that cause I have more experience with the browser platform? Maybe it is, but that is probably the other main reason people use it. Personally I think the dom and css makes total sense. A tree of nodes where you can address nodes with selectors to style them. Seems pretty ideal, I don't know what I would do differently.
Both.
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?
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?
I would rather know straight-out that a company doesn’t have real native support.
I have used many native GUIs on Windows that looked blurry because they din't get font rendering right and that only work at a fixed window size.
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.
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.
> But I don't understand where the sentiment that native=better comes from.
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.
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.
> But I don't understand where the sentiment that native=better comes from.
OCD.
OCD.
Design tools often have controls on how you can scale a box by locking expansion in different directions and anchoring elements to specific side. Its results in the same thing as flexbox and alignment but is was more intuitive.
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.
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.
>I have been using CSS for 20 years. It’s too difficult for what it primarily does.
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.
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.
I think it's easier for us because we've kept up with small incremental changes over 20 years. To someone just jumping in fresh from school or boot camp or whatever, it's quite overwhelming. We've had the benefit of having mastered the simple basics back when they still were simple, and then gradually increasing complexity on an as-needed basis, every few years at a time. It's different when you're just thrust into it new, with decades of built-up cruft.
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.
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.
>To someone just jumping in fresh from school or boot camp or whatever, it's quite overwhelming.
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.
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.
> The real issue with CSS is the eternal question of, do I fill my parent or expand to fit children?
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
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
This is because of what we have today, it's not how it needs to be.
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.
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 two aren't mutually exclusive (responsive design and GUIs). Winforms was responsive long before HTML. Dreamweaver was OK at responsive layout shifts in real time. Figma handles it OK too. Even the browser inspector with hot module reload can do the job.
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.
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.
Fair point. There surely is a space for new tools of this kind.
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.
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.
It has got a lot better now with flex and other new functionality, but before it was definitely very tricky.
It is actually amazing how much can be done with vanilla JS without fancy frameworks.
Frameworks generally don't enable you to do something, they provide a framework in which you can do something you already could, but in a way that's more organized, efficient, extensible, robust, and/or stable. I.e. they enforce rules. You can come up with those rules yourself and follow them ad hoc. All the framework does is programmatically enforce them and abstract away boilerplate (e.g. "define X as a function of declarative state" is a common one, like React for UI).
Why is that amazing to you? Frameworks are just vanilla JS wrapped up in specific functions to that framework that do a lot of abstraction level work for you.
Perhaps it's strange to the uninitiated that so many seemingly useless/redundant abstractions exist around something that seems pretty capable of doing the job without a bunch of handwaving. If you never worked with the DOM in 2012 and had a need to support every browser out there, you'd not understand the pain that was involved.
It only seems capable due to those frameworks and abstractions. At the end of the day, there are only so many builtin types and functions on the core runtime. Everything else is up to the ecosystem to provide. Just like C or C++, at it's core, it's just a basic language for things. It's the libraries of code from others that give it [more] powers.
> It only seems capable due to those frameworks and abstractions.
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.
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.
NodeJS is a framework. It adds to base JavaScript API’s for working on the system side. It’s an abstraction (albeit, additions) that give you more functions.
> NodeJS is a framework.
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.
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.
The one thing that I thought was a pro for frameworks were all of the compatibility tricks they abstracted away. It allows for your code to be cleaner by not having to constantly use if branches testing the user's browser. It meant that the frameworks update kept up with any new quirks freeing me from constantly researching them and updating my code. My code can stay the same, and my project stays up to date with those quirks by updating the framework.
Actually everything can be and _is_ done with vanilla JS. It's just frameworks and libraries that abstract this complexity away.
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.
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.
It is turing complete language. Why would you be limited? You could write anything even with brainfuck.
It definitely depends on the technology, but for a lot of sites JavaScript simply isn't necessary.
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.
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.
> 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...)
From that link: "JavaScript should be used to display the <dialog> element."
From that link: "JavaScript should be used to display the <dialog> element."
Ah that is true. It does make us depend less on JavaScript, although not to the degree I thought when linking to it.
Thank you for correcting me.
Thank you for correcting me.
For all its quirks, JavaScript is an incredibly concise and easy-to-write multi-paradigm language. For banging out prototype code, it's my favorite tool no matter the domain.
Hmm, I think the real advantage is more that you get an advanced cross-platform environment to run it in “for free” – excellent debugger, various ways to do UI, graphics, getting input from the user, etc. For lots of recommended ‘beginner’ languages, this isn’t the case.
Long time huge fan of JS. I appreciate your calling out the multi-paradigm aspect; having these first class functions & prototype based inheritance has been so flexible.
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
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 don’t know - the author seems fairly aggressive in his belief that one shouldn’t question JavaScript. Seems hypocritical.
Elm is the closest we got to usable no-js in my opinion, too bad the excessive centralisation by the benevolent dictator wrecked it
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.
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.
As much as we all use HTML, CSS, and JavaScript; it isn’t 2003 anymore. Most web browsers people use are relatively up to date and automatically updating.
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.
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.
Nobody said "Javascript is the pinacle". But it is extremely difficult to create standards that multiple companies can agree on and want to spend huge efforts to implement and continue to refine for 30+ years. Microsoft tried to make VBScript happen, but nobody else making browsers would ever support it, so it died. And I'm glad it did, because it let everyone focus on Javascript and improving it, hardening it as an attack vector, and creating a huge variety of tooling for every kind of project.
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.
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.
After working with new age frameworks (SwiftUI, Compose, Flutter), I’m rediscovering web development (last time I’ve touched it was more than 10 years ago).
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.
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.
> Maybe there’s a better way than having a DOM in the first place.
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.
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.
I love JavaScript, but that HTMJS page has to be a joke. Putting that much JavaScript inside an inline onclick event attribute is pretty ridiculous. It's like a blog for how not to use JavaScript.
It seems you are right. The blog post reads “I've created HTMJS as a *sarcastic* way to express my thoughts.”
Serious question: why is inline JavaScript like that a bad idea?
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.
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.
If it is actually a simple bit of inline code, then sure. I mean not more than 2 commands maximum. Any more than that should be inside a <script> tag where it's far easier to write and format the code, debug, abstract, and reason about. The huge amount of code in the example on the HTMJS "blog" is just the worst way to write js code into a webpage because it is not a simple function, it's difficult to read, it won't have syntax highlighting because it's treated as a string.
It's properly highlighted in my IDE, which was actually a surprise.
> You can have JS in the way you want, just don't be too aggressive towards other people's choices.
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.
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.
Welcome to Hacker News. Where merely questioning the modern state of JavaScript is a heresy.
The comment is questioning whether the interactive internet, where webpages can be computer programs instead of just documents, is a good idea. That’s a pretty broad claim! Complaining about modern JS is a different story, and it’s a pretty popular discussion point on HN :)
>"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."
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.
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.
> and many smart people concerned with keeping JavaScript safe to run in a web browser.
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.
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.
What should it take? One smart person? A few average people? Do you realize how important web browsers are to modern life? Encryption alone takes many smart people to do right in a tool that billions of people use, so it should be no surprise that many smart people are helping secure, optimize, and extend javascript in such a widely used and universally important tool that is the web browser.
A few talented but not unique engineers should be able to make a web browser. Like a window manager. It is a hard task, but in range of a solid community effort.
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.
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.
>A few talented but not unique engineers should be able to make a web browser.
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. 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.
>> A few talented but not unique engineers should be able to make a web browser.
> 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.
> 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.
Okay, so please tell us what you think is insecure about javascript running inside a web browser?
I made some picture/text/video gallery explorer application with python/flask/js
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.
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 look at all those Tor-compatible websites that have achieved so much without JavaScript, including CAPTCHAs, etc.
`parseInt(c.innerHTML)` and we're hacked... :D seriously though, I know HTMJS is tongue in cheek but don't ever do this if you are a JS dev. innerHTML isn't safe, sanitized, or what you expect it to contain. To the author, thanks for the laugh.
I have had a love hate like most. I have come to peace with it mostly because I know its quirky, and I think once you reach this point you can really do a lot. Reading Mozillas documentation is a huge help though.
I’ve settled on htmx not because I’m anti-JS, but to avoid Node/NPM, build steps, duplication of logic, etc. For me, it’s the ecosystem that’s problematic, not the language itself.
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.
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.
Do you remember when the most widely used web browser supported 2 programming languages? Javascript and VBScript. It didn't work out so well, and everyone making browsers agreed it was better to focus on one language so the browser didn't become an even larger attack surface. Javascript has become highly optimized and very hardened against attacks, and has improved significantly over the years, and if you __must__ use another language, then WASM is there for your needs.
You can use JS to write application that can be used across all major platforms without any changes. On top of that, a lot of modern languages can compile to JS or WASM.
You call that tyrannical?
You call that tyrannical?
JS is the only language that has really fulfilled the dream of being able to run anywhere. Web, desktop, servers, CLI tools, mobile, microcontrollers, you name it.
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.
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.
[deleted]
If you still think JavaScript is not "a proper language" today in 2024 you're giving off serious junior engineer energy.