Hacker News Reader

Comment by tambourine_man | Hacker News Reader

I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack.

If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework.

If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying to shoehorn types into it, only to later transpile it back? Not to mention JSX.

It all seems so crazy to me, but this ship has long sailed.

View on HN

> It all seems so crazy to me, but this ship has long sailed.

Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me.

Although it's not a perfect solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development.

The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.

Svelte has been on my list to try, thanks for the reminder. I've also liked htmx (from intercooler) for keeping complexity managed. Any comparisons?

I saw the Svelte presentation a few years ago when it was released and my jaw hit the floor hard. That was some cool radical thinking. I haven't used it beyond playing with a few examples, so I can't really tell for sure if it holds up. Everything looks great on the demos.

Unfortunately it hasn't caught on, though it maybe be too early to call.

Too early to call.

Wait until Typescript is properly supported.

That happened like half a year ago[0]

[0] https://svelte.dev/blog/svelte-and-typescript

Definitely too early to call, but it is making waves already:

https://2020.stateofjs.com/en-US/technologies/front-end-fram...

I really, really hate the JS toolchains like "Webpack + TS + React + eslint + Babel etc etc" that you mentioned.

I rather like Svelte.

But honesty requires that we recognize that Svelte also uses Webpack/Rollup + TS + Svelte etc etc.

I like the idea of Snowpack. But if A.svelte and B.svelte both use C.svelte, Snowpack has to do a lot of redundant work to provide A.js and B.js with Svelte.js and C.js all converted again and again from ts then baked into both A.js and B.js. That's a lot of server work and a lot of client work and a lot of network work.

So you still want a webpack or rollup or what have you to bundle and tree-shake and codesplit for production. I don't know why this irritates me more than running any of my other code through a compiler. But it always has.

I've been running Svelte with esbuild and it's incredible, and doesn't bring along all of the above overhead. I get to target modern browser stacks which is a huge plus that keeps a large amount of complexity out of my toolchain.

Mileage will vary =)

what runs with a 'constantly running event loop' exactly?

I can't think of a single framework that does this, (its neigh impossible, actually, it'll just lock up your browser)

Svelte is cool, but this statement needs some serious proof

At Work, we‘re building web applications that need to be accessed by hundreds of editors with thousands of pages. Most of them share an essential bundle of components. Are you telling me a project that complicated can be built using just jquery?

Also, what‘s bad about typescript?

Do you need SPA for everything there? Because if server side rendering/logic is “allowed” with only a few interactive bits here and there written in jquery, than it can be absolutely done as that was/is the case a “few” years back.

I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.

Its become such a large obstetrical that we have scheduled in a task this year to remove all server side rendering from the app.

Its become such a large problem that we have scheduled in a task this year to remove all server side rendering from the app.

Server side rendering almost always means implementing the same feature twice, once on the server so it loads correct, and then a second time on the frontend so it changes as the user modifies it.

The number of clients accessing the page has no bearing on the best framework to use. The number of pages on the website is also not that relevant.

If 400 people are accessing 10,000 static pages, don't use any js at all.

I couldn‘t disagree more. It‘s a user portal managing thousands of different interactions and workflows, based on the users existing information. Most of them can be edited live with a content-management-system by an editor. These workflows are very hard to reason about with just jquery or nor js at all.

It can, sure, but having coding conventions is essential, which those frameworks/linters help to enforce.

But we've been doing projects with millions of pages way before React :)

Checkout Wikipedia, which, by the way, uses jQuery, of course. And PHP.

>Also, what‘s bad about typescript?

It tries to turn the very dynamic JavaScript into something it will never be and no amount of contortion can hide it. Unless it stops being a superset of JavaScript in the future, but I don't see that coming.

Wikipedia is a largely uniform, read-only, static experience. These days people want app-like experience on the front-end. Can‘t manage them with jquery.

The bit about typescript is true at runtime. However, Typescript is also good documentation for developers.

https://htmx.org

For when I’ve wanted to sprinkle interactivity, this is what I’ve turned to lately. It’s quite brilliant, and more declarative than most solutions.

But React is still necessary in my day to day job, as our web application is incredibly complicated in terms of feature set and customisation. They both have a place.

I'm on the same boat, super productive with php/twig/jquery. But recently my boss gave my a side project without any specific requirements, 10 charts and 2-3 tables with their associated crud. I made everything with react + php, and oh my god that site is super fast. It's eye opening!

Make Postbacks Great Again.

Reply on news.ycombinator.com