Hacker News Reader

Comment by bernawil | Hacker News Reader

  They're forms that submit stuff to a server and get a response

What kind of response? Asuming no React,

a. json

b. SSR-html?

If,

a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that.

b. You'll be merging your server-rendered html to your current view. Re-binding event handlers if you've got any interactive stuff (e.g your SSR came with a modal link) and god knows what else.

React is a million times better than this.

View on HN

I just use vanilla JS. For transport I use JSON over Websockets (with fallback to long-polling if the user is behind a proxy that doesn't support Websockets). I format the messages like id+command+json-payload. If the message contains an id, it calls the callback function given by the API request. If no id is given, the event listeners for "command" are called. In a higher level there are more events that can be listened for.

For layout I use a mix of both pure and imperative functions that either creates a new element for every state, or modifies existing elements - however all isolated in a component or widget.

I try to use standard HTML5 elements rather then creating my own. But they are often inside a component or widgets which takes care of events like keypress, mousedown etc.

There are no string templates! No server rendering, just API endpoints. There is no JQery, there is no framework - besides the functionality for handling server messages and passing data to event listeners and callbacks. Some components and widgets are generic and can be reused in other projects. But most are specific to the app itself.

The advantages is that it's simple, fast, and customizable. The disadvantage is that layout is a bit tedious using appendChild instead of XML/JSX.

I use CSS for styling. I like CSS very much probably because I used to do web apps before CSS existed. To change theme you just change the .css file. Components, widgets and elements are not aware of theme and style, that's all handled by CSS. Animations are handled by CSS, and different screen sizes are also handled by CSS. Sometimes you need to the change components/widgets though.

The only advantage I see with frameworks is that you get to write XML/JSX/HTML, which makes it more easy to move things around vs just using JS functions and appendChild. But when looking at React apps the components are broken down into individual files anyway, so it's difficult to get an overview.

Probably the biggest advantages of going vanilla JS eg. no JSX nor frameworks, is that debugging becomes easier, and you do not need a build pipeline, just refresh or hot-reload individual functions. No bundles or package managers needed.

That sounds like a great framework. Let us know when you release it. :)

The points made elsewhere in this thread still stand: a bespoke framework might be conceptually simpler and much easier for a solo developer, but for larger apps that require a team of developers using a popular framework would be much more productive overall, as everyone is or should be on the same page with how features are implemented. This often results in poor UX where specialized knowledge about the framework is needed to improve performance and scale, which you as the author of yours know by heart and find it much easier to achieve similar or better results.

I'd say neither approach is inherently bad. Use whatever delivers the best UX for the project at hand, but know that you'll be paying a price when that approach reaches its limits.

For short living projects, say two moths or half a year, I would probably go with an existing framework, for that initial speed and reuse of existing libraries/plugins. But for anything you would spend one year or more on, I would build a custom solution which optimizes for whatever is the domain priority, for example front-end performance, speed of development, etc. If you use your own "framework" it will become stable over time, where as a popular frameworks like React or Angular will just keep changing and eventually reach end of life support.

You forget the most basic response. A full HTML file with a corresponding reload. None of what you said applies. I'm a big react fan and advocate too but sometimes I think we forget about the basics.

First time I hear XMLHttpRequest was a mistake.

No one is going to sit through a full-page reload on every form validation.

Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.

> No one is going to sit through a full-page reload on every form validation.

Why not? Most of the pure HTML forms I use load at least an order of magnitude faster than the complex SPAs I use because there's so many fewer network requests. You can make SPAs which are as fast but I'd say fewer than a third companies, even very large ones like Google or Facebook, succeed at doing so and an even smaller percentage have thought hard enough about error handling. On a daily basic I use sites from Google, Twitter, Facebook, etc. where I have to do a reload anyway because their developers were unaware that network operations require timeouts, retries, and that you need to provide UI feedback for all of those to match what the browser provides by default.

EDIT: to be clear, I like that we can do a ton of very complicated things in a browser now — we've been working towards that as an industry for the last 3 decades and it's great that it's largely arrived — but I think it really hits the failure of companies to skimp on resources for anything which isn't critical to the default user experience. Duplicating built-in functionality should be seen as an expensive commitment, not the default unless you're willing to devote the extra resources needed.

I agree with this.

Yes, ideally, a SPA could be better (i.e why re-send the parts of the app that didn't need to change), but most of these apps are actually way slower -- either because the developers don't know/care beteer, or perhaps more probably, are not given the time to implement the perfect(-ish) solution.

A full html page reload isn't much slower than react/redux doing a json fetch, but it may appear so since most of the content doesn't flash, new content comes in with an effect etc. And I agree, this looks more slick.

The irony is you're posting on HN, which does exactly what you suggest no one will tolerate. How slow is this form submission for you? ;-)

Conversely, the upvote button (which I used for your point) doesn’t perform a full refresh. Both are good.

hey, we all love how fast HN loads, not gonna argue!

On the other hand, I don't think it's usable for other crowds. I spend most of my day inside vim, so I'm used to switching windows and going back all the time but I don't think that having to load a submit form in a new page, losing all context of the conversation tree is particularly usable.

Turn off your JS and upvote something. It becomes substantially less pleasant.

Turn off JS and load an SPA :p

Sites or "apps" relying heavily on full page loads are, in my experience, much faster than their "efficient" XMLHttpeRequest counterparts, in practice. As in, click, thing happens, thing is done happening, much faster. We even have examples of this with the same "app"—Gmail, for example: Basic HTML, "mobile", standard, and, though I think it's gone now, Inbox. At least four versions. Basic HTML is less janky than "mobile" on mobile, and much, much faster than standard or Inbox, despite "inefficient" full page loads.

pjax is about a decade old at this point, dirt simple, and easily handles re-binding event handlers. Check it out: https://github.com/defunkt/jquery-pjax

Turbolinks is a more contemporary library that does much the same.

It doesn't need to be complicated.

Reply on news.ycombinator.com