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

361–366 of 366 posts

Re: Why Is Front-End Development So Unstable?

#361

Post by tracker1 »

acemarke wrote: post #293
tracker1 wrote: post #174

Earlier quoted context omitted.

I've only seen one issue in React that affected me.. when they started requiring PascalCase for component names with JSX. Everything else has been really nice. I glommed onto Redux and thunks pretty early on, and have been wrapping around fetch about as long. I used Bootstrap for a long time, and progressed to material-ui with very little disconnect. Those have been my personal preferences for several years, and they…

The JSX transform has, as far as I know, _always_ required PascalCase for component names. That's how it distinguishes between "this tag name is actually a variable pointing to a component" and "this tag name should be turned into a string".

Nope.. early on, you could use any local variable... there was a whitelist of html elements... they did a cleanup that required the PascalCase and defaulted to html element render for anything else. It was around 0.10 or so, iirc.

Re: Why Is Front-End Development So Unstable?

#362

Post by pas »

randomdata wrote: post #275
pas wrote: post #193

Earlier quoted context omitted.

It's data. There's a fix format for serializing it. In a lossless way. I don't know what meredydd talks about, there's no mismatch with regards to data. You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit. The problem with frameworks is not the hardship of funneling data up and down the stack. The problem is that they are optimizing for different things. React op…

> I don't know what meredydd talks about, there's no mismatch with regards to data. He's talking about different services each having their own preferred way to structure the data. When the layout differs, it cannot simply be a memcpy, and so you get tools to try to ease the tedium of translating one structure's layout into to another. They get the job done most of the time, but run into edge cases that return the de…

> own preferred way to structure the data.

Absolutely. But user/business data? That doesn't matter. When you design the system/stack you pick the right components/tools (right data structures) that can losslessly represent the input/output of the neighboring/adjacent layers. If you want to store 500 byte long fields, then make your DB column 500 byte wide, make sure the backend accepts 500 byte long input, but rejects longer ones, make sure your HTML input has a maxlen=500 (and account for Unicode code point surrogate / multibyte fuckery if applicable)

There's mismatch, of course, but as I've detailed in a sibling comment [0], it's because of difference in purpose and function. A DB is different from a HTML/CSS layout rendering engine, because they have a very (set) of purpose(s), hence different interfaces, and so on. And frameworks are glue between these functions (and the layers as we allocate them to).

> Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases [...]

Yes, perfectly agreed. And since we concentrate on different edge-cases each time, we move from trade-off to trade-off with each new framework, and browsing trend/fad (mobile, tablet, SSR, ultra-tree-shakable-gzip-able, "native" [mobile] compilable, etc).

[0] https://news.ycombinator.com/item?id=17209305

Re: Why Is Front-End Development So Unstable?

#363

Post by tracker1 »

Chris_Newton wrote: post #264
tracker1 wrote: post #171

Earlier quoted context omitted.

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…

I do things "the hard way". I agree, except that I would argue it’s often the easier way. If I had to give a one sentence answer to the original question, it would be, “Front-end [web] development is so unstable because people introduce so much accidental complexity.” For example, while I don’t disagree with Meredydd that there can be awkward mismatches between the layers he described, I also think several of those l…

I think a lot of the disconnect can go further away as JSON data types (regardless of actual serialization such as BSON etc) and use are more well supported at the database layer. When I did more C#, and Entity Framework came out, I'd add an XML column to most of my tables, as well as a base class wrapper for my own use... that allowed by to write extension properties that wrapped around XML nodes under the covers. So I could extend with extra properties for things that didn't need to be queried on.

It worked pretty well, of course I actually started doing it because getting schema changes at my workplace was a painful endeavor.

I agree that a lot of the disconnect is induced by developers. It's also part of why I'm a pretty big proponent of a JS UI talking to a service written in JS. It allows for a lot less cognitive adjustment. I remember doing HTML/CSS/JS with Flash/Flex, with .Net, T-SQL, and VB6 in one workplace regularly. I swear every time I had to change from one to another, I was typing the wrong way for a good 15-20 minutes... answering questions at times took 2 minutes just to shake my brain out of whatever I was working in.

I started using less stored procedure code and the DB more as dumb storage, and embraced node pretty early on. Even if it is a "lesser" language, there's something to be said for one language to rule them all. (I do like modern JS though.)

Re: Why Is Front-End Development So Unstable?

#364

Post by rhapsodic »

tracker1 wrote: post #360
rhapsodic wrote: post #354

Earlier quoted context omitted.

>Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using…

I came into my example above 5 years in... it was "Enterprise" .Net and not Java, but a lot of the same techniques at play... I hated it all. I'll take today's JS/NPM ecosystem over those days. I rally against ORM, and DI/IOC frameworks to the end, they aren't needed in JS. That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/pattern…

>That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers.

I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.)

>As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad.

Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch.

When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.)

That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.

Re: Why Is Front-End Development So Unstable?

#365

Post by Too »

ggregoire wrote: post #173
k__ wrote: post #119

Earlier quoted context omitted.

Yes, I still don't get th Vue hype.

Angular 1 developers going back to something similar (my 2 cents).

I think the appeal of Vue is that it's "Angular done correct" and "Angular without the bloat you never use". The core concept of Angular was never bad, it's just that it had tons of pitfalls and bugs and it wanted to be everything at the same time, not just the view-layer.

Re: Why Is Front-End Development So Unstable?

#366

Post by blacksqr »

thisrod wrote: post #159
paulddraper wrote: post #128

Earlier quoted context omitted.

> Growing up from a document viewer to an app platform in the particular way it did left the web as the most important and ubiquitous GUI app deployment and runtime platform, but without a dev-accessible native GUI component system. Exactly this. Web technologies cannot be understood without understanding the history of the web itself. You could just as easily imagine, say (random example), Internet + Gopher + Lisp p…

> It was somewhat inevitable chain of events The question that intrigues me is why Tcl/Tk didn't take off around 1995. We could have had internet apps about a decade before web apps were feasible. The only answer I can think of is that no one in 1995 would have contemplated running a Tcl script that their computer had just downloaded from a random host, but Javascript boiled that frog gradually. I'd be keen to hear o…

https://news.ycombinator.com/item?id=2380044
Post reply on HN