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

Why Is Front-End Development So Unstable?

breck-mckye.com

Post reply on HN
Print view View original

281–290 of 366 posts

Re: Why Is Front-End Development So Unstable?

#281

Post by Kinrany »

mseebach wrote: post #43
Karrot_Kream wrote: post #30

Earlier quoted context omitted.

I'm finding the growing celebrity culture of programming to be troubling. I find that programming is becoming less and less about code or architecture and more about evangelism and marketing, but I'm not sure what changed in the incentive structure for this to happen, and I would like to find out. Aside: This has made me reconsider being a career programmer.

It's an extremely large and diverse field. There are plenty of us who aren't celebrities and don't care about celebrities (except to the extent that it is caused by deep expertise). Just like you ignore reality TV celebrities, ignore these guys. It's just noise. Turn off Twitter and read "Growing Object-Oriented Software, Guided by Tests" instead.

Is it just me, or is the last line basically "other gurus are fake, only this guru I support is real"?

Re: Why Is Front-End Development So Unstable?

#282

Post by godinaa »

rusk wrote: post #192

I think the quality standard is different. Front end has to "look good" and be "good enough to use". Little finnicky errors are often tolerated as a user can be expected to work around a certain issues. Since issues can be quickly spotted code hygiene and rigorous software quality practices aren't as important. Also, performance and resource utilisation aren't as important, to a degree anyway. Back-end, unsupervised,…

I disagree. Rigorous code standards are just as necessary on front-end code as back-end. In my experience, no code review, poor design or documentation, and lax standards lead to jittery experiences. For example, people write complex blocking code that causes the page to freeze for moments while that processing is happening. People write event handlers that execute too often and slow user interaction.

Re: Why Is Front-End Development So Unstable?

#283

Post by rusk »

godinaa wrote: post #282
rusk wrote: post #192

I think the quality standard is different. Front end has to "look good" and be "good enough to use". Little finnicky errors are often tolerated as a user can be expected to work around a certain issues. Since issues can be quickly spotted code hygiene and rigorous software quality practices aren't as important. Also, performance and resource utilisation aren't as important, to a degree anyway. Back-end, unsupervised,…

I disagree. Rigorous code standards are just as necessary on front-end code as back-end. In my experience, no code review, poor design or documentation, and lax standards lead to jittery experiences. For example, people write complex blocking code that causes the page to freeze for moments while that processing is happening. People write event handlers that execute too often and slow user interaction.

My point was though, that such issues can be quickly picked up just by using the application, and you can usually elicit the causal factors by prodding at it. Often times such issues in non-UI code can go for years without it being noticed.

But broadly speaking yes I agree, but one or two of my line managers in the past would not.

Re: Why Is Front-End Development So Unstable?

#284

Post by fauigerzigerk »

lkrubner wrote: post #228
Cthulhu_ wrote: post #219

Earlier quoted context omitted.

There have been attempts at rethinking it though; noSQL was the buzzword of a couple of years ago, and even nowdays there's mature tools like Firebase that allow you to store and retrieve data much more directly than e.g. SQL. The challenge in nosql storage is of course data migrations and whatnot. But yeah, in theory you can just open up a MongoDB instance to your front-end and not have to bother with SQL or much of…

Angular and React both rely on Javascript and HTML, so you can't describe them as "designed to be great front-end technologies". HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML. It's gotten better over the years, but it is still far from what you would expect if you were trying to build a…

I agree with you on HTML/CSS but I don't see how JavaScript is any worse than VB or any other programming language ever used for frontends.

Re: Why Is Front-End Development So Unstable?

#285

Post by cirgue »

tracker1 wrote: post #171
meredydd wrote: post #56

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.…

All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…

> WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries?

I am getting into frontend for a hobby project after spending a few years doing ML and applied stats, and I am currently asking myself this question. If your db interaction is simple, a query is almost as easy to write and maintain as an interaction with an ORM, and is significantly more flexible. If it is something more sophisticated, then your ORM quickly becomes more of a hindrance than a help. What am I missing here? Where is the virtue of an ORM beyond not having to use SQL?

Re: Why Is Front-End Development So Unstable?

#286

Post by ayrx »

boomlinde wrote: post #208
ayrx wrote: post #148

Earlier quoted context omitted.

What incentives would a someone have to invest a considerable amount of time in releasing and maintaining an open source project if they can't even use that to promote themselves?

Maybe they have a genuine interest in the problem they're addressing, and in solving it. I work on some open source projects that gain little attention from others but have great utility to me, personally.

It's a nice sentiment but that's how you end up with abandoned, low quality projects that no one uses. Or even worse - abandoned, low quality projects that half the Internet relies on.

Re: Why Is Front-End Development So Unstable?

#287

Post by la_fayette »

unclebucknasty wrote: post #242
bonesss wrote: post #206

Earlier quoted context omitted.

> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to c…

About 17 years ago, I wrote a GUI-based code generator that allows me to generate the boilerplate JDBC cruft from SQL statements, with several options for common scenarios. The code it generates is extensible and provides helpers for extending. To this day, I haven't found anything (including ORMs, Spring support, etc.) easier to use, more flexible, or more sensible.

Is it closed source? I am in search for something like this. I consider this as Naked Object approach.

Re: Why Is Front-End Development So Unstable?

#288

Post by patorjk »

reitanqild wrote: post #170
patorjk wrote: 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.

Angular 1.x is not listed in https://update.angular.io/.

Additionally, there was no initial update path between Angular 1 and Angular 2 until the community cried foul. It's been a while, but after they finally released an Angular 1 to Angular 2 bridge, I read several tutorials and books that discussed the upgrade path but said to absolutely not use it in production. It would kill the performance of your app. That sort of made the value of an Angular 1 to Angular 2 bridge pretty weak. If one were to migrate to Angular 2, it would seem more time efficient to just to start fresh rather than spend time on a wonky bridge between the two frameworks.

Re: Why Is Front-End Development So Unstable?

#289

Post by gkya »

darepublic wrote: post #106
rhapsodic wrote: post #66

Earlier quoted context omitted.

>In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?

Having worked with large codebase written in jQuery here are some of my thoughts, There were a ton of times where the complexity of the situation made it so hard to know how to debug something. I mean you had to keep track in your head in a given piece of code what the UI state was, what classes or event handlers were toggled on or off, what the value of various variables were etc. In order to keep my sanity I would…

That sounds like an issue caused by an indecent debugger to me. I havent had to debug JS, but indeed the browser debuggers can use some sophistication and customisability, IMHO.

Re: Why Is Front-End Development So Unstable?

#290

Post by emodendroket »

Chris_Newton wrote: post #274
emodendroket wrote: post #250

Earlier quoted context omitted.

That stuff works fine if your client-side needs are simple, but if you actually want a single-page application, or just an application with a lot of rich JS functionality, it quickly becomes unwieldy.

That stuff works fine if your client-side needs are simple To be fair, just about anything works fine if your client-side needs are simple. However, I have reached the opposite conclusion to you: the more customised and complicated and large-scale and long-lived the software becomes, the less value I see in a lot of the popular but ever-changing web technologies and the more I am likely to favour building on the stan…

I don't like microlibraries very much either, but that's a different question. A monolithic frontend framework can make your life easier.
Post reply on HN