Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Websites have evolved back to static HTML/CSS/JS files

paramaggarwal.substack.com

Post reply on HN
Print view View original

221–230 of 313 posts

Re: Websites have evolved back to static HTML/CSS/JS files

#221

Post by pests »

wyqydsyq wrote: post #148
akiselev wrote: post #99

Earlier quoted context omitted.

Svelte components compile to vanilla javascript plus a small runtime (a dozen or so functions that track state for context and the developer tools). It's much lighter weight than React or Vue's runtime and a side effect is that integrating Svelte components into other frameworks is a breeze (especially if you compile to web components). The author refers to it more as a separate language. I've had a great experience…

> Svelte components compile to vanilla javascript plus a small runtime Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library. The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without h…

Svelte is actually quite a bit different. Quoting a random section from their docs

"[Svelte is a] compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time"

My point being there is a large amount of compile time code transformation at build time. The run time is not so much a framework as a library like libc. In Svelte when you update state there is no virtual dom, dom diffing, fibers, or anything. It would have been compiled into a direct dom update of anything depending on it. It's no longer a Svelte app just vanillajs. There are some details or course but it's a different paradigm than to react or other modern UI frameworks.

Re: Websites have evolved back to static HTML/CSS/JS files

#222

Post by benbristow »

zuzun wrote: post #219
benbristow wrote: post #52

Earlier quoted context omitted.

Twitter's redesign is one of the most performant SPA's I've seen in a while. It's really smooth and nicely designed too. A lot better than their previous webapp.

When I open a Tweet I look at spinner animations for 10 seconds. Scrolling is also the opposite of smooth.

Scrolling is silky smooth for me and spinners go away quickly.

What hardware are you running?

Re: Websites have evolved back to static HTML/CSS/JS files

#223

Post by realityking »

nefitty wrote: post #44
x3haloed wrote: post #26

Earlier quoted context omitted.

It's better than everything else because people have never heard of it. When did software engineers become hipsters?

It seems like a lot of web devs are either stuck chasing novelty or constantly trying to bet on the next big thing. For example, what happened to CoffeeScript? https://trends.google.com/trends/explore?q=%2Fm%2F0hjc5m0&ge... What happened to Ember? https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8...

CoffeeScript largely got killed by EcmaScript 6.

Two reasons why

1) Some CoffeeScript features, like arrow functions and classes, made it into ES6. 2) CoffeeScript was never updated to properly generate ES6. Largely because the features that got adopted by ES6 had subtle differences that made the migration path for existing projects highly complex.

I think, to a lesser extend, the rise of TypeScript also had something to do with it.

Re: Websites have evolved back to static HTML/CSS/JS files

#224

Post by modo_mario »

manigandham wrote: post #165
userbinator wrote: post #123

Earlier quoted context omitted.

My experience with the Outlook web app (not the "basic HTML" mode, which is perfectly usable in contrast) is the exact opposite --- it's extremely slow and consumes a ridiculous amount of memory for what it does (I've seen it take over 2GB of RAM, and this is with an account where all the emails with their attachments total less than 100MB.) When composing a message it lags so much that it will delay each keystroke b…

Unused RAM is wasted RAM. If you don't have anything else that needs it then just let your system automatically handle it. Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.

>Unused RAM is wasted RAM.

Says the OS developer, says the browser developer, says the webapp developer, says the developer of whatever else you have running. Developer time is expensive. Says one. Look it runs fine and is snappy. Says another on his maxed out development pc forgetting about his grandma. Why should i care about that extra memory load when most pc's nowadays have x amount. Says yet another.

And so the slugfest continues.

>Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.

Browser extensions can definitely make a browser sluggish but most don't interfere with the content. The only ones that do AND are common are adblockers which have a tendency of making it less sluggish.

Re: Websites have evolved back to static HTML/CSS/JS files

#225

Post by rovr138 »

wyqydsyq wrote: post #174
rovr138 wrote: post #169

Earlier quoted context omitted.

> building an SPA allows you to build applications as declarative composable functions which are deterministic How is that not the definition of a function or a method? Deterministic in what sense? It’s output? It’s input? Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.

> How is that not the definition of a function or a method? It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery sele…

> The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out.

If you don’t know how your code will work, that’s an issue with the quality of the code.

> What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output.

Agreed.

> Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input,

With a language like PHP, if you call a function twice with the same input, why would the function return 2 different outputs?

> it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.

If your application also does this, the only difference is that you’re not using jQuery for it.

The output of this is deterministic. Given jQuery works, the element will resize and change color.

> In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.

The assumption here is that declarative is deterministic and anything else isn’t and that’s just not true.

Determinism isn’t a function of the language, structure or paradigm.

If something is deterministic is dependent on the algorithm it has.

Re: Websites have evolved back to static HTML/CSS/JS files

#227

Post by terpimost »

jonny383 wrote: post #167

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

So true about a website. The recent time I don’t even bother about hosting, I choose the most simple to manage and teach others. For a simple page there are services like https://tilda.cc . Gatsby suddenly improves Wordpress. And Kontent.ai is just a great editing experience with do_it_as_you_want frontend.

Re: Websites have evolved back to static HTML/CSS/JS files

#228

Post by fukpaywalls »

turtlecloud wrote: post #213
jonny383 wrote: post #167

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

The reason for choosing new technology on the developers part is for job security. If everything were still php you would have outsourced his job to India ages ago. The fact is that the developers need to do this because of the ding dongs mbas in management.

that and the fact that every developer / engineer succumbs to the urge to re-invent the wheel

Re: Websites have evolved back to static HTML/CSS/JS files

#229

Post by krapp »

RandomGuyDTB wrote: post #109
somecallitblues wrote: post #76

Earlier quoted context omitted.

I’m sorry to say this but your site may only be appealing to you. Even though it will render on Commodore 64.

The intent is for users to style it themselves.. or it was, until browsers stopped having that functionality.

Browsers never stopped having that functionality. It's still entirely possible to load custom user styles into a webpage.

Re: Websites have evolved back to static HTML/CSS/JS files

#230

Post by Razengan »

cj wrote: post #160
nn3 wrote: post #151

Earlier quoted context omitted.

>You need experienced engineers to create performance no >matter what your domain is. Actually the funny thing with HTML is that the simplest things are fast. If you just write a old school HTML web page without a bazillion frame works and not going too heavy on graphics things are usually fast. And doing that is literally so much simpler and easier than learning all the super complicated frameworks of the day. So it…

This perspective is reasonable, until you start applying it to highly interactive / dynamic GUIs. Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience. Another example: any page that displays a row/table of data that the user wants to sort (frontend libraries make sorting instantaneous, compared to full page refreshes with html-only). There are lots of people using compli…

> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.

I can’t recall the last time any website offered me an acceptable embedded chat experience (not counting dedicated clients like Discord) so that’s all for the better.

Post reply on HN