The boring front-end developer (2014)(adamsilver.io)
adamsilver.io
The boring front-end developer (2014)
https://adamsilver.io/articles/the-boring-front-end-developer/
71 comments
Why not find a project somewhere that truly calls for an SPA? Those are the fun ones.
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.
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.
Sell shovels during a gold rush, whats the problem?
If you are disillusioned then its time for something new
If you are disillusioned then its time for something new
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...
There’s not much meat here to the assertion that it is easier to develop and use.
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.
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.
Sorry I miswrote. I recognize the mindshare shift, but not entirely convinced on the makes dev easier part.
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.
> 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.
We have 50,000~ LoC in our front-end and the Webpack development-server is rebuilding in 2-3 seconds.
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.
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.
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
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?
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?
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
- 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
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.
Previous discussion: https://news.ycombinator.com/item?id=9879172
This should also have a 2014 in the title.
This should also have a 2014 in the title.
Added. Thanks!
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.
[1]: https://css-tricks.com/the-great-divide/
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/
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.
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).
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).
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
Lots and lots and lots of people.
Lots and lots and lots of people.
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.
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.
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.
IME the issue is not being overwhelmed with libs/frameworks, the issue is SPAs requires way more work.
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
* Accessible via keyboard
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
> 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.
I believe the answer is Svelte.
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.
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.
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.
No real content yet, but there will be regular content about my side projects.
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.
Of course, once everyone does this, tech innovation grinds to a halt and we end up using the suboptimal tools we have forever.
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.
As far as lightweight goes, jquery is much heavier than Preact, a React clone designed to be lightweight. Only 16kb.
[deleted]
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.
I'm working on a 1.6Ghz CPU and compile times are a frustrating several seconds.
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.
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.
Damn I am a cool front-end developer and that's not a good thing.
That was a very boring article.
Yeah, I don't think we really need a hundred Modern Frontend Bad articles every week
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 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.
Job boards seem to have (a lot) more Angular than Vue work posted: https://medium.com/zerotomastery/tech-trends-showdown-react-...
JQuery is still popular
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.
Who is the authority on not recommending Angular? They're still regularly releasing an actively developed framework.
https://2018.stateofjs.com/front-end-frameworks/overview/ is my favorite source. Angular is losing ground every year.
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.
> I dont think there has been much change in the javascript world in the last few years that hasnt been strictly beneficial.
Take a look at Svelte 3.
https://svelte.dev/blog/svelte-3-rethinking-reactivity
Take a look at Svelte 3.
https://svelte.dev/blog/svelte-3-rethinking-reactivity
Two genuine questions.
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.
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).
It isn't about your problems, it is about your user's problems.
Do you think I'm writing web applications for myself?
I agree with ng12 here. If my users are getting 60FPS+ with Angular or React there is no tangible performance issue my users are suffering from.
What do you mean Angular not being recommended? It's pretty damn straight-forward and does the job just fine if a SPA is what you're after.
What happened to Knockout.js?
Just in case, I'm being serious. I'm a mostly backend dev, and haven't spent significant time working on frontend code in several years.
Just in case, I'm being serious. I'm a mostly backend dev, and haven't spent significant time working on frontend code in several years.
loll
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.
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.