Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Sapper.js – towards a better web app framework

svelte.technology

Post reply on HN
Print view View original

171–180 of 219 posts

Re: Show HN: Sapper.js – towards a better web app framework

#171

Post by Ros2 »

Hey Rich, your hackernews clone doesn't perform all that well globally

https://testmysite.io/5a4c2cdf819876444fa127b5/hn.svelte.tec...

I really like Svelte! But I don't even serve my content from Express middleware anymore due to the above problem.

I just feel like you're under-estimating a developer's resourcefulness to make the content that actually is static a static page, and also over-estimating the number of new, traditional client/server web apps (at least by people who are probably in your target audience).

Static performance is hard to beat especially globally and there's a clear performance degradation once you get away from the epicenter. Believe it or not Svelte.technology's landing page actually performs noticeably more poorly coast to coast in the US (>2x worse to load in California than NY--150ms vs 500ms).

I'm not saying give up or anything, just saying it might be a good idea to talk to more JAMStack people :)

Re: Show HN: Sapper.js – towards a better web app framework

#172

Post by lfischer »

_greim_ wrote: post #153

> the framework should do automatic code-splitting at the route level, and support dynamic import(...) for more granular manual control I disagree! Code-splitting is arguably an architectural dead-end for SPAs: 1) It adds a non-trivial layer of complexity to both your application logic and your tooling. SPAs (and the JS ecosystem in general) are already complicated enough without this extra layer of indirection, and…

It’s an interesting idea. From the case studies you’ll find on the web, it looks like Progressive Web Apps want to play minimal bootstrap time as as card against native apps, but it’s true that re-use of existing web know-how could be enough arguments in their, although native app developers are getting almost as easy to find as web developers these days.

Re: Show HN: Sapper.js – towards a better web app framework

#173

Post by unclebucknasty »

scottmf wrote: post #155
RobertRoberts wrote: post #103

Earlier quoted context omitted.

How does that help 1000 visitors to a blog read the blog easier? Not every site is an app, and the apps we do build we already have invested in VanillaJS framework. Do you think React will outlast the VanillaJS framework? ( http://vanilla-js.com/ ) (edit: this is partly a joke comment, fyi)

I understand the joke but JS isn't a framework, it's a language. "No framework" generally means "poorly-written custom framework". Do you have any code samples to share from your vanilla JS apps?

>"No framework" generally means "poorly-written custom framework"

This thinking is part of the problem: the idea that not-using a framework almost necessarily means you're writing garbage.

>Do you have any code samples to share from your vanilla JS apps?

I can show you bad code from popular frameworks too--in particular, hacks to get around the "magic" that frameworks offer.

And, invariably, we move on from the framework because now there's "something better". And, we say "that's just progress". No one wants to admit that the last framework was just bad.

It's a trend that's been going on for decades in programming, and not just with JS frameworks. Stick around long enough and you'll see exactly how predictable it is.

Re: Show HN: Sapper.js – towards a better web app framework

#174

Post by rich_harris »

fineline wrote: post #168
rich_harris wrote: post #147

Earlier quoted context omitted.

Simply put, you can do more with templates. It's the Principle of Least Power at work — the same way you can do more with a blob of JSON than a blob of JavaScript, templates allow you to do things that are basically impossible with JSX, such as compiling to a string concat function for server-side rendering that is much, much faster. Ask the teams behind Glimmer, Marko, and other tools, and they'll tell you the exact…

Hi Rich, I notice you mention Marko. That was my first thought when checking out Svelte today - Marko uses somewhat similar approach, and thus brings somewhat similar benefits. But Marko has couple of other advantages - beautiful "concise" syntax option, and easy debugging at dev time as the Lasso bundler turns JS modules into equivalent files in the browser, complete with same line numbering. (It only works with Com…

I'd say it's a matter of personal preference as much as anything else. (Personally I'm not a fan of the compact syntax — I prefer just using HTML and CSS, but it's subjective.)

Performance-wise, you'll get great results with either framework. You mention debugging — Svelte creates useful sourcemaps, and the generated code is very readable anyway. Svelte has a few features you might find interesting (AFAIK Marko doesn't offer these, though I'm not intimately familiar with it):

* it can compile directly to custom elements * your styles are scoped to the component * declarative transitions * built-in global store (think Redux, but zero boilerplate) * useful element bindings (for e.g. customisable media players https://svelte.technology/repl?example=binding-media-element...) * computed properties. these are a lifesaver when you're doing a lot of complex reactive stuff

and so on. Also, I don't think Marko has an equivalent of Sapper.

Finally, while Marko is slimmer than the likes or React or Vue, there's still a runtime library you need to include on your pages. A typical Sapper page is about the same size as Marko by itself, before you've added any app code.

Re: Show HN: Sapper.js – towards a better web app framework

#175

Post by lfischer »

cryptica wrote: post #161

Isomorphic frameworks are a bad idea. I'm convinced that any attempt at making a single general-purpose web application framework will fail. I've seen it happen too many times before. SocketStream, Derby, and even MeteorJS which had massive funding and marketing just couldn't do it. NextJS is just the next generation of fools who didn't research the market... Surely we can at least wait for NextJS to go belly up befo…

From what I’ve gathered, both Next.js and Sapper.js are less ambitious than Meteor and Derby. They require to write your own data access code by hand, by making HTTP requests or importing whatever server-side JavaScript libraries you need, while Meteor and Derby tried to provide the same model API on the server and on the client. Maybe the model API (and the fact that you were almost forced into storing everything in MongoDB) was the greatest limitation.

Re: Show HN: Sapper.js – towards a better web app framework

#176

Post by rich_harris »

Ros2 wrote: post #171

Hey Rich, your hackernews clone doesn't perform all that well globally https://testmysite.io/5a4c2cdf819876444fa127b5/hn.svelte.tec... I really like Svelte! But I don't even serve my content from Express middleware anymore due to the above problem. I just feel like you're under-estimating a developer's resourcefulness to make the content that actually is static a static page, and also over-estimating the number of ne…

This is more of an ops thing than a framework thing. If you're making a purely static app, JAMStack is great. Sapper is solving a different problem.

Having said that, we will eventually add the ability to 'export' a purely static site that can be deployed to services like Netlify. Next.js has this, but they didn't launch with it either. Bear with us!

Re: Show HN: Sapper.js – towards a better web app framework

#178

Post by austincheney »

Touche wrote: post #6

I think this premise is wrong: > 2. As a corollary, your app's codebase should be universal — write once for server and client This is a mistake a lot of developers make. The server and client are not the same. As far as rendering HTML goes, the client does a superset of what the server does. This means either the framework has to be without leaks; meaning you never need raw DOM access at all, OR it means once you do…

> This is a mistake a lot of developers make. The server and client are not the same.

This is the basic value premise of frameworks. Write less code with uniform conventions and make it easy by hiding the complexity. Unfortunately, the premise is faulty.

You can only lie to yourself for so long that your ignorance of how things really work is fine because of (name your favorite abstraction). This is a very direct example of tech debt. By ignoring how things really work the application will gradually get bigger and slower until it is an incompetent mess like paying off credit cards with other credit cards.

The reason for this snowball effect is largely due to a lack of confidence that feeds upon convenience as opposed to examination of why technical problems exist in the first place.

Re: Show HN: Sapper.js – towards a better web app framework

#179

Post by taneq »

rich_harris wrote: post #23
DougWebb wrote: post #18

Sorry, I couldn't resist. Second and third paragraphs, with some minor editing: HTML is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at https://www.w3schools.com/html/ . HTML introduced a brilliant idea: all the pages of your app are files in a your-project/pages directory, and each of those files is just an HTML page. Everything else flows from that breakth…

If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.

When the entire page is 50kb of compressed text and some cached images, I don't mind reloading it on every single navigation (at which point dynamically generated HTML is more than adequate for dynamic data). It's only when devs insist on shoveling 5mb of compressed JS libraries into it that it becomes an issue.

Re: Show HN: Sapper.js – towards a better web app framework

#180

Post by cookiecaper »

megaman22 wrote: post #48
scottmf wrote: post #42

Earlier quoted context omitted.

I feel like a lot of HN is stuck in 2010 and dislikes all of this new web tech because they don’t understand it. This comment is a prime example.

Possibly a lot of HN has been around the block for a couple of decades at this point, and has seen this web dev stuff come full circle several times, and before that, the same ideas in desktop software. Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Maybe we can get away from rehashing the same cycle of trends every five years and move o…

Yes, though I think we need to diffuse the sentiment via organic cultural osmosis rather than relying on ivory towers to indoctrinate for us (not effective).

Alan Kay frequently laments the direction of the computer industry, calling computing "not-quite-a-field" and "pop culture". From an interview in 2012:

Quote:

----

> Kay: [...] [I] happen to believe in history. The lack of interest, the disdain for history is what makes computing not-quite-a-field.

> Binstock [interviewer]: You once referred to computing as pop culture.

> Kay: It is. Complete pop culture. I'm not against pop culture. Developed music, for instance, needs a pop culture. [...] The big problem with our culture is that it's being dominated [more by] pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that's been worked on and developed and you [can] [sic] go to the next couple levels.

[...]

> [Kay continues]: [P]op culture holds a disdain for history. Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from]. [sic - brackets in original]

---

It's a great summary of the programming fads that have come to characterize tech culture and how disappointing it is for anyone who is trying to navigate this field with some intent and presence of mind higher than fitting in with the crowd or cashing in on a perceived gold rush.

It's also just a great memorialization of the concept of pop culture in general; pop culture is about a feeling of belonging and community, and engaging positive biological responses associated with social approval and community. It's something that people do to give themselves that rush of praise, and then retroactively try to justify. After a couple of years, no one can understand what anyone was thinking because they were just rationalizing riding the tide.

And, IMO, it aptly describes not only the React phenomenon, but also Kubernetes (aka "shared hosting"), Docker (aka "static linking"), etc. Also IMO, big dollar players stoke this negative culture because it's profitable for them.

It's not necessarily that these technologies won't leave their mark, it's just that they're not the revelations people pretend they are.

Regardless, suspicion is always warranted when people insist that the contemporary is novel, in computing or practically anything else.

[0] http://www.drdobbs.com/architecture-and-design/interview-wit... \ archive: https://archive.fo/DkQOc

Post reply on HN