Remix clone Hacker News

It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.

I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.

Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.

▲

johnisgood 3 days ago | parent | next [-]

> The majority of web developers today suck

Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.

I do not even know if they would classify as "junior" devs.

This does not apply to ALL web developers, but many.

	▲	maccard 3 days ago \| parent [-]
		They still existed and wrote shitty code 20 years ago, or 30 years ago.

▲

injidup 3 days ago | parent | prev | next [-]

> React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year

proceeds to shame and suggests changing to the new paragdigm of the year.

> For a framework meant for serious adults

	▲	soulofmischief 3 days ago \| parent \| next [-]
		I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time. And the sentence you quoted is a dig at React and the React ecosystem, not individual developers. Nice try, though!
	▲	RUnconcerned 3 days ago \| parent \| prev [-]
		mithril is hardly the new paradigm of the year

▲

branko_d 3 days ago | parent | prev | next [-]

> Also, React is a nightmare.

I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.

However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.

▲

lexlash 3 days ago | parent | prev | next [-]

I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.

React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.

https://mithril.js.org/

▲

bryanrasmussen 3 days ago | parent | prev [-]

I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.

▲

soulofmischief 3 days ago | parent [-]

Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?

▲

bryanrasmussen 3 days ago | parent [-]

The idea of JSX is I think genius.

If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.

But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.

This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.

https://github.com/chentsulin/awesome-react-renderer

So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.

This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)

sorry about last part, old programmer wandering.

▲

threetonesun 3 days ago | parent | next [-]

I would never want to write template files in something other than JSX at this point. Every library that does binding via HTML attributes is a huge step back, as far as I'm concerned.

I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.

	▲	bryanrasmussen 3 days ago \| parent [-]
		I wouldn't say it's 90% (although my last quibble regarding percentages in this very thread got downvoted to 0) but it is tedious and sort of difficult because of the tediousness, but not sure I have ever seen any solution for forms that made me say, damn I like working with this.

▲

branko_d 3 days ago | parent | prev [-]

What is truly remarkable about it is that it’s just JavaScript (after some transpilation), which means you can easily use JavaScript’s control structures. Conditional rendering has never been so easy!