re: A JavaScript-Free Frontend VIEW POST


True enough, but on the other hand I very rarely find myself with broken HTML. IDEs make it very clear when you're missing a closing tag, or when things are in a different order than you intended (especially with a reformat-on-save feature enabled). In addition, JavaScript stack traces aren't always that helpful, especially when you're using a SPA framework that calls your code, or you use a lot of promises, etc.

In the last year, I can remember maybe 2 instances of broken HTML that took me some time to find, but I run into JS errors weekly, if not daily, where the exception and stack trace are useless and I spend a good 20+ minutes tracing through the code or stepping through in a debugger before I can find the bug.

In general, HTML is significantly less complex by its nature, so there's just less that can go wrong. And HTML validators are pretty solid at this point, and have been for a long time.


Sure, all of the above. Both of those are (again, in my experience) 100x easier to track down and solve than, e.g., an obscure bug caused by mistyping a property name in some callback halfway down an RxJS pipe.

And in fact, both of those can also be caught by IDEs and/or HTML validators, since attributes and elements are standardized, and anyway, the cases where "an element was used incorrectly" will cause significant problems are usually cases that are visually obvious, and thus easy enough to trace, or that cause accessibility problems, which should also be clear enough if you're doing a11y testing in the first place.

Again, it boils down to HTML having much less in-built complexity to it. I think that's the big takeaway from this article: most of the stuff we use JavaScript frameworks to accomplish are not complex enough problems to justify such a complex solution. As the author points out, there are cases where this is not true, and in those cases, sure, sprinkle in some JS. But you can get pretty far without it.


Sure it is. For one, attributes typically have effects that are obvious when missing. For another, HTML5 doesn't allow custom attributes that aren't prefixed with data-, and most HTML validators will catch them.

And anyway, you wanna talk JS, how about mistyped event names? Just last week my teammate lost hours in a weird bug that boiled down to a '$destroy' event mistyped as '$destory'.


I mean, then it would be your own fault for not checking the attribute to begin with. What's the difference?


The same can be said of events. I guess my point boils down to: anything that can go wrong in HTML has a direct analog in JavaScript, and there's a thousand extra things that can go wrong in JS as well.

Congratulations Ken for your patience in this conversation. I am impressed


A mistyped HTML tag is not gonna do much to help you fix stuff, but a call to a non-existent function in JS is gonna throw an exception with that tells you what you tried to do along with a stacktrace. Thus I think that having an exception is clearly better.

That is a strength of html, not a weakness. It's called the "robustness principle" (aka Postel's law). It's the reason the web was able to thrive, and is still thriving 30 years after its invention.

Malformed html, unrecognized tags or attributes, will not throw an exception. The browser will do its best, and in all likelihood, your users will still be able to do their jobs.


Html is entirely declarative, and there are plenty of validators out there, often built right into the IDE.

While I agree it might be nice for browsers to put something in the console when they encounter unrecognized tags or attributes (and I think some of them might already do this), I still think a silent best-efforts approach by the browser is a way better experience for users than a blank page with a hidden stack trace.


That's the crux of this whole argument, though: an unrecognized tag is not an error. Because Html tags are not instructions to be followed like an imperative program. They are semantic expressions of document structure, intended for a variety of potential clients of differing capabilities. Different browsers (and other devices) are free to interpret parts of those declarations they understand, and ignore others. Html documents can be full of tags and attributes, meant for specific clients, in different contexts.

By design, browsers are supposed to ignore anything they don't recognize. If they wrote errors to the console for every bit of unknown content, the console would be very noisy indeed.

This seems to be a hard concept for many to grasp.


Yes, and Firefox also writes warnings to the console for malformed content (known elements appearing in the wrong place, such as putting a tr element directly inside a div), mismatched open/close tags, etc.

So that should satisfy most of your concerns around mistyped html tags. The difference is that the browser won't just stop rendering the page, and in most cases the user can keep working even if something looks a little off.

But unrecognized tag and attribute names should not result in warnings in the browser. The browser has no idea whether these names might have meaning to other clients, and so it (rightfully) ignores them.

You can still catch all of these at dev/build time with an html validator. So there's much less need for console warnings if any kind.

That is decidedly not the case with JavaScript. Your JavaScript may be 100% correct from three compilers perspective, but you don't have complete control over the environment in which it runs (or if it runs at all). Putting too much responsibility on JavaScript inevitably limits the number of browsers your app can reasonably support.

Even those who "only support modern browsers", (or worse: "only support chrome", a super dickish and short-sighted attitude) cannot be assured that their script will always work. Browser plugins, malware filters, etc. can all interfere. So JavaScript needs console errors in order to help diagnose errors in the client. It's essential information.

But you don't really need that as much (or at all) with html.


A mistyped HTML tag is generally obvious, the page will not look as intended. A validator browser extension will double check and help you be more thorough in development.

That's right, calling a non-existent function in JavaScript will throw an error that will be easy to debug. But how does one debug an exception thrown by some library that is a sub-dependency three levels deep downloaded from npm, that you didn't write, is obscure to begin with, and is now minified in your production build? Whether the bug gets solved or not, chances are good that many hours will be spent trying to figure it out. I've been there more times than I care to recall.

Have you ever deployed Bugsnag with your frontend code? Some problems are easily solved, but after a certain point the exceptions become unwieldy, submitted in foreign languages, and exhibit a myriad of other unreproducable issues.


That is impossible in the current JavaScript ecosystem.


It's totally possible. Write your helpers, don't use 3rd party libraries!
You can have templates, module, components even event driven functionality in a few lines of code. Compatible with all browsers and zero dependencies, working in all server technologies, even opening plain html file.
I wrote about that here

Problem: There are too many js libraries, and people use them excessively.

Solution: "Just write your own framework then!"

... wow. You should do this. Please. I mean it. Write and use your own framework and then build a web app with it. A web app that does something, not a app. Report back when you understand why this is a learning exercise and most people use libraries managed by thousands of active users instead of one random dude.

"Do not use libraries with many sub dependencies"

Ooook. Do you actually use NPM? Have you ever? Did you miss the left-pad fiasco? Yes, simple. 2/3rds of the internet went down because managing JS dependency chains is "simple". Words of someone who has never built a JS based front-end.


I already did it. I have production web apps that uses my own tools with almost zero dependencies, just some 3rd party helper components (front end). Are time perdurable, easy for me to debug and very easy to add new features, not having to learn anything new every time I need to apply new feature to my project.

Maybe my short answer in certain context was misunderstood and not explains the intention of my blog post linked.
In my opinion, there's a trend to use the complex frameworks, with more than 1000 dependencies, compilation steps, ... for doing every kind of web apps, including the simple ones. In my experience, the more dependencies and more steps (compilations, …), the more possible problematic situations.

My post isn’t really about creating a React or Angular competitor, is just about a simple exercise to realize that there are some features on these frameworks that can be solved relatively easy creating a simple helper. Maybe you don't need an entire frameworks to just take advantage of 2, 3, or 4 features it supplies. As I said in the post, We don't want to reinvent the wheel. Ok, that's a good point, but a lot of frameworks don't have just wheels, they build entire trucks.

I don’t pretend to write a framework, I only invite to think if with on ore two helpers developed by your own, maybe can solve your problem without the necessity to deal with these complex ecosystems.

Finally, I don’t say no one has not to use frameworks. There’s a lot of situations where frameworks are the best solution definitely. I just say, be sure you really need to use and learn a new tool before going for it.

2/3rds of the internet did not go down. Nothing serious happened at all.

Leftpad was a rather useless package that was included in some other major packages and caused many automated builds to break. No working code was affected and no competent team was using that package directly in their apps in the first place. The underlying was actually about NPM being a poorly designed system that allowed packages to be completely removed in the first place.

If anything, the incident was a good call for better dependency management in the JS community to avoid dependency sprawl and highlighted how important it is to bring a real standard library to the language.

Nothing serious happened at all.

the incident was a good call for better dependency management

Wait I thought nothing serious happened at all?

The entire event was serious and highlighted some major flaws in the way we handle dependencies. You're right, I agree.

I never claimed to have experience in writing JS libraries or frameworks

Please, contribute, but perhaps refrain from comments like "simple: don't do that thing!" Maybe you can see how this could be annoying to some of us.


Write and use your own framework and then build a web app with it. A web app that does something

Of course you realize that every framework out there originated as someone's pet project, someone unsatisfied with existing frameworks, and with a different set of problems to solve.

So yeah, I would absolutely encourage anyone to build what they need. And maybe that's not a huge one-size-fits-all "framework", but a simple set of modules, tailor made for their specific needs.

code of conduct - report abuse