81–90 of 143 posts
Earlier quoted context omitted.
Like left-pad? By adding more 3rd party dependencies (and theirs) you're increasing risk.
You’re increasing risk by writing it yourself too.
It means there's less leaks through the cracks because everything is better integrated instead of loosely tied together.
This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side frameworks already figured out. I was following a simple Vue/Vuex tutorial the other day and my node_modules directory was 200MB+. Use yarn or npm to install XYZ.... What's the difference? Why do I have to google this as step 0? Why do you assume I know the intric…
I can't really understand the sentiment that front-end dev is absurd. I started with .NET years ago and find _anything_ that becomes 'standard' in the front-end more approachable than the constant reinventing of the wheel / new framework releases MS did circa 2004 - 2014. It was something like: - Learn ASP, opps we meant ASP.NET web forms. Actually, we meant .NET MVC. - Oh no, the world wants APIs ... please learn WC…
This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side frameworks already figured out. I was following a simple Vue/Vuex tutorial the other day and my node_modules directory was 200MB+. Use yarn or npm to install XYZ.... What's the difference? Why do I have to google this as step 0? Why do you assume I know the intric…
1910: We dream of human flight.
2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all.
1981: We dream of reusable software, of assemblable software components, of sharing.
This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side frameworks already figured out. I was following a simple Vue/Vuex tutorial the other day and my node_modules directory was 200MB+. Use yarn or npm to install XYZ.... What's the difference? Why do I have to google this as step 0? Why do you assume I know the intric…
I understand your frustration. One thing I'd like to mention is that a comment similar to your comment is frequently mentioned in any HN post about typical frontend/JavaScript topics. So frequently, that I'm not sure what it adds to the discussion at this point. It's possible you are not aware of that and just wanted to let you know.
I think a lot of us are spending too much time troubleshooting dependency nightmares versus actually solving problems for our clients/employers.
The popularity of projects like Laravel Mix indicate that there may be a problem grokking all this stuff.
Earlier quoted context omitted.
I'm primarily a back-end dev but do some front end work which is mostly React. I didn't like it much and thought there should be something better. Learned Vue on my own time, which was only a few hours. Did a super simple side project to work around some common gotchas. So glad I did, now use Vue for all new work and encourage people at work on greenfield projects. Now, I'm playing around with alternate state managem…
What did you dislike about React? What does Vue do better?
I imagine it could be better with a different state management library or maybe ReactReason or TypeScript. The other thing I really like about Vue is how the layout and logic stay separated. With React and JSX there's always code all over the place: class methods, regular methods, lambdas, inline '&&' throughout the JSX. The way Vue handles events is far simpler.
I do however see the value in all of this with React when working on a large team. It all adds up to safety. I haven't yet worked on a Vue app that has grown complex enough to feel any of that necessary as where even a simple React app's structure is already complex.
This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side frameworks already figured out. I was following a simple Vue/Vuex tutorial the other day and my node_modules directory was 200MB+. Use yarn or npm to install XYZ.... What's the difference? Why do I have to google this as step 0? Why do you assume I know the intric…
2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all. 1981: We dream of reusable software, of assemblable software components, of sharing.
> CSS grid > If you’re still using heavy-weight grid frameworks from UI toolkits like Bootstrap or Foundation, you are falling behind. This is a pretty sensationalist way to word this and honestly an absurd statement as a whole. If you have a public-facing site, ignoring everything that isn't up-to-date is a luxury you can't afford and blunt statements like these show ignorance in that regard.
Then it's time for PostCSS, because now we use JS to write CSS.
Earlier quoted context omitted.
According to CanIUse, it's supported in browsers used by 88% of users in the United States. Which means sites will fail to render properly in 12% of browsers. Developing for a b2b or enterprise product? That percentage is going to be lower. Developing for users outside advanced industrial countries? Lower. And it's not like you can polyfill it or use a fallback -- CSS grid is a completely new way of building layouts…
CSS grid works in IE11 with a few restrictions. Requiring IE11+ support is quite common for websites targeting the US market at least. Unless your audience is pretty unusual it's easy to make a case for excluding older browsers than this.
It is not just "a few restrictions"; you can't even get close to a grid-based layout that works in IE10/11 by accident.
It's doable, but practically, it might be a fairly reasonable decision to give up on giving IE the nice layout and falling back to a flat "mobile" layout, if you're doing progressive enhancement properly.
What are the minimum technologies needed to get a solid front-end stack, with a nice balance between modern features without framework/library/build tool/transpiling hell?
For example, I don’t want to learn TypeScript when vanilla JavaScript will suffice. I’m wary of picking up the “hot” new frameworks because they haven’t stood the test of time and may get deprecated/irrelevant.
Basically, I want to have a flexible and minimalist stack, but also with a good balance of features (i.e. not just a static HTML site).
Any ideas?
Earlier quoted context omitted.
What did you dislike about React? What does Vue do better?
The 'type'ing with PropTypes which required much typing. Also having to edit 4 or more places to add one thing. Let's see there's where the UI calls the action, the action, the api request, the reducer and finally the render of the data along with any new proptypes you introduced copied to each consumer. I imagine it could be better with a different state management library or maybe ReactReason or TypeScript. The oth…
For Redux specifically, we've got a new `redux-starter-kit` package available. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state without writing any action types or action creators by hand. I'd encourage anyone using Redux to try it out and let us know how much it helps you.