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

Why is front-end development so unstable? (2018)

breck-mckye.com

Post reply on HN
Print view View original

161–170 of 181 posts

Re: Why is front-end development so unstable? (2018)

#161

Post by hansworst »

Hermitian909 wrote: post #131
scrose wrote: post #118

Earlier quoted context omitted.

> I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us. Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set…

> that's rare, but great Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90% + used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the…

I’ve experienced similar thing wrt the build system, but haven’t used redux in all but one of the React projects I’ve worked on as a full time product engineer over the past couple of years.

Re: Why is front-end development so unstable? (2018)

#162

Post by gjvnq »

holoduke wrote: post #33
moonchrome wrote: post #15

Saying React support libraries are at fault here is not fair - React basically reimagined itself over the years and went from OO and class based components to hooks and functions. The fact that you can still do OO isn't really helping it since it adds to the complexity of things you need to learn to grasp the ecosystem. But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous ca…

I don't know one single UI/UX development environment which is elegant and nice. From Android to iOS to Linux to Linux and Windows to browser UI kits. They are all complex and require constant searching for answers. The libraries are very big and require a complex tooling setup. You can never be an expert in all of them. At least not me.

NCurses is pretty elegant in it's simplicity.

Re: Why is front-end development so unstable? (2018)

#163

Post by kbrannigan »

sbf501 wrote: post #74

Here's an unpopular opinion: it is unstable because we don't know what exactly "front-end" means. First it was static HTML pages, then it was CGI (ColdFusion & DHTML FTW!), then it was PHP, then it was Rails, then it was Node, then it was React, Angular, Vue... Those aren't random progressions. On the contrary, they are front-end devs responding to needs of the UX moreso than the UI. There have been major efforts to…

Funny I started to rediscover PHP. It is so pleasant. Just by reading the documentation of Symfony, Yii I have learned a lot about web development.

Re: Why is front-end development so unstable? (2018)

#164

Post by azemetre »

msie wrote: post #127
cehrlich wrote: post #92

Earlier quoted context omitted.

It’s true that there are a lot of different ways to do the same thing, but the good news is you’re doing the same thing and the difference is mostly just syntax. Someone who has used Redux extensively can get up and running with Zustand in no time, and vice versa. Likewise React Query and Apollo Client are basically the same thing. Build tools are a bigger issue, but fortunately most front end devs don’t actually nee…

As if it's so easy to move from one thing to another. Yikes!

Some libraries will create code mods to assist in transitions. For example I've used some MUI codemods in the past to make transitions to newer versions of the library more seamless [1].

There are also codemods to say move from underscore to lodash and vice versa (been a while and can't find them at the moment).

ASTs [2] are pretty cool in this regard. Especially if you write your code in a manner that easier to automate against.

[1] https://github.com/mui/material-ui/blob/master/packages/mui-... [2] https://en.wikipedia.org/wiki/Abstract_syntax_tree

Re: Why is front-end development so unstable? (2018)

#165

Post by nawgz »

ricardobeat wrote: post #159
nawgz wrote: post #152

Earlier quoted context omitted.

> > I maintain my 2017 apps including major version bumps with no issues today > Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps” What a strange stance. It's a React/MobX collaborative model editing internal tool deployed in production to users who generate and analyze models with it. It started on Webpack 2 and React 15 and MobX 4, now it's on Webpack 5 and React 17 and MobX…

> I find it difficult to believe that you really think React Context scales the same way I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons. jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption. I've been involved in multiple new product de…

Lol, where did you get that I maintain one stable app from? I additionally don’t see how your working conditions relate to churn in JS given that you could use the same stack for each of those projects, as I said, as far back as 5 years ago

Re: Why is front-end development so unstable? (2018)

#166

Post by mgkimsal »

escape_goat wrote: post #65
zero_shift wrote: post #51

Earlier quoted context omitted.

I'm the author and I agree. Things have slowed down and matured. The "JS moves too fast" meme is well out of date, and in fact I wrote a comment here a few hours ago bemoaning it

I don't know what it's like these days but I recall especially the pernicious 'evangelism'. People on a literal salary promoting frameworks like they were from marketing. As a bargain basement, self-taught, late web 1.0 dev more comfortable on the server side I remember rake-stepping the undiscussed limitations of Backbone JS, and then studying the ridiculous complexities of Angular 1 while reading post after post of…

> and then learning that the great leap forward for Angular 2 was "yeah we're going to throw all that bullshit out we were wrong." By the time I was done I genuinely had no interest left in me for another new framework, package manager, or library....

I've seen this more than a few times over the years, and it makes me a lot more skeptical of praise for anything new. Almost always the praise is about technical aspects of a new tech/stack, and the value is almost always in the larger ecosystem. I'm fine - happy, often - with using something slightly out of date if it means there's a community of people who can help support it, answer questions, publish mods, etc. There's a balance somewhere to be found, but I've been burned too many times picking a tool, investing in it, then having much be thrown away for the 'v2' version which is often not backwards compatible (for good reasons, usually, but still problematic).

Marks of maturity of a project - acknowledging upgrade requirements, publishing upgrade guides, supporting previous versions for a publicly stated time range, etc.

Re: Why is front-end development so unstable? (2018)

#167

Post by runarberg »

suction wrote: post #154
runarberg wrote: post #119

Earlier quoted context omitted.

I inherited a vue2 codebase with a vuex store, and upgrading to vue3 and pinia one component at a time over a course of 3-4 months was quite easy. The upgrade path is really clear and they did a good job making everything compatible so that it could be made gradually over a relatively long time.

3-4 months seems doable. We are usually asked to do it in a week or two.

That seems like a bad idea from an engineer perspective. The migration path is designed to be gradual, that migrated and legacy code can live side by side in production. I honestly don’t know why anyone would enact a policy of migrating all at once when there is an alternative.

Re: Why is front-end development so unstable? (2018)

#168

Post by miiiiiike »

etoxin wrote: post #148
miiiiiike wrote: post #130

Earlier quoted context omitted.

This comment makes absolutely no sense in the context of the article. Did you read it?

you're right. I only read the title and very quickly. My bad.

Good on you man. Not many people are big enough/bother to admit to being wrong on the internet.

Re: Why is front-end development so unstable? (2018)

#169

Post by Shalomboy »

madeofpalk wrote: post #124
ricardobeat wrote: post #80

Earlier quoted context omitted.

You covered the frameworks, but a lot of the feeling comes from the tooling and library ecosystem. For example, a recap of the last 10 years: - grunt / broccoli / gulp / browserify / webpack / metro / esbuild / parcel / swc / turborepo / bun - flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai And this is just within React, and off…

Postgres, mysql, mariadb, cockroachdb, Prometheus, neo4j, firebase, dbaas. The list goes on and on. Multiple things exist. That’s fine and healthy? You don’t need to know absolutely everything.

I would be thrilled to work someplace that uses neo4j. Such a good graph dbms. Too many folks believe the only way to organize data is with relational tables.

Re: Why is front-end development so unstable? (2018)

#170

Post by ricardobeat »

nawgz wrote: post #165
ricardobeat wrote: post #159

Earlier quoted context omitted.

> I find it difficult to believe that you really think React Context scales the same way I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons. jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption. I've been involved in multiple new product de…

Lol, where did you get that I maintain one stable app from? I additionally don’t see how your working conditions relate to churn in JS given that you could use the same stack for each of those projects, as I said, as far back as 5 years ago

You said 'It's a React/MobX collaborative model editing internal tool' so I assumed you're commenting based on that particular project. It's not a value judgement either way.

The kind of development you do (product / projects / marketing) makes a huge difference in your experience, how often you get to start from scratch (= latest versions of everything) vs maintaining existing codebases. I don't think that's controversial. You could use the same stack for every project, but people and teams change and want to catch onto the latest "advancements" in the field.

Post reply on HN