Old backend coder here. All I see here is
>>> it’s fast
That's the same thought I 30 years ago when going from compiling a Fortran program (minutes) to compiling programs with Turbo Pascal 3.0 (instant)
History repeats itself I guess.
Vite – Next Generation Front End Tooling
241–250 of 383 posts
Re: Vite – Next Generation Front End Tooling
#242Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing. I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, a…
No post body was provided.
Re: Vite – Next Generation Front End Tooling
#243Earlier quoted context omitted.
Game-changer perhaps in a bad way ;) We're losing the art of writing solid code and instead flail with the "hot reload" crutch. I miss the days of punching cards and submitting a deck to be compiled and run - at least in terms of it forcing me to verify my work ahead of time. And yes - I'm (mostly) kidding. But I did write my first programs on punched cards at a university course while I was still in grade school. Pr…
We are also writing far more complicated software. Punch cards didn’t have to support thousands of different devices, resolutions, screen densities, input methods, etc. It’s a totally different world.
That's totally fair but the tooling is still not where you'd like it.
In theory, there's no reason that you shouldn't be able to backtrace from the website to the filesystem. If you can do that, then your "it reloads every second" becomes even faster, it becomes WYSIWYG, you are writing in the live constantly-refreshing UI. Well, almost: your text editor has Undo and Git and your web browser doesn't. But we could build those into the browser. Heck, Redux is basically Git except without any standardized verbs, just give Redux some standardized verbs for tracking revisions in a living app and you've got everything you need.
If you follow that trend to its logical conclusion ("OK I want a special way to ctrl-click or right-click or something to edit the HTML of a component I see") you eventually get Smalltalk, and we're finally back as productive as we could be in the 70s :)
Re: Vite – Next Generation Front End Tooling
#244Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing. I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, a…
The saving grace of frontend is that debugging is really easy. You can inspect the actual code of all your dependencies in node_modules, and they're almost always on github too (in case they bundled/minified code). The programs are mostly single-process and single-threaded. The same Chrome devtools you use to debug in the browser are used to debug NodeJS code.
Yes, it's stupid that sometimes you have to set a breakpoint inside a webpack plugin to figure out what's going on, but at least it's an option.
And as other commenters have echoed - you don't have to use any of this stuff. Most of it is short-lived and low-quality anyway. Half the time it's just an excuse for someone to write a blog post for clout. Expertise is as much about filtering out noise as it is digging deep into things.
People complain a lot about bundlers in particular. Bundlers are "just" string concatenation. It's an easily understandable problem with a lot of weird edge cases. So you wind up with bikeshedding and a lot of bundlers and what looks like unnecessary complexity. But there's little payoff to really "learn" a particular bundler. It's more important to learn why bundling is necessary (the Vite FAQ does a decent job of this) and then some of the features that can make it complicated (e.g code transformation). Then you become an expert on the underlying problem of shipping the minimal amount of code to the browser, which isn't going anywhere. You can then understand what differentiates bundler A from B. It's usually not much beyond a simpler config file. Despite all the new hotness that exists today, the outdated Webpack 4 has feature parity with pretty much any bundler out there.
Re: Vite – Next Generation Front End Tooling
#245Earlier quoted context omitted.
Whether the project is FOSS or not is irrelevant. They're seeking distribution and in order to further distribute a project needs to be able to cleanly communicate why it deserves more distribution. Ironically, based on your comment, FOSS products are generally very good at this. What OP provided was criticism, and FOSS needs and welcomes criticism to stay strong and relevant. If OP was opening a GitHub issue and ber…
The argument presented was neither level-headed nor genuine.
It's a tad emotional but still cogent.
Re: Vite – Next Generation Front End Tooling
#246Earlier quoted context omitted.
"Next gen front end tooling" - for anyone with some vague knowledge of front end development would understand that this is going to be something like webpack, or mix, or grunt, or gulp. Not every front page has to assume the person going to it knows nothing.
Front-end tooling that I have to run on the server? Even people familiar with the JS ecosystem might be confused by that.
You don't have to run this on a server. This would never run on a server. This would be used in your local dev environment.
Re: Vite – Next Generation Front End Tooling
#247Hey. If you're hear to post about how the web is always changing, and it's so complicated, no one cares. It's been posted 20 times by now and there are good reasons (we build much more complicated webapps these days).
I like Vite. A few things I like:
- Super fast
- Works out of the box (like parcel)
- Even production builds are super fast -- this is a bit of an underrated feature because sometimes things only break in prod builds, so having fast prod builds = more frequent prod tests = better
Re: Vite – Next Generation Front End Tooling
#248Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing. I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, a…
It's hilarious listening to my friends who do frontend rave about the the incredible framework of the month, every month there's a new one that's supposed to be the last, ultimate, final stop for developing frontends. Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.
I don't really understand these sorts of low-effort comments. You're probably referencing the React Server Components that were recently proposed. React has supported server side rendering basically since its inception. The problem with most existing SSR implementations in any language is that it's a one-shot synchronous process which doesn't allow for out of order streaming. For example, you might want to render a loading state and replace it with content once some network call returns. This used to take multiple requests; you get the initial page, some JS makes the network call, then you might need to download even more JS to render the result. Now you can do it all in one shot with (almost) no JS; the server can stream this entire sequence of HTML chunks in one response.
That's pretty useful and it's not "PHP 25 years later with 100x the complexity"
Re: Vite – Next Generation Front End Tooling
#249Vite is kind of nice because it weaves together some more modern tools, but if you're doing something simple, you might be able to just use esbuild directly on it's own. Bonus: if you're writing Go software, you can use esbuild's (slightly cumbersome) Go API directly in your app server and avoid needing to have JS tooling in your serving/building path, just using Node to handle things like JS package management, typechecking, and linting.
Re: Vite – Next Generation Front End Tooling
#250Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" that never really work in you editor, and you never really grasp before moving on to the next thing. I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, a…
I too find this exhausting. However, to be completely fair, front end was a 100% no-go for me before 2015, and improvements to the language and improvements to the ecosystem have turned it into something that I can deal with occasionally without wanting to murder anybody. ES2016+, better build systems, better package management, typescript, etc., have all made huge strides in front end development.
It could still do without the framework of the month trendiness, but eventually dumb ideas die and good ideas succeed.