Live data from Hacker News

Why Is Front-End Development So Unstable?

breck-mckye.com

161–170 of 366 posts

Re: Why Is Front-End Development So Unstable?

#161
post #82

At some point, when modules get "micro" enough, the effort of managing them and learning their usage outweighs the effort of implementing the thing yourself. Most JavaScript projects seem to walk that line quite closely. I'm a React developer at work, but I recently gave Vue a try at home. This is one of the things that most stood out to me about it. React makes a selling point out of the fact that it's "just renderi…

Seriously, I feel the same way. I tried Angular1 5 years (?) ago and had to do ember for a gig. They were way too complicated, bloated, and terrible.

Vue just works. One of the book suggest that if you like React JSX you can do it too in VueJS. I've never done React but the thought of mixing javascript with template sounds horrifying. VueJS default template system make sense and it is self contain to a file or component.

Re: Why Is Front-End Development So Unstable?

#162

Earlier quoted context omitted.

Mithril is similarly small and very easy to get started.

Mithril is my favorite by far. It's not even close. It's depressing how little-known it remains.

@RodericDay, I just vouched this comment which was [dead].

You've been shadowbanned since https://news.ycombinator.com/item?id=14982937 (9 months ago) you may want to appeal that decision or create a new account.

Re: Why Is Front-End Development So Unstable?

#163

Earlier quoted context omitted.

>If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors. I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here. jQuery is library that provides DOM shorthand - it isn’t a true application framework. Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the tec…

Something like React isn't even an application framework, though, it's a view library of compositional functions feeding into a tree diff. How does functional, side-effect-free code increase complexity ? What makes your side-effecting code more testable and verifiable than unambiguous in/out functional transforms?

Personally for me it's a trade off and it does increase complexity.

With jQuery and such you just include a script and back then there were no package management system, glup/grunt, webpack, yeoman/brunch, etc..

Also the client side rendering make SEO hard.

jQuery just get stuff done but at the same time the organization of your code is up to you and you do sacrifice some reusability but in general the trade off is complexity.

VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...

Re: Why Is Front-End Development So Unstable?

#164
Yes, no one takes the time to research. Most popular does not equate to good.

I took the time to do the research back in 2013 and found that Ember basically solves all the problems OP talks about. Tom Dale, one of the creators of Ember, blogged over a year ago [1] about how Ember has been around since the days of Backbone. As the years rolled on, other frameworks became obsolete, but Ember evolved (with sane upgrade paths) and is still relevant.

1: https://tomdale.net/2017/04/making-the-jump/

Re: Why Is Front-End Development So Unstable?

#165

There are a set of converging interests causing pain in the ecosystem. First a company promoting a project, then people hoping to provide services, consulting or training, and third people hoping to get a job or padding their current resumes. None of these people have a particular interest in the technology or its merit, its anything they can make money or benefit from and then forums like HN and others are used to a…

I assume that observation applies to more than just front-end development. At least I've personally seen the effect more generally.

I think another self-interested actor is the "nobody ever got fired for buying IBM" manager, except that, today, it's not IBM. IBM has, of course, been replaced by whichever technology is currently in high repute. They need never gain technical knowledge themselves.

Granted, in some cases, that's actually a case of legitimate delegation to their engineers (whose conflicting interests you've addressed), but, since they have the same access to the Internet as everyone else, that can't be assumed.

> And since self interest is involved the arguments become needlessly charged.

I hadn't fully considered that until now.

That isn't to say that I'm not a cynic, but, rather, that, for example, the average HN commenter may not want to come to terms with having, even to a slight degree, such self interest. That can lead a form of needlessly charged argument, defensiveness, that wouldn't necessarily be obvious otherwise.

In a professional setting, it can lead to seemingly-irrational decisions in the face of overwhelming evidence that the other way is better.

Re: Why Is Front-End Development So Unstable?

#166

Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3.…

That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins.

OP forgot how life looked when your web app project was handcrafted HTML page with manually inserted scripts tags. When your form submission was multi-level backend API in PHP. jQuery plugins with 20+ options published randomly on the internet.

Re: Why Is Front-End Development So Unstable?

#167

Earlier quoted context omitted.

I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .

> I think more developers should use jquery to prototype an app and move torward a framework when it is needed. They really shouldn't. With VueJS it's not that difficult to get setup and running with the CLI and components is such a game changer. Don't get me wrong. I love jQuery, there's nothing better than taking someone else's library and then extending it. Here's an example [0]. However, one thing that I have lea…

> One last thing to leave with. I have a page builder much like Elementor. In jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's about 20k LOC alone with hundreds of functions.

> Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC.

The community with the first decent (open-source or paid) page builder gets my vote. I could use that in so many projects (and tell people "Yes it's WordPress" when the underlying tech is something else).

I was expecting it to be React, with each component having a frontend view and an admin view, and then I'd do server-side-rendering, but happy if it's VueJS...

Re: Why Is Front-End Development So Unstable?

#168
This is pretty funny. Frontend isn't "unstable". We have made it unstable with "modern" frameworks and libraries. The web is one of the most stable things ever built. There are sites from the early 90s still chugging along. That's more than you can say for most "front ends".

The better question is why did we fuck everything up so badly and call it "modern" as if the other methods of doing frontend development are prehistoric caveman shit. That's the fucking joke.

Re: Why Is Front-End Development So Unstable?

#169
I do find a bit of the argument hyperbolic... My preference today is Koa + about 3-5 modules (including 1-2 custom) on the backend and React, Redux, Redux-thunks, redux-first-router and fetch (in most browsers) on the front end. For UI, will generally suggest bootstrap or material-ui (the library). create-react-app does take a lot of the guesswork out of the front-end.

In the end, front/back-end tech grows at an incredible pace. Look at go, rust, .Net Core and a half dozen other options that sprung up in the past 6-8 years and all the frameworks around them. It isn't new. Last generation(s) it was Python, Ruby, C#, Java and on, and on... this isn't new.

Re: Why Is Front-End Development So Unstable?

#170
post #14

> What is to be done? ... Consider non-microlib architectures What about what happened with Angular (1), the 3rd library on your list? That whole framework was deprecated in favor of Angular (2). Additionally, the list of front-end libraries given doesn't really reflect the landscape front-end devs have traversed. Years ago, I remember working on an app that heavily relied on YUI around the time that library was shut…

There's a clear upgrade path (with tooling) between Angular.js and Angular 2, 4, 5, 6. There's now also https://update.angular.io/ to help.
Post reply on HN