re: A JavaScript-Free Frontend VIEW POST

VIEW FULL DISCUSSION
 

You are right that having no exceptions is good... if there are no bugs. 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.

 

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.

 

By "mistyped HTML tag" I don't just mean broken HTMl, but also cases where an attribute was misspelled, or when an element was used incorrectly.

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.

Not necessarily. A non-existent attribute isn’t gonna be caught as easily as as trying to read a non-existent variable.

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'.

That’s his own fault for not checking the event handler to begin with.

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

The attribute where it went wrong might not be obvious.

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.

 

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.

 

Simple: Do not use libraries with too many sub-dependencies.

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 todomvc.com 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 never claimed to have experience in writing JS libraries or frameworks, and there is absolutely no reason to write one just for a simple web app.

And yes, I have heard about leftpad.

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.

I am sorry that you are annoyed, but I don’t feel I need to write 3 paragraphs to explain my point.

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.

 

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.

 

Well AFAIK you aren’t told, even in the console, whenever there’s mistyped HTML. So while you are mostly right, I still think there should be an error or warning when something’s wrong.

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.

I’d prefer a best-efforts approach with a console error, which I wouldn’t consider hidden, just placed where the average user wouldn’t find it.

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.

You can filter console output, atleast in Firefox.

code of conduct - report abuse