Why Is Front-End Development So Unstable? • Hacker News Board

Re: Why Is Front-End Development So Unstable?

#271

Post by toasterlovin » Thu, May 31, 2018, 1:58 PM UTC

qaq wrote: post #259

toasterlovin wrote: post #245

Earlier quoted context omitted.

I’m actually quite fond of SQL, but I disagree that ORMs are not a productivity boost. My experience is in Rails and I think ActiveRecord is a pretty clear win for simple queries. That being said, it is pretty common for less experienced developers to not understand what the ORM is actually doing.

On any project of sufficient size there will be fairly advanced reporting functionality that you generally will not be able to do using ORM so you will end up with a mix of ORM and direct SQL. Also ORM forces you to the lowest common denominator for supported RDBMs I generally do not want to be limited to the SQLite features if I am running PostgreSQL

I did qualify my statement with “for simple queries”.

For more complicated queries, a pattern I have become quite fond of is making database views and then using them as the backing table for an ORM model. In Rails, at least, this gives you the best of both worlds.

Re: Why Is Front-End Development So Unstable?

#272

Post by rimliu » Thu, May 31, 2018, 1:58 PM UTC

andrewstuart wrote: post #150

It's unstable because there are millions of developers working with front end technologies and that community is rapidly finding better ways of doing things. And when better ways are found, because development is so time consuming and difficult, people move to embrace those new and better ways. I'm glad of the rapid change because there is alot more improvement needed at the front end. Consider for example the vast a…

s/better/different/

Compared to how much code size and complexity for the tooling increased the benefits for the end user are tiny, if there are any at all. We are just getting SPAs which do not work with JS off where a simple static page would do perfectly.

Re: Why Is Front-End Development So Unstable?

#273

Post by bzalasky » Thu, May 31, 2018, 2:02 PM UTC

christophilus wrote: post #256

ggregoire wrote: post #131

Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Post…

Did you read the article? Here's a snippet from the beginning: > Do front end technologies actually change that quickly? > In the sense of major view technologies, probably not... Consider this list of the highest ‘starred’ JavaScript front-end technologies on Github: +------------------------------------------------------------+ | Library | Stars | Released | Age | |--------------------------------------------------…

Small correction on the chart, React has actually been open sourced for ~5 years, React Native is ~3 years old.

As far as how fast frontend technologies are changing, in my ~10 year career, I've only had to use jQuery (~2008-present), Backbone (~2012-present) and React (2015-present) professionally. These libraries weren't swapped out on a whim, and I still use all 3 in different projects on a weekly basis. While I've dabbled with most of the others, I haven't selected them or encountered them professionally.

To some extent, I think library churn can be attributed to keeping things interesting when the problems you're solving are less interesting.

Most frontend engineers could probably benefit from rolling their own SPA library (not for production use, but to learn how the different pieces come together). There's probably room for a few more "From Scratch" tutorials in this space akin to Destroy All Software's series of screencasts. Working through something like this would make it clear that the differences between the libraries above are smaller than it might otherwise seem.

Re: Why Is Front-End Development So Unstable?

#274

Post by Chris_Newton » Thu, May 31, 2018, 2:03 PM UTC

emodendroket wrote: post #250

aaronbrethorst wrote: post #182

Earlier quoted context omitted.

I feel like this is a false dichotomy. The choice doesn't have to be roasting squirrels over an open flame/handcrafting PHP pages vs. shiny futurism/Node+React. I have been getting along just fine with Rails, HTML, and a sprinkling of JS for over 10 years.

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 standard foundations with minimal dependencies in between and usually a relatively small but high-value set of libraries.

The benefits of quickly fetching many tiny packages with a package manager or of building on top of all-encompassing frameworks or automation tools are mostly found in two situations, in my experience: getting started quickly (including rapid prototyping exercises) and ongoing development if (and only if) you are staying almost entirely within the bounds of what your chosen technologies already do well.

However, if your requirements start to evolve and diversify in a longer-lasting project, it’s all too easy for those numerous tiny dependencies to become a liability or for that framework or tool you built everything around to become a straitjacket. The relatively short lifetimes of many of these technologies can also become an expensive problem if the community drifts away and the security and compatibility work slows down or stops entirely but your project still depends on them as much as ever.

Re: Why Is Front-End Development So Unstable?

#275

Post by randomdata » Thu, May 31, 2018, 2:09 PM UTC

pas wrote: post #193

adrianratnapala wrote: post #151

Earlier quoted context omitted.

Even on the desktop those three layers involve impedance mismatch and much the same pathologies as meredydd describes. But I guess three layers of it are better than 6.

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 developer back to manual tedium. Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases, but they end up leaving many more on the table for the next intrepid developer.

Re: Why Is Front-End Development So Unstable?

#276

Post by gkya » Thu, May 31, 2018, 2:12 PM UTC

collyw wrote: post #60

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.

I got asked if I had a blog in an interview. I am a software engineer not a self marketer.

If you ever used any F/OSS software, or made use of a blog post when solving some problem, you owe to the community a blog or something similar. That can be answering SE questions etc. occasionally or an anonymous blog, not contributing knowledge to the community that saves you many years of work every day is outright selfish.

Furhtermore, I don't see what makes self marketing a bad thing given it is of the honest kind. The CV you send to them in order to get the interview is self marketing too, and so are thw clean clothes you wore to that occasion.

I cant count how many times a random blog post has saved me blinking weeks. You are being very rude with that statement.

Re: Why Is Front-End Development So Unstable?

#277

Post by rhapsodic » Thu, May 31, 2018, 2:13 PM UTC

tracker1 wrote: post #178

rhapsodic wrote: post #99

Earlier quoted context omitted.

> Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”. This defines what the developer wants to happen, Yes, it does. All in one place, in about 10 easy to understand, easy to debug lines of code. >but is brittle and hard to test. I don't see how it's brittle, or hard to test. You click the button, and verify that it does what it's suppose…

Scale that to a VERY large application. There are lots of applications where class names and even hierarchies get re-used by other teams working on another portion of an application. In practice, CSS blows up, other portions of the app stop working correctly. Yes, you CAN use discipline in order to create good applications with jquery and others. In the end, I'll take my single state tree (source of truth) and one-wa…

>Scale that to a VERY large application.

I have. Without problems.

>In practice, CSS blows up, other portions of the app stop working correctly.

Perhaps in your practice, tracker1. But not in mine.

That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me.

If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code.

I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.

Re: Why Is Front-End Development So Unstable?

#278

Post by _ea1k » Thu, May 31, 2018, 2:21 PM UTC

Doctor_Fegg wrote: post #212

ggregoire wrote: post #131

Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Post…

> Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? _If_ frontend development is all you do, then no, it isn't. One of the good things about the internet is that it's possible for a lone wolf to build and ship something amazing. One person can understand enough of the full stack, from HTML/CSS through JS to a serverside language and basic server administration, t…

I think you really nailed it with the packaging concerns. It doesn't help that every little framework (and mini-framework) seems to think that the problem can be fixed by just shipping their own little CLI wrapper.

Not having a decent build and package management system is what makes the frontend ecosystem so hard, IMO. I'm hoping this finally changes in the next couple of years.

Re: Why Is Front-End Development So Unstable?

#279

Post by goatlover » Thu, May 31, 2018, 2:24 PM UTC

tracker1 wrote: post #184

megaman22 wrote: post #95

Earlier quoted context omitted.

The front-end world is rediscovering lessons learned in the days of desktop thick clients from the 90s, if not earlier. I rage far too often that I have to jump through all these hoops to slam out some UI that I could have done in high school with VB6.

That said, most You can do a simple web app with straight HTML, and a light web server app pretty simply. Not as simply, but simply enough if you wanted to.

> VB6 apps I've ever seen didn't even handle, or enable a window resize properly.

I think the complaint is that GUI builders from the 90s could have been adopted and improved (responsive for one) on the web in the last 20 years. Flash had a GUI builder, animation timeline, etc. ten years ago.

Re: Why Is Front-End Development So Unstable?

#280

Post by fauigerzigerk » Thu, May 31, 2018, 2:25 PM UTC

pas wrote: post #193

adrianratnapala wrote: post #151

Earlier quoted context omitted.

Even on the desktop those three layers involve impedance mismatch and much the same pathologies as meredydd describes. But I guess three layers of it are better than 6.

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…

>You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit.

I'm not sure what exactly you mean by that. But one thing is absolutely clear. You cannot automatically derive a logical layer from the layer above or below. If you could, there would be no reason to have seperate (logical) layers in the first place.

That's why you get an "impedance mismatch" that has to be bridged by providing some additional information, which often has consequences for performance, debuggabilty and clarity.

Maybe I misunderstand the gist of your comment though.