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.
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.
I've spent most of the last decade working on data-intensive web applications which definitely deserve to be SPAs. There's lots of opportunity, especially if you're willing to move away from the "retail" public-facing web.
What do you mean by data intensive? I'm thinking something that looks like a bloomberg terminal, complex tabular data or complex visualizations. Those are cases that should never be a web app at all, even with recent improvements HTML is a document format and horribly suited to those use cases.
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...
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.
I didn't mean to say that SPAs were easier at all. They're not. I think they're under most circumstances much harder than traditional webapps. That being said, my experience is that users and in my case clients are starting to expect SPA features and it's harder to try and coax extensive SPA functionality out of a traditional web app than it is to just write a SPA.
I suppose it's all relative, but at least in Rails, while I suppose it's trivial in an absolute sense, it's much harder than doing stuff "the rails way."
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.
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
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.
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.
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.
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).
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
I just built a simple webapp at work and found that most of what I used JQuery for (cross-browser functionality) was already built into the modern browsers. I'm sure if I had to do something more complex or handle more than the handful of event handlers I wrote I'd reach for more than just plain JS, but shrug. It worked for me.
It's losing ground in popularity -- that I don't disagree with. However, it is a perfectly acceptable solution for building SPAs. (Saved my personal bias for the end: Do I feel it enables the highest level of productivity for me versus other frameworks? No).
You can’t forget about Ember. It’s still going strong. It’s in widespread use and drives some major projects. It’s just not terrible, so people don’t constantly talk about it or rewrite things in it or replace it, generating a churn of blog posts about itself, it’s out there quietly getting stuff done for a lot of people.
1. "Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like virtual DOM diffing that eat into your frame budget and tax the garbage collector."
Is this a practical concern for folks writing CRUD SPAs? I've never experienced degradation in performance due to virtual dom diffing.
2. "Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM."
Angular has its ahead-of-time (AOT) compiler for applications built in production mode. Is this any different from Svelte? It sounds like Svelte claims to be novel, but Angular too does build-time template optimization.
I'd love answers to these questions too. Svelte looks cool from a technology perspective but honestly it's biggest selling point is solving problems I don't have.
It’s solving a performance problem on low-powered, embedded web platforms, such as TVs and even consoles with powerful hardware but inefficient browsers (e.g. PS4’s WebMAF).
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.