The boring front-end developer (2014)

https://adamsilver.io/articles/the-boring-front-end-developer/

by rayraegah • 7 years ago

93 69 7 years ago

adamsilver.io

Romanulus• 7 years ago

That was a very boring article.

drngdds• 7 years ago

Yeah, I don't think we really need a hundred Modern Frontend Bad articles every week

newfangle4• 7 years ago

We have 3. React, angular, and vue. Angular isnt even recommended anymore so its really only react and vue.

I dont think there has been much change in the javascript world in the last few years that hasnt been strictly beneficial. The biggest paradigm shift is probably the widespread use of typing on the frontend with typescript and flow.

slg• 7 years ago

Previous discussion: https://news.ycombinator.com/item?id=9879172

This should also have a 2014 in the title.

dang• 7 years ago

Added. Thanks!

OkGoDoIt• 7 years ago

Yes, 100% this. I've been trying to articulate the annoyance I have with modern front-end development and this hits the nail on the head.

Does anyone know SF companies that take this attitude? I've been interviewing all over at startups and large companies but I always feel misaligned when discussing front-end tradeoffs. I'm in the process of realigning my career away from full-stack dev nowadays because the state of frontend dev is so horrendous in my opinion. But I'd rather just work somewhere that isn't trying to turn every little thing into an SPA.

caprese• 7 years ago

Sell shovels during a gold rush, whats the problem?

If you are disillusioned then its time for something new

ng127• 7 years ago

Why not find a project somewhere that truly calls for an SPA? Those are the fun ones.

flukus2• 7 years ago

Because those are almost non-existent. There are many web-apps that need a fair bit of interactivity but a full SPA is overkill. I'm thinking things like JIRA where the interactivity of the kanban board is good but most of the time I'll just middle click to open a task in a new tab anyway, being a full SPA is a net negative. Most of the rest deserve to be a real desktop and/or mobile app.

SPA's aside web dev hasn't changed much in a decade, it's just been framework churn.

bryanrasmussen2• 7 years ago

ok since I worked at a place last year where compile times were hurting things I can understand that part but in general I have to say really bad decisions need to be made for compile time to even be noticeable.

rexpop• 7 years ago

I'm working on a 1.6Ghz CPU and compile times are a frustrating several seconds.

bryanrasmussen2• 7 years ago

The place where I was working was pretty big and had probably 10 big teams handling different parts of their site, to compile your project you compiled the whole site. Furthermore it did stuff like compiled images every time although image assets were hardly ever added. Compile times at times could be in the minutes. Not to mention that their gulp file was badly written.

A redesign of the whole compilation process was undertaken - assets that were global were compiled through a different process and you pulled the precompiled results, assets that were hardly ever touched in the normal development flow were not automatically compiled instead you had to call the process to compile them, only paths or asset types that had been changed were compiled - thus if no sass files had been touched no style compilation happened, and finally you no longer had to compile everybody's subsection of the site only your own. Compile time was generally less than a second for our part of the site on my machine.

newfangle4• 7 years ago

Does anyone that has been developing fe code in the past few years felt that the pace of change has been overwhelming? I think weve finally settled down on a few tried and true frameworks for frontend development.

chefandy• 7 years ago

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

Lots and lots and lots of people.

Scarbutt• 7 years ago

IME the issue is not being overwhelmed with libs/frameworks, the issue is SPAs requires way more work.

runarberg• 7 years ago

Perhaps, but I’ve been feeling the great schism[1] happening in front end development between a more design oriented developers and the tech oriented developers. Being on the design side of the schism (what this 2014 article calls BFED) I feel unsatisfied with the current state of front end mentality (even though its settled). I feel that the pressure to use the wrong set of tools to arrive at the wrong conclusion too great. The fact that selection between these wrong set of tools is less overwhelming, feels irrelevant.

Note that there are still what I consider right tools and right conclusions. They are just under in terms of popularity and it feels like the industry is pushing me away from them.

[1] https://css-tricks.com/the-great-divide/

throwaway8879• 7 years ago

I'm working on something new and and the whole frontend ecosystem makes me nervous. The last time I did any kind of production-level frontend work was 2004.

It feels like I woke from a coma and am trying to adjust to a new kind of world with flying cars except they don't really fly.

I mean, I feel insecure for writing CSS by hand, not using webpack/roll-up or a whole frontend build flow. I do like Mithril.js and Svelte though so perhaps I'll start using bits of that in my new project.

mixmastamyk3• 7 years ago

The important part is shipping, not what tools you use. Facebook and many others were started in PHP. That said I still lint my code.

eitland• 7 years ago

During the last two years in frontend I've learned about and considered and or used grunt, gulp, sass, Webpack Angular 1 and Angular 2+.

In hindsight maybe the most annoying part isn't just the constant churn, but also how questions about x will be answered with: you should use y instead.

ng127• 7 years ago

I don't. I've been using the exact same tech stack for the past 4+ years. Granted, that's not _that_ long but it's long enough to feel like it's table.

rajangdavis• 7 years ago

I just left a consulting shop where we didn't use the latest and greatest.

In some ways, it's sort of a blessing to avoid the javascript fatigue; however, in cases where we worked with clients with strong branding/UX guidelines with React components, it was really frustrating having to rebuild components entirely from scratch.

I think the largest changes are behind us - I think the big shift happened at the end of 2014 when Angular 2 was announced without backwards compatibility. It was also the time when Node had really been thrust forward as the backend language of choice in comparison to Ruby on Rails (from my experience).

santoshalper• 7 years ago

The boring front-end developer is trying to build for the web, not trying to build shitty "apps" that just happen to run in the browser.

jilles• 7 years ago

Damn I am a cool front-end developer and that's not a good thing.

jasonhansel• 7 years ago

Also: the boring front-end developer recognizes that large single-page apps can have significant front-end performance issues, which is why so many "modern" web apps are unbearably slow & memory-intensive.

localhostdotdev• 7 years ago

this is my definition of a boring programmer:

- makes code that works

- solves people's problems

- doesn't care what other programmers think

edit: the truth is a boring programmer won't even read this, just doesn't care, doesn't read hn, just does stuff

orange8• 7 years ago

If the code only works but isn't maintainable (simple and extendable), then you've got a very interesting programmer, just havn't realized it yet.

sk5t• 7 years ago

This seems like an appropriate time to invoke http://boringtechnology.club/ -- more thoughts on why to avoid the flavor of the month when you're trying to build useful software that doesn't _need_ dependencies on shiny new stuff.

kazagistar• 7 years ago

Of course, once everyone does this, tech innovation grinds to a halt and we end up using the suboptimal tools we have forever.

halleonard2• 7 years ago

loll

arenaninja2• 7 years ago

But some of us do work on front-end applications where even modern frameworks are scrutinized. I've started to dream of a maintainable application with no runtime on top of the browser itself (no vDOM)

IMO frameworks nowadays don't give you much more than a rope to hang yourself with, it's up to developers to recognize this. But some applications do need these patterns in order to build front-end applications with dozens of developers on the same team. The unfortunate reality is that too many people think they need use the same tech for a landing page; and too few people with front-end skills seem capable of profiling (in Chrome! nevermind trying to figure out where your GC pressure is coming from in IE11)

But this article is pretty boring. I can think of some concerns that the applications I work on need solved:

* Maintainable (TypeScript helps a ton with this)

* Stylizable/Themable (emotion/JSS, etc.; pick your poison)

* Reusable (presentational components in React; I imagine Vue could work for us as well)

* Asynchronous, reacting to events from user input/websocket/timers/local+remote storage appropriately

* Accessible via keyboard

wishinghand• 7 years ago

I've started to dream of a maintainable application with no runtime on top of the browser itself (no vDOM)

I believe the answer is Svelte.

arenaninja2• 7 years ago

I am currently looking into it :) So far the theming does not appear to be fleshed out; I'm about to compare some performance metrics with some of our animated components. I'm also not sure what the state management solution looks like, but I only spent a couple of hours setting up today

jv222222• 7 years ago

I love the Indie Hackers community and mission of the site, but I can't understand why on earth the site is so JavaScript heavy.

Almost everything on that site could be server side and there is no need for a loading screen that takes 2+ seconds to load!

Again, love what they've done, love the community, don't understand the tech choice.

https://www.indiehackers.com

Edit: I think javascript and dynamic stuff is great to use where it really speeds things up like a comment popup etc. I think of it like seasoning. Use it sparingly to make a site really great in the places that a full page reload would be a bad experience.

jb3689• 7 years ago

Yeah, in my ETL work we call things like this bugs. I've never understood why this is acceptable on the front-end. Users seem to have been conditioned over the years that it's just "slow internet" I think and are willing to wait for an app to load

jv222222• 7 years ago

Yeah. And how much code has to load?

Given that I can get 100k image in a few seconds!!! Ie Why would it ever need more than 100k JS after compression and thus < 1s to load?

Even if it is a big size why not cache and be instant on load?

If the answer is it needs to use Ajax to load data after loading the js, then why not include that data on initial load?

drivingmenuts• 7 years ago

Where I work, we’re still using jQuery. Why? It works and everyone on the team understands it, even the backend guy who hates doing UI stuff. We looked at React and Vue, and they’re great, but it would be a nightmare to get everyone on the same page and wouldn’t solve the problem of keeping our front end lightweight.

halleonard2• 7 years ago

You would be surprised. After a couple tutorials I imagine, at the very least, your backend developer will thank you. That's been the biggest migration in the react world -- backend developers to the frontend, because the frontend suddenly "makes sense" due to it being declarative and predictable, rather than imperative.

As far as lightweight goes, jquery is much heavier than Preact, a React clone designed to be lightweight. Only 16kb.

ng127• 7 years ago

I hate these kinds of posts. It's all useless to talk about unless you talk about what you're trying to build. Not everything that runs in a browser is cut from the same cloth. My job would be miserable without a UI framework, it's a trade-off I've consciously made. I've lived through PHP and Ruby and jQuery/Backbone/Knockout/Closure and my current stack (React + TypeScript) is the only thing that makes my job actually enjoyable. The most important skill is to be able to identify when and where building an SPA is a good idea (hint: it's not your blog or your company's home page). If you really do need an SPA, great, pick a UI framework and a few preprocessors/transpilers and get hacking. If not, also great, just use server-side templates and jQuery. Whatever way you go just remember to leave the zealotry at home.

winrid• 7 years ago

Heh, I just built my new blog with zero client side scripting. It's so fast (shameful plug: http://blog.winricklabs.com/)

No real content yet, but there will be regular content about my side projects.

ivanhoe• 7 years ago

In 2014, when this was originally written, I'd totally agree - but it was 4.5 years ago and a lot of things have changed in the meantime. At the moment I'm dealing with one jQuery old-school project and while on one hand it's really a nice feeling to debug code without constantly waiting for webpack to finish compiling the code, most of the time I'm really in pain. After years of working in Vue and React it just feels ugly and messy and it's much more complicated to understand and refactor. To quote on one of my fav Stephen King's books "the world has moved on" since then...

mixmastamyk3• 7 years ago

There’s not much meat here to the assertion that it is easier to develop and use.

jinfiesto3• 7 years ago

It's been probably 2 years since I've seen a front-end dev listing that doesn't list experience with a SPA framework as mandatory. I'm not going to question that hybrid and traditional apps exist in the wild. I maintain some myself. That being said, I think it's pretty clear that at the very least the world is moving on. We are asking for more out of the web than what it was designed for, and it's difficult to meet the expectations of modern users without modern tooling.

By way of example, I do a lot of freelancing and have quite a lot of clients that I think would be better served by a traditional web app (much faster to develop, though not nearly as rich interactions dollar for dollar. Also a lower infra bill generally.) Many of them refuse though because they've been conditioned to expect the kinds of features that SPA's provide.

I write a lot of business automation sorts of apps for SMBs. Something I see requested a lot is wizard style workflows (on a web app.) This is trivial in a SPA and a major annoyance at best in the context of a traditional app framework. I totally agree that the world might not have moved on yet, but I think it's pretty clear which way the wind is blowing. Users are expecting rich SPA interactions as the new normal.

tdy_err• 7 years ago

without constantly waiting for webpack to finish compiling the code

We have 50,000~ LoC in our front-end and the Webpack development-server is rebuilding in 2-3 seconds.

austincheney• 7 years ago

I so tired of the excess tooling and incompetent reliance upon it. You don’t need layers of frameworks and 150mb of dependencies to build a tiny web app. Without all the helpful bullshit in the way I can get the job done 10x faster. The excess nonsense isn’t there to help clueless users. It’s there to prop up clueless developers.

When I start interviewing next month I am going to dive into this immediately and if I don’t like the answer I am walking out. Interview over. They can hire somebody else to write tiny react modules.

The boring front-end developer (2014)

Related Stories