Hacker News Reader

Comment by superkuh | Hacker News Reader

>Or consider not using a framework at all. For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.

This should be the takeaway from the article. There's absolutely no need for javascript on most websites that use javascript. I understand if you're forced into it by the time and economic contingencies of your work but if you bring JS frameworks home to your personal sites you're doing it wrong.

View on HN

Exactly. I avoid JS as much as possible. Unfortunately most of web developers want to develop SPAs regardless of the actual need of the projects.

I prefer the MPA (multi-page application) approach for most projects. If interactivty is needed, I use REST services and a data-binding framework on the front end.

That's very interesting - I use a similar approach. In my case, it wasn't deliberate. It came about from working on a variety of projects with management that had unclear and frequently shifting requirements.

A monolithic SPA approach turned into too much work when you'd have to throw out a bunch of code one day, replace it the next day with something just similar enough to cause a bunch of refactoring and bugs, etc.

In that context, it's easier to treat each page or major component as its own mini-SPA, then glue them together with a bare minimum of code.

For the same general reason, and to echo other comments, I recently chose Angular over React (or Vue) simply because Angular has a lot of built-in functionality that helps prevent a downward spiral of dependency maintenance from third party libraries and plugins, even if it's a little slower overall on many benchmarks.

This is the first time I've seen the "MPA" phrase used like this, but I think this is my preferred approach too.

Same, as a user I like the feel of going to a separate page.

Can you recommend any such frameworks?

Stimulus is is a pretty good example of a simple JS framework that binds via data attributes. It, coupled with Turbolinks or Pjax, should let you do nearly anything you'd typically use a more popular front-end framework for, for much cheaper. Check it out: https://stimulusjs.org/

Thanks, that looks really cool.

Knockoutjs works well for this, have heard vuejs is similar but haven't tried it.

That's for highly interactive pages of course, for simple pages that just need some regex validation or something, no framework is the best framework.

I find JavaScript (especially React) to be an awesome template framework for non-SPA websites. I've used it in situations where I'm just creating server side template components. The JavaScript ecosystem can be extremely enjoyable for fast development.

Saying you have SPA experience with the latest frameworks makes it easier to get a job.

I understand. I just do not accept the incidental complexity and performance tradeoffs these SPAs mean. I have built several of them over the last couple of years but still like to avoid them as much as possible.

SPA building experience, coupled with popular JS frameworks, sells usually better than the skills of carefully engineering solution for the task.

These "carefully engineered solutions" typically aren't - and instead random js bolt-ons to whatever server side language. UI state is smeared across layers, and ability to test, share and modularize suffers. SPAs usually are better engineered UIs than the alternatives.

Do you have data to back that up, or are you speaking from personal experience? I know how it can go wrong, but SPAs can become a mess too.

I had one project where we built a very beautiful, modern site that had about 50 lines of js in total. Of course your page-change times are going to be around 0.5s with an MPA, but SPAs are often slower than that anyway.

I don't know but with a service worker you could possibly reduce that 0.5 in your MPA further by caching likely next pages ahead of time.

Yes, mainly personal experience. SPAs can definitely be a mess too. Mostly calling out that managing state in one place makes unit testing easier, which usually results in a better quality codebase

The backend has to handle all of the scale. That's where the real difficult engineering comes in and if you're using JS there, you're going to pay a huge price. It doesn't seem like many front-end JS developers understand that pulling data from different places isn't actually a hard problem but instead correctly storing and managing that data at scale is where the actual engineering happens.

State management is hard. That is the core issue.

Note you can still use an MPA and have a dynamic UI using React/Knockout/whatever. It is just usually not done that way and most go full SPA.

As opposed to spas that take forty seconds to load on a 48-core machine with a gigabit link? Yeah...

Well in a way it makes sense. Its like learning any other technology stack. The core stack may not be the best fit, but its considered a better bet to hire someone with experience in the target language/stack because the learning curve is reduced.

AKA, a developer that knows the same framework your app uses, only has to learn about your specific application rather than all the background libraries/etc your using. Its the same reason for preferring a C programmer for a C position over a ruby programmer (or flip it). Sure the ruby programmer might be awesome and after a couple years more productive, but in the meantime they will be making a bunch of newbie C mistakes, and generally bootstrapping slower.

This is part of the reason i'm in favor of generally reducing the number of languages/frameworks in general use. Its better for everyone if we all agree on some simple baselines even if they may not be the most optimum for any given problem. The efficiencies of repeatedly avoiding a bunch of rookie mistakes (and then having to debug/fix/test them for the next few years) is well worth it in the long run.

Resume driven development works. Unfortunately.

If your site can render without javascript, it can render without ads.

Some sites explicitly don't want that, unfortunately.

Why is JavaScript required for ads?

It's not. It's required for tracking.

I run several websites where advertisers pay to be on the website so that their brand can be associated with the content, and get viewed — just like a billboard or a TV commercial. None of them have Javascript. They're just plain images and links.

You don't need javascript for tracking. You could just use an invisible pixel.

Some advertisers don't like to trust hits if they can't verify the hit came from a real, live browser. Like the difference between the original recaptcha (read the letters in this image) and the new ones (mouse, keyboard, and browser behaviour looks like a human browsing on a real browser).

In an absolute technical sense of course it isn’t, but virtually all the major players in web ads (Google Adsense etc) typically use JS to ship ads/tracking to your page.

It is not strictly required, but most ad networks want to know about you as much as possible, from display resolution to browsing history (if they can). This requires JS.

Also, a lot of ad content is "rich", animated, etc, also scripted.

In 1990s and early 2000s ads were mostly just images ("banners") served by an ad network, or even text links, without any scripting.

Because most ads are auctioned at the time the page is loading. The clientside scripts identifies the user however best it can and then contacts ad delivery networks to see who is willing to pay the most to place the ad (this is second hand recalling, I might be wrong)

The problem I have is that my UIs generally end up with complex requirements. At first, it's just a standard CMS-like site with relatively static content. Then they want discussions. Then they want live discussions. Then they want the ability to highlight sections of the article and hang running side-conversations off of those... etc... Without using some kind of front-end framework, I end up organically evolving my own to tackle the increasing complexity of the UI. Now, I've got UI logic spread across two layers: my back-end (Rails or whatever) and in my front end (my hodgepodge JS), both of which need to dynamically render / update markup-- at which point I wish I'd just gone with an SPA framework in the first place.

See, that's the point where I usually wish I hadn't used a framework. As your design gets more and more convoluted, the amount of switches, toggles, and special cases that you have to build into the widgets tends to balloon. Most current frameworks make that an exhausting exercise in state drilling, and it becomes hard to reason about how any given change in application state will affect the view.

Its not just that, but due to the difficulties of getting CSS to do what you want, it seems standard practice now has everyone using JS for basic layout/update tasks. Back when I was doing a lot of web development getting something sitting in the right place with CSS frequently took me much longer than just writing a bit of JS to adjust the size/position, but the results with CSS were much faster to respond.

CSS is easy to use today in comparison to what we had 10 years ago (float based grids, clear fixes, arcane margin collapsing rules). And yet sites managed to do their layout without requiring a javascript framework.

I hear you about CSS historically being a PITA. In my experience (web-related dev and arch since 1998), modern tooling, CSS-in-JS and component-based UI makes the DX so much nicer than it's ever been. My current project uses react, emotion, tailwind, autoprefix and postcss, and it's intuitive and efficient.

The big challenge for this are different screen layouts.

Mobile + desktop support is basically a hard requirement. A tablet-optimized version is nice to have.

This gets very hard to do well with just CSS.

Not true. Check out CSS media queries.

I'll second this. FlexBox + CSS Grid with the appropriate media queries can handle just about every layout configuration you can throw at it.

When i checked those, searching uncovered statements that most smart phones are lying. Which would explain why my tests never worked in my phone.

Maybe I've been led astray, but from what i gathered about a year ago, media queries cannot distinguish between desktop and phone, you need JS to do this.

Please tell me I'm wrong about that (at least, if you give me a hint on how to do it).

Media queries combined with the viewport meta-tag solves your problem.

    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

Using that meta-tag, phones will respond to media queries around 240-360 pixels, depending on their screen size.

I like to use bootstrap to not be bothered with media queries myself. But I only use small parts from bootstrap, and I opt-in/opt-out from specific parts by removing/adding includes to specific modules from bootstrap. (you can do that with the LESS or SASS version of the package, copy the generic "imports" file, and comment-out everything you don't want/need)

Bootstrap includes many sane defaults and some fixes for weird browsers. By choosing what to include and what not to include, I can choose whether I want bootstrap's opinionated styles or my own, and I can switch later (start out with bootstrap forms, customise them later & finally remove bootstrap form styles)

You're right, but often your problem is better served by a different strategy, because doing web design based on device type is kind of unsustainable.

you are right. Css media queries are for viewport's resolution and some simple "media" types. Device type determination requires calculations on string (user agent). you cannot determine what devices are with css only. But a backend can. You can divide your app and serve seperate designs by user agent etc.

And grid for repositioning blocks

Yes, we were targeting mobile/tablet devices at the time too (well bolting on to existing code base). For example, the CSS to dynamically swap between a side menu and hamburger button wasn't complex (as well as a few other layout changes we made based on screen size), but getting everything to resize properly had a significant/constant overhead during development. Mostly because any given solution took hours to work out.

The alternative of feeding separate style sheets makes it easier to develop, but much harder to test even with the responsive design buttons in ff/chrome. That is probably also why I haven't seen many web apps that try to do everything with a single set of CSS pages recently.

So is it time for "CSS libraries" (pls no, though)?

Why do you think so many developers use things like Bootstrap, Foundation, Bourbon, Bulma, etc as starting points and languages like LESS and SASS to keep it modular/readable/maintainable? We've had CSS libraries and frameworks for years now.

> This gets very hard to do well with just CSS.

This was once true, but not anymore. Grid and flex coupled with media queries solve this problem almost perfectly.

Or you could just not care about mobile's inadequacies. That's one of the joys of making personal websites. You get to do what you want not what's required to make the most money.

Amusingly enough, his charts & images don’t display without JavaScript. Are they interactive, or is he himself using JavaScript when a simple img tag would suffice?

It's probably because his blog is hosted on Medium.

Blame Medium. Why do people even use this pile of garbage?

* Slow

* Bloated

* No images if you block cookies or js

* Paywalled. Asks for $5 membership every other day. Requiring deleting cookies to read articles

* Probably tracks the living shit out of visitors

* Somehow needs a ton of js to render a blog article

* Frequent divs in the middle of the screen asking to create an account

And they don't even produce content. It's all created by users.

I see business opportunity here.

> I see business opportunity here.

Genuinly curious: do you see one without the annoying aspects you described? How would you monetize it?

Admittedly, I don't know of another blog platform without ads. But I haven't taken time to search either.

> How would you monetize it

I wouldn't. Medium solves a non-problem. It only exists because VC funds have this tendency of pouring money over anything that resembles business.

However, Medium isn't too big to fail and I suspect its grace period is long past and now business decisions are mostly driven by shareholders seeking a favorable exit strategy. [1]

[1] https://marketingland.com/medium-will-eliminate-promoted-sto...

But if I really had to come up with a way to monetize Medium, I'd take a look at Wikipedia business model.

Wikipedia is a non-profit. It by definition doesn't have a business model.

And yet Wikimedia foundation reported an increase of $22 millions in net assets in 2016 alone, totaling $120 millions sitting in the bank. [1]

So my suggestion stands: There are lessons to be learned by looking at how Wikipedia manages without ads.

[1] https://annual.wikimedia.org/2017/financials.html

Because people don’t care about those points, it’s easy, and it gets you an audience quickly.

Speak for yourself. Some people do mind shitty websites. That's one of the reasons Medium had to layoff 1/3 of its employees last year.

There is no need to go raw if you can use a library like Preact (3KB) or HyperApp (1KB) and still get the majority of the benefits of using a modern component architecture.

Javascript has specific client side features that servers cannot provide. Good luck doing google maps without JS.

When I browse the web, I disable JS by default. In overwhelming majority of the cases, it makes everything so much faster and nicer.

I don't understand why this point is brought up on HN everytime there's a discussion about JS.

The behaviour of disabling Javascript represents an almost non-existent subset of web users and developers have more pressings things to think about.

I agree. I appreciate that you _can_ disable JavaScript, but I don't really think of it as a realistic option for using the web in 2018, and certainly not for the average user wanting to do average things.

It actually is a completely viable option in 2018 for advanced user wanting to do average things (with uMatrix for example), and it is a nice experience. Agree about average users though.

But considering how horrifically bad things have gotten, maybe we should be making a concerted effort to make it realistic.

Reply on news.ycombinator.com